Как мы знаем, youtube перестал показывать рекламу уже пару лет как, а недавно практически перестал показываться сам. А если и показывался, то по цене 144р.

Мне это не понравилось, и на конечных хостах я, в целом, способ смотреть рекламу без тормозов я нашёл, благо есть VPS с развёрнутым CHR в другой стране. Но это каждый раз на устройствах надо было включать всякие программы дополнительные, и прочие разные костыли, которые привносили толику дискомфорта.

Но мне хотелось, чтобы всё работало без лишних телодвижений для всех устройств в моей сети. Да и вроде не зря я микротовод со стажем, решил разобраться.

Чтобы не оставлять неоправданных ожиданий, скажу сразу: инструкция для последних версий RouterOS 7 (я дома сделал на 7.15.3) и точка выхода у вас должна быть. Без неё можете дальше не читать.

Прежде чем начать конфигурацию, убедитесь, что выполнили для этого необходимый минимум:

1.     У вас есть рабочий куда-надо-туннель

2.     У вас интерфейсы добавлены в интерфейс-листы WAN (провайдер и туннель) и LAN (ваши внутренние интерфейсы)

3.     Ваш роутер снаружи закрыт, например, стандартным фаерволом и не отвечает на DNS-запросы (важно!)

4.     Ваш роутер (и только он) является DNS-сервером в вашей сети/сетях

Итак, наверняка многие из вас знают про Policy Based Routing. Это когда решение о маршрутизации у нас принимается не по адресу получателя, а по политике, в которую попал пакет. Именно этим мы и воспользуемся.

Подразумевается, что любой впн-клиент у вас уже есть и настроен. В данном материале НЕ будет рассматриваться сценарий с IKEv2, который не создаёт интерфейса, а трафик в нём бегает с помощью чёрной магии и политик IPSec.

Общая задача такова:

· Нам нужно частично трафик отправлять в vpn

· Мы не знаем всех ip-адресов заранее

· Мы не знаем всех FQDN, известны лишь несколько необходимых доменов второго уровня

· Мы не хотим заворачивать ВСЕ адреса гугла в впн, ибо жирно очень

Вводные кажутся непростыми, потому что возможности адрес-листа в фаерволе ограничены: либо адрес/подсеть, либо FQDN, но поддомены по маске он не принимает, что делает стандартную концепцию нерабочей.

В любом случае, нам понадобится дополнительная таблица маршрутизации, чтобы поместить в неё маршрут через vpn. Создадим её и добавим маршрут двумя командами:

/routing table add disabled=no fib name=rt_vpn
/ip route add gateway=l2tp-out1 routing-table= rt_vpn

Здесь l2tp-out1 имя вашего куда-надо-туннеля, а rt_vpn – имя создаваемой таблицы маршрутизации.

Далее мы не сразу перейдём к Policy Routing-у, а сначала поколдуем с DNS.

В Mikrotik за несколько последних версий работу с этим протоколом весьма неплохо прокачали, и нам это сейчас пригодится. Речь пойдёт про статические DNS-записи.

Во-первых, добавили возможность создавать запись с типом FWD, это значит, что запрос, совпавший с условием (именем или регуляркой) будет перенаправлен на указанный DNS-сервер.

Во-вторых, сделали прекрасную опцию match-subdomain, которая позволяет нам цеплять домены более высоких уровней

В-третьих, ещё одна опция – и она довольно свежая (в данном контексте) – address-list. С её помощью в момент резолва по данной статической записи, всё, что отрезолвилось, добавляется в указанный адрес-лист в фаерволе.

А теперь соберём адское к-к-к-комбо: мы можем направлять нужные нам запросы вместе с поддоменами на нужные нам сервера, а полученные ответы автоматически заносить в адрес-лист, где они будут жить до протухания кэша DNS.

Домены для просмотра рекламы через впн нам известны, их не так много:

· youtube.com

· googlevideo.com

· youtu.be

· ytimg.com

Я их добавил в ip dns static двумя способами сразу, можете потом поотключать ненужное, поэкспериментировать:

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=youtube.com type=FWD

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=googlevideo.com type=FWD

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=youtu.be type=FWD

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=ytimg.com type=FWD

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=ggpht.com type=FWD

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=googleapis.com type=FWD

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=googleusercontent.com type=FWD

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=ytimg.l.google.com type=FWD

