Обход блокировок и layer7

[ArtVAnt]

Не совсем так. Дело не в prerouting. Дело в add dst.

passthrough(yes | no; default:yes) - следует ли пропускать пакет дальше после маркировки его заданной меткой.
Cвойство действительно, только если действие соответствует определенной выборке - например, mark packet, connection или routing mark.

Понял, благодарю за разъяснение!

[Inner]

Не знаю, может поможет. Я у себя порезал торренты по скорости, но вы можете переделать под себя для обхода блокировок

В L7:

Код: Выделить всё

/ip firewall layer7-protocol
add name=torrent-www regexp="^.*(get|GET).+(torrent|thepiratebay|isohunt|enterta\
    ne|demonoid|btjunkie|mininova|flixflux|vertor|h33t|zoozle|bitnova|bitsoup|me\
    ganova|fulldls|btbot|fenopy|gpirate|commonbits).*\$"
add name=torrent-dns regexp="^.+(torrent|thepiratebay|isohunt|entertane|demonoid\
    |btjunkie|mininova|flixflux|vertor|h33t|zoozle|bitnova|bitsoup|meganova|full\
    dls|btbot|fenopy|gpirate|commonbits|bittorrent|bit-torrent).*\$"
add name=torrent-dht regexp="^d1:[a|r]d2:id20:.*:y1:[q|r]e"

В Mangle:

Код: Выделить всё

/ip firewall mangle
add action=mark-connection chain=prerouting comment=torrent-www layer7-protocol=torrent-www new-connection-mark=torrent-con passthrough=yes
add action=mark-connection chain=prerouting comment=torrent-dns layer7-protocol=torrent-dns new-connection-mark=torrent-con passthrough=yes
add action=mark-connection chain=prerouting comment=torrent-dht layer7-protocol=torrent-dht new-connection-mark=torrent-con passthrough=yes
add action=mark-packet chain=prerouting comment=torrent connection-mark=torrent-con new-packet-mark=torrent-packet passthrough=no

В QoS:

Код: Выделить всё

/queue simple
add disabled=yes dst=ether1 max-limit=10M/10M name=TorrentsForVIP packet-marks=torrent-packet target=10.0.0.20/32
add dst=ether1 max-limit=64k/64k name=TorrentsForAll packet-marks=torrent-packet target=MAIN-bridge

[zikolingmoth]

Честно говоря точно сказать не могу относительно перечисления... Но тут всё тоже просто, можно попробовать и проверить.

К сожалению у меня ничего не вышло с перечислением в одном правиле, ни через запятую, ни через пробел, ни через точку с запятой) но при этом он дает сохранить это в таком виде, но счетчик не прибавляет и соответственно ничего не работает.
Отдельные правила отлично работают.
К сожалению не нашел инфы, что можно и в каком виде прописать в строку tls host и можнл ли указывать как-то несколько. Это было бы логичным на мой взгляд)



Кстати, в моем случае получается так, что нет проблемы с открытием сайта, если этого адреса еще нет в списке(для первого открытия).
Сначала у меня идет правило Ваше, которое добавляет ip адрес в адрес лист, а далее идет правило мое, которое mark route, для которого уже получается адрес добавился в адрес лист и он спокойно уходит куда нужно). В вашем случае по идее тоже же не должно быть такой проблемы, еслт у вас не заканчивается обработка на моменте добавления адреса в адрес лист а дальше идет вниз по правилам фаервола

Добрый день! Не подскажете столкнулся с проблемой. При использовании данного правила ипшники добавляются в адрес лист и трафик уходит в впн, но есть проблема. Ощущение что он не все нужные ип добавляет, так как наблюдал картину, когда первый раз открываешь приложение инсты, оно не грузит ничего. Второй раз все работает. Далее выгружаешь приложение из памяти смартфона и заново его запускаешь и оно не грузит контент. Ощущение что правило не добавляет нужные ип адреса. Можно ли пофиксить данную проблему?

[gmx]

Добрый день! Не подскажете столкнулся с проблемой. При использовании данного правила ипшники добавляются в адрес лист и трафик уходит в впн, но есть проблема. Ощущение что он не все нужные ип добавляет, так как наблюдал картину, когда первый раз открываешь приложение инсты, оно не грузит ничего. Второй раз все работает. Далее выгружаешь приложение из памяти смартфона и заново его запускаешь и оно не грузит контент. Ощущение что правило не добавляет нужные ип адреса. Можно ли пофиксить данную проблему?

