Сегодня, 19 сентября 2021 года, на провайдере Уфанет опять наблюдаются блокировки сети DHT.
Отправка UDP-запросов, начинающиеся с байтов 64 31 3a (d1:), приводят к блокировке по связке source port + destination IP + destination port в рамках UDP-сессии, т.е. если хотя бы раз был отправлен пакет, начинающийся с этих байтов, никакие пакеты больше с этого source port на этот ip-адрес и destination port доставляться не будут, до момента таймаута сессии connection tracking на DPI, который равен 4-5 минутам.
При этом, если начать сессию с отправки какого-то другого UDP-пакета (например, отправить просто букву A), а затем в другом/других пакетах отправлять DHT-пакеты, то блокировки не происходит.
Также можно разбить (фрагментировать) первый UDP-пакет в сессии на несколько пакетов: в первом отправить 64, а во втором 31 3a…. В этом случае также блокировки не происходит.
Команды для проверки доступности DHT, которые я выкладывал ранее:
dht.libtorrent.org:
nping --udp -g 12345 -p 25401 -c1 dht.libtorrent.org --data "\x64\x31\x3a\x61\x64\x32\x3a\x62\x73\x69\x31\x65\x32\x3a\x69\x64\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x85\xbd\x80\x66\x18\x56\x00\xfd\x39\x3a\x69\x6e\x66\x6f\x5f\x68\x61\x73\x68\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x4a\x6d\x72\xdb\x91\x7c\x54\xcc\x65\x31\x3a\x71\x39\x3a\x67\x65\x74\x5f\x70\x65\x65\x72\x73\x31\x3a\x74\x32\x3a\x1a\x2e\x31\x3a\x76\x34\x3a\x4c\x54\x01\x2d\x31\x3a\x79\x31\x3a\x71\x65"
router.bittorrent.com:
nping --udp -g 12345 -p 6881 -c1 router.bittorrent.com --data "\x64\x31\x3a\x61\x64\x32\x3a\x62\x73\x69\x31\x65\x32\x3a\x69\x64\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x85\xbd\x80\x66\x18\x56\x00\xfd\x39\x3a\x69\x6e\x66\x6f\x5f\x68\x61\x73\x68\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x4a\x6d\x72\xdb\x91\x7c\x54\xcc\x65\x31\x3a\x71\x39\x3a\x67\x65\x74\x5f\x70\x65\x65\x72\x73\x31\x3a\x74\x32\x3a\x1a\x2e\x31\x3a\x76\x34\x3a\x4c\x54\x01\x2d\x31\x3a\x79\x31\x3a\x71\x65"
Опция -g задает source port.
Клиенты BitTorrent, по крайней мере некоторые, похоже, просто отбрасывают неизвестные пакеты по UDP, поэтому можно отправить какой угодно «мусор» реальным пирам в первом пакете, и DHT начнёт работать.
$ nping --udp -g 12330 -p 25401 -c1 dht.libtorrent.org --data-string A; \
nping --udp -g 12330 -p 25401 -c1 dht.libtorrent.org --data "\x64\x31\x3a\x61\x64\x32\x3a\x62\x73\x69\x31\x65\x32\x3a\x69\x64\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x85\xbd\x80\x66\x18\x56\x00\xfd\x39\x3a\x69\x6e\x66\x6f\x5f\x68\x61\x73\x68\x32\x30\x3a\x75\x6c\x1f\xb3\x52\xb2\xd2\x6d\xc9\xd5\x57\x7c\x4a\x6d\x72\xdb\x91\x7c\x54\xcc\x65\x31\x3a\x71\x39\x3a\x67\x65\x74\x5f\x70\x65\x65\x72\x73\x31\x3a\x74\x32\x3a\x1a\x2e\x31\x3a\x76\x34\x3a\x4c\x54\x01\x2d\x31\x3a\x79\x31\x3a\x71\x65"
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2021-09-19 17:59 UTC
SENT (0.0664s) UDP 172.17.0.2:12330 > 185.157.221.247:25401 ttl=64 id=16440 iplen=29
nping_event_handler(): READ-PCAP killed: Resource temporarily unavailable
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (29B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.08 seconds
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2021-09-19 17:59 UTC
SENT (0.0673s) UDP 172.17.0.2:12330 > 185.157.221.247:25401 ttl=64 id=34359 iplen=139
RCVD (0.1285s) UDP 185.157.221.247:25401 > 172.17.0.2:12330 ttl=52 id=54585 iplen=184
Max rtt: 61.242ms | Min rtt: 61.242ms | Avg rtt: 61.242ms
Raw packets sent: 1 (139B) | Rcvd: 1 (184B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.11 seconds
Строка RCVD (0.1285s) UDP 185.157.221.247:25401 > 172.17.0.2:12330 ttl=52 id=54585 iplen=184 говорит о получении ответа от реального узла dht.libtorrent.org, если вместо DHT-хендшейка сначала отправить ему букву “A” отдельным пакетом.
Предположительно, блокировка DHT вызвана использованием фреймворка NewNode в приложениях Навального для мобильных устройств, который использует эту сеть для поиска пиров.