/ip dns static add address-list=to-vpn forward-to=1.1.1.1 match-subdomain=yes name=nhacmp3youtube.com type=FWD

Эти настройки разрешают необходимые домены на DNS-сервере 1.1.1.1 и добавляют полученные от него адрес в список адресов to-vpn. Первые четыре записи используют регулярные выражения, следующие — домен с поддоменами. По-идее, можно попробовать обойтись без регулярок, а также использовать любой симпатичный вам DNS.

У нас готова наполнялка адрес-листа, который мы далее будем заворачивать в туннель. Достаём шампуры и подходим к мангалу. То есть, к манглу.

Для начала давайте пришьём ещё пока неотстреленную ногу. Поскольку мы будем возиться с Policy Routing-ом, вероятность отстрела не то что ненулевая, а весьма высокая. Снизим её с помощью дополнительного адрес-листа и правила в мангле:

/ip firewall address-list add address=10.0.0.0/8 list=RFC1918

/ip firewall address-list add address=172.16.0.0/12 list=RFC1918

/ip firewall address-list add address=192.168.0.0/16 list=RFC1918

/ip firewall mangle add action=accept chain=prerouting dst-address-list=RFC1918 in-interface-list=!WAN

Данное правило поднимите в мангле на самый верх. Пусть оно там незаметно болтается примерно всегда. Если у вас уже настроены сложные манглы – то инвазивность приведённых здесь правил именно для вашего конфига оценивайте для себя сами. Если ваш мангл девственно чист – можете смело следовать приведённым инструкциям.

Правило, которое добавили, не позволит локальным адресам улететь в туннель. Ну и правильно, он же у нас исключительно для просмотра рекламы, а не для этой вашей работы, что там забыли локальные адреса?..

Дальше нам необходимо пометить соединения до адресов из нашего списка. Традиционно я это делаю следующим образом:

/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark connection-state=new dst-address-list=to-vpn in-interface-list=!WAN new-connection-mark=to-vpn-conn passthrough=yes

/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark connection-state=new in-interface-list=!WAN new-connection-mark=to-vpn-conn passthrough=yes src-address-list=fully-vpned-devices

Правил, как вы можете видеть, два. Оба они по разным критериям маркируют соединения маркой to-vpn-conn. Первое правило делает это для всего внутреннего трафика, который идёт к адресам, находящимся в списке to-vpn. Этот список наполняется у нас из настроек DNS, но никто не запрещает вам добавлять туда любые адреса/домены, которые нужно завернуть в куда-надо-туннель. Второе правило отмаркирует ВСЕ соединения устройств, айпи-адреса которых вы добавите в список fully-vpned-devices. Совершенно не обязательно его чем-то наполнять, создаётся на всякий случай для последующего удобства. То есть для устройств из этого списка весь мир будет виден по ту сторону туннеля.

Теперь у нас есть раскрашенные соединения, но с трафиком из них ничего не происходит. Исправим это недоразумение, и, наконец, применим ту самую политику маршрутизации.

/ip firewall mangle add action=mark-routing chain=prerouting connection-mark=to-vpn-conn in-interface-list=!WAN new-routing-mark= rt_vpn passthrough=no

Здесь мы в цепочке prerouting (потому что она находится ДО маршрутизации) всем пакетам, которые идут НЕ СНАРУЖИ (то есть изнутри) И соединения этих пакетов промаркированы вышеназванной маркой соединения – вот по этим критериям мы пакету навешиваем routing-mark той таблицы, где нас ждёт маршрут куда-то далеко. Таким образом решение о маршрутизации для этих пакетов будет осуществляться по таблице rt_vpn и определит совершенно другой исходящий интерфейс. По прохождении всей packet flow diagram, этот пакет улетит в туннель, а не к провайдеру.

После произведённых манипуляций сбрасываем DNS-кэш наших устройств (или, чтобы наверняка, перезагружаем их) и наслаждаемся рекламой на Youtube в небывало высоком качестве без тормозов. Profit!

Скопипаздил тут:

https://telegra.ph/Smotrim-reklamu-na-Youtube-v-4K-08-12