Выявление пакетов от DPI на роутере

#1

Всем привет! Задача проста: выявлять и направлять через VPS заблокированные ресурсы на уровне домашнего роутера. Сейчас пытаюсь реализовать на базе микротика. На данный момент отлавливаю ответ от DPI следующим правилом:

/ip firewall filter add action=add-src-to-address-list address-list=rkn address-list-timeout=1w chain=forward comment=
“RST to Address list” connection-state=established in-interface=pppoe-out1 packet-size=40 protocol=tcp
src-port=443,80 tcp-flags=rst

Затем соединения с хостами, из сформировавшегося списка “подозрительных” ip-адресов направляю через VPN:

/ip firewall mangle
add action=mark-routing chain=prerouting dst-address-list=rkn new-routing-mark=rkn passthrough=yes

Проблема в том, что правило фильтра слишком широкое, и в список попадает много лишних, легитимных соединений. В статье на хабре ValdikSS писал: “В случае с HTTPS-сайтами, DPI присылает TCP Reset-пакет, тоже с Identification = 1 и Flags = 0”, но в моём случае это не так почему-то, всё наоборот: DF-флаг на месте (1), identification = 0. Провайдер - ростелеком, Нижний Новгород.

Подскажите, можно-ли как-то средствами микротика однозначно идентифицировать ответ от DPI (TCP-reset)?

#2

Эта информация чуть ли не пятилетней давности, с тех пор многие системы DPI изменились или были заменены.

Почему из всех возможных методов обхода блокировок вы выбрали именно этот? Вас чем-то не устроили «классические» методы маршрутизации заблокированных адресов (которые тоже могут маршрутизировать много «лишнего»)?

#3

Приветствую! Так вот как раз и не устроили тем, что маршрутизируют много «лишнего», ищу способ исправить этот момент

#4

Привет!
У меня провайдер тоже ростелеком. В принципе с его DPI (не ТСПУ) в целом легко бороться.
На микроте две команды:
под https значение ttl=equal возможно придется подобрать индивидуально Wireshark в помощь.

1    block - http
      chain=forward action=drop protocol=tcp in-interface=ether1 src-port=80 content=Location: http://warning.rt.ru/ log=no log-prefix="" 

 2    block - https
      chain=forward action=drop tcp-flags=rst protocol=tcp ttl=equal:118 in-interface=ether1 src-port=443 packet-size=40 log=no log-prefix=""

Ну и в дополнении к этому Настройка BGP для обхода блокировок, версия 3.1. И немного Q&A / Хабр

P.S.
Ростелеком вроде не баловался подменой DNS, но все равно запросы лучше также в тунель отправлять

#5

Привет! Увы, это решение уже не работает должным образом, по крайней мере в Нижнем Новгороде :frowning:

#6

А DNS заворачиваете в туннель?

#7

DNS через DoH Cloudflare

#8
#9

Поделюсь своим способом.
Мой провайдер осуществляет блокировку интересным способом, отправляя FIN,ACK пакет после ClientHello. Видимо они думали что это усложнит жизнь тем кто захочет обойти блокировку DPI.

для статьи
для статьи1129×401 35.5 KB

Фейковый пакет FIN,ACK мало чем отличается от других кроме всегда одинакового TTL=57 что недостаточно для выявления блокировки.

Но я нашел способ его выявлять практически со 100% гарантией.

Принцип работы
Мы создаем два правила. Первое помечает все соединения в которых мы нашли ClientHello пакет.
Второе правило ловит следующий пакет и проверяет его на FIN,ACK при условии что объем переданных пакетов в соединении не превышает 1000 байт. Значение в 1000 байт я подбирал экспериментально. Если 2-ое правило срабатывает то добавляем ip сервера в список для обхода блокировок.

Вероятность что в первых 1000 байт соединения, отсылая приветствие, мы получим пинок под зад стремится к нулю, следовательно нас блокируют.

Реализация

В IP-Firewall-Mangle создаем два правила:

Первое правило:

Посмотреть

rule1_1
rule1_1603×690 16.1 KB

rule1_2
rule1_2607×692 17.5 KB

rule1_3
rule1_3605×693 11.1 KB

Второе правило:

Посмотреть

rule2_1
rule2_1603×690 16.1 KB

rule2_2
rule2_2603×693 17.7 KB

rule2_3
rule2_3603×691 11 KB

Данный способ также хорошо подойдет если провайдер отсылает фейковый RST пакет, т.к мы отсекаем пакеты после 1000 байт и тем самым уменьшаем вероятность ложного срабатывания.