Конечно не все. Более того, они меняются, подключаются разные CDN причем логику переключений знают только разработчики приложения.
Относительно удобное и результативное решение - получить список адресов через bgp.
https://antifilter.network/bgp

[Proger125]

Добрый день! Не подскажете столкнулся с проблемой. При использовании данного правила ипшники добавляются в адрес лист и трафик уходит в впн, но есть проблема. Ощущение что он не все нужные ип добавляет, так как наблюдал картину, когда первый раз открываешь приложение инсты, оно не грузит ничего. Второй раз все работает. Далее выгружаешь приложение из памяти смартфона и заново его запускаешь и оно не грузит контент. Ощущение что правило не добавляет нужные ип адреса. Можно ли пофиксить данную проблему?

Можно. Решается связкой: правило TLS HOST + перехват DNS request/answer.

Так и есть. TLS HOST добавляет только часть ip адресов в список. В настоящий момент времени еще необходимо добавлять все ip адреса, что резольвятся DNS по данному домену и всем его субдоменам. Если посмотреть трафик к этим доменам, там не всегда полное пересечение по ip с теми, что получены от TLS HOST.

Но нужно учесть нюанс, упомянутый GMX в предыдущем сообщении, ответ DNS на соответствующий запрос должен быть из той же географической зоны, куда ходит ваш VPN. Для разных регионов, разные пулы ip из CDN. Именно поэтому недостаточно просто взять и добавить в Address List наименование host.com и думать, что теперь всё завернется в канал. Современные порталы разный контент грузят с разных субдоменов, расположенных на разных ip (и всё это с оглядкой на геозоны CDN). Использование маски, например, *.host.com в перехвате DNS ответов решает это полностью (об этом ниже). Либо самостоятельно изучите трафик и посмотрите все субдомены к которым идёт обращение. В принципе, можно попробовать их всех прописать вручную в Address List как a.host.com, b.host.com и т.д., но некоторые порталы создают такие субдомены динамически и там поможет только маска *. И еще раз про геозону DNS, если у вас инста резольвится через московский cloudflare, а впн бегает в Амстердам, то есть шанс словить connection refused у сайта, делайте всё красиво - в одной геозоне vpn и dns resolver.

Что касаемо перехвата, то перехватить ip прилетающие в качестве ответов на DNS request нужного домена стандартными средствами ROS не получится. Решения кастомные в принципе есть, разные способы, разные плюсы и минусы. Каждый сам изобретает свой велосипед. Я сделал у себя даже в рилтайме добавление DNS answer в Address List. Ни одного ip не теряется, все открывается сразу. И какие там субдомены, сколько их - у меня голова не болит.

Получаемое решение именно через перехват DNS request/answer - очень гибкое. Заворачивать в канал можно выборочно субдомены, а можно домены целиком, или даже полностью доменные зоны. С тем вектором, как развивается криптографическая защита трафика, работоспособность одного лишь способа TLS HOST лишь временна. Закроют это поле шифром или сам пакет установления связи TLS и всё, его не прочесть. Если мне не изменяет память, в TLS 1.3 уже можно скрывать это поле по желанию. Сохраняйте контроль над DNS запросами за собой, в этом решение.

[zikolingmoth]

Добрый день! Не подскажете столкнулся с проблемой. При использовании данного правила ипшники добавляются в адрес лист и трафик уходит в впн, но есть проблема. Ощущение что он не все нужные ип добавляет, так как наблюдал картину, когда первый раз открываешь приложение инсты, оно не грузит ничего. Второй раз все работает. Далее выгружаешь приложение из памяти смартфона и заново его запускаешь и оно не грузит контент. Ощущение что правило не добавляет нужные ип адреса. Можно ли пофиксить данную проблему?

Можно. Решается связкой: правило TLS HOST + перехват DNS request/answer.

Так и есть. TLS HOST добавляет только часть ip адресов в список. В настоящий момент времени еще необходимо добавлять все ip адреса, что резольвятся DNS по данному домену и всем его субдоменам. Если посмотреть трафик к этим доменам, там не всегда полное пересечение по ip с теми, что получены от TLS HOST.

