Блокировка BitTorrent DHT

Сегодня, 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 в приложениях Навального для мобильных устройств, который использует эту сеть для поиска пиров.

Проверил сейчас на Теле2, нет такого.
Зачем это делать, если выборы уже закончились, тем более на ограниченном кругу операторов? Гораздо понятнее было бы именно в дни выборах запустить эту блокировку у всех.
В их действиях в последнее время все меньше логики… Хотя, может быть, это все как раз очень логично, только мы об этом узнаем позже.

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

Где-то через месяц у меня предстоит переход на провайдер Ростелеком(к сожалению) и очень переживаю за возможность пользования торрентов. Как бы не пришлось покупать vps и настраивать shadowsocks со всякими дополнениями к нему

$ 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"

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2021-09-20 20:22 RTZ 2 (чшьр)
SENT (0.0750s) UDP 192.168.0.174:12345 > 185.157.221.247:25401 ttl=64 id=20449 iplen=139
RCVD (0.1100s) UDP 185.157.221.247:25401 > 192.168.0.174:12345 ttl=52 id=63019 iplen=184

Max rtt: 34.000ms | Min rtt: 34.000ms | Avg rtt: 34.000ms
Raw packets sent: 1 (153B) | Rcvd: 1 (184B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.58 seconds
$ 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"


Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2021-09-20 20:23 RTZ 2 (чшьр)
SENT (0.0770s) UDP 192.168.0.174:12345 > 67.215.246.10:6881 ttl=64 id=19539 iplen=139
RCVD (0.2610s) UDP 67.215.246.10:6881 > 192.168.0.174:12345 ttl=42 id=59672 iplen=514

Max rtt: 183.000ms | Min rtt: 183.000ms | Avg rtt: 183.000ms
Raw packets sent: 1 (153B) | Rcvd: 1 (514B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.42 seconds

У вас нет блокировки. Пакеты уходят и приходят.
Выполните, пожалуйста, следующую команду:

tracert dht.libtorrent.org
Трассировка маршрута к dht.libtorrent.org [185.157.221.247]
с максимальным числом прыжков 30:

  1     1 ms    <1 мс     1 ms  192.168.0.1
  2    13 ms    <1 мс    <1 мс  100.79.0.1
  3    <1 мс     3 ms    <1 мс  10.1.139.2
  4     2 ms     2 ms     1 ms  10.1.139.17
  5     6 ms     3 ms     3 ms  10.0.20.221
  6     1 ms     2 ms     4 ms  10.17.0.154
  7    15 ms    10 ms     3 ms  194.186.77.173
  8     *        *       24 ms  mx01.Stockholm.gldn.net [79.104.235.78]
  9    24 ms    24 ms    26 ms  netnod-ix-ge-b-sth-1500.portlane.net [194.68.128.194]
 10    26 ms    25 ms    24 ms  be-1.pe3.sto1.se.portlane.net [80.67.4.137]
 11    24 ms    24 ms    24 ms  be-1-10.vbdc-cr4.glesys.net [80.67.0.193]
 12    31 ms    32 ms    33 ms  te-0-0-0-7.fbg-cr2.glesys.net [193.108.196.93]
 13    32 ms    32 ms    32 ms  te-2-1.fbg-pe1.glesys.net [193.108.196.94]
 14    32 ms    32 ms    32 ms  185-157-221-247-static.glesys.net [185.157.221.247]

Трассировка завершена.

Это идея на будущее для доработки nfqws и goodbyedpi
пока видится 2 варианта : fake для QUIC и zero/random для остального
мне раньше казалось, что DPI будут работать с UDP только stateless

а Ростелеком точно торренты блокирует или это под вопросом?

Ростелеком Санкт-Петербург не блокирует.