Но нужно учесть нюанс, упомянутый GMX в предыдущем сообщении, ответ DNS на соответствующий запрос должен быть из той же географической зоны, куда ходит ваш VPN. Для разных регионов, разные пулы ip из CDN. Именно поэтому недостаточно просто взять и добавить в Address List наименование host.com и думать, что теперь всё завернется в канал. Современные порталы разный контент грузят с разных субдоменов, расположенных на разных ip (и всё это с оглядкой на геозоны CDN). Использование маски, например, *.host.com в перехвате DNS ответов решает это полностью (об этом ниже). Либо самостоятельно изучите трафик и посмотрите все субдомены к которым идёт обращение. В принципе, можно попробовать их всех прописать вручную в Address List как a.host.com, b.host.com и т.д., но некоторые порталы создают такие субдомены динамически и там поможет только маска *. И еще раз про геозону DNS, если у вас инста резольвится через московский cloudflare, а впн бегает в Амстердам, то есть шанс словить connection refused у сайта, делайте всё красиво - в одной геозоне vpn и dns resolver.

Что касаемо перехвата, то перехватить ip прилетающие в качестве ответов на DNS request нужного домена стандартными средствами ROS не получится. Решения кастомные в принципе есть, разные способы, разные плюсы и минусы. Каждый сам изобретает свой велосипед. Я сделал у себя даже в рилтайме добавление DNS answer в Address List. Ни одного ip не теряется, все открывается сразу. И какие там субдомены, сколько их - у меня голова не болит.

Получаемое решение именно через перехват DNS request/answer - очень гибкое. Заворачивать в канал можно выборочно субдомены, а можно домены целиком, или даже полностью доменные зоны. С тем вектором, как развивается криптографическая защита трафика, работоспособность одного лишь способа TLS HOST лишь временна. Закроют это поле шифром или сам пакет установления связи TLS и всё, его не прочесть. Если мне не изменяет память, в TLS 1.3 уже можно скрывать это поле по желанию. Сохраняйте контроль над DNS запросами за собой, в этом решение.

Можете описать поподробнее ваш способ, было бы идаельно с командами в терминале. Очень благодарен что подсказали в каком направлении думать!

[Proger125]

Можете описать поподробнее ваш способ, было бы идаельно с командами в терминале. Очень благодарен что подсказали в каком направлении думать!

К сожалению, команд в терминале Микротик у меня почти не используется для этой задачи, мой способ это связка Микротик + VPS. В которой на долю Микротик приходится лишь 5% действий и 95% всего остального на серверный Linux. Настройку и администрирование Linux я не осилю расписать. Средствами ROS, как я уже писал, более менее приличный анализ трафика DNS не предусмотрен.

Вы можете сделать Микротик системным DNS сервером в локальной сети. Всем вашим сетевым устройствам прописать в настройках его использование. И даже сможете на Микротике на 53-м порту читать входящие DNS запросы через Layer 7 с использованием всевозможных масок. Перехватите весь входяший DNS request и всё... (( Больше ничего не сможете сделать. Ну разве только блокировать выборочно DNS запросы и как следствие доступ к некоторым сайтам.

Ни ответные IP от конечного резольвера DNS, ни даже сами запрашиваемые домены/субдомены вы не сможете добавлять динамически в Address List направляемый в туннель. Поэтому я весь DNS трафик разбираю удаленно. Ну кроме, блокировок доступа к сайтам, разумеется. Тут у ROS всё прекрасно )))

[retom]

Замучился конфигурировать что по ip отправить в VPN, и я сделал немного по другому.
Настроил входящий VPN и на телефоне происал какие программы должны работать через VPN а какие на прямую.
+ настроил proxy и весь трафик с прокси отправил в VPN.
В браузере поставил плагин и прописал какие сайты должны рабоать через прокси а какие нет.

[ArtVAnt]

Не очень понял в чем загвоздка у вас вышла..
Использую dns over tls 1.1.1.1 на микротике + вышеописанный способ с tls host.
Имейте ввиду, что у некоторых сайтов несколько доменов!
Например, для фб и инстаграма у меня добавлены следующие домены, проблем нет