RKN will try to block the following VPN services

Доступность сайтов можно проверить, например, через ooni, либо вручную через curl — он напишет более-менее подробную причину недоступности.
Скачайте curl, наберите, например, curl -v https://dns.google/, и если нет ответа, выложите сюда вывод.

Так делает большинство мелких провайдеров, т.к. 20% качальщиков p2p забивают 80% канала провайдера. В свое время именно из-за этого перешел к Ростелекому.

Speedtest у всех уважающих себя провайдеров гонится через отдельную, всегда свободную трубу и часто вообще в обход шейпера, чтобы были красивые цифры на графиках и выше место в рейтинге.

Кстати, какой смысл сейчас блокировать DoH/DoT, если блокировки у всех давно не через DNS, а через DPI?

Вы обращались в их службу поддержки? Что они ответили? Если проблема наблюдается и сейчас, обратитесь. Чем больше жалоб, тем быстрее исправят ибо блокировка DHT - это явно их местная инициатива ибо через других провайдеров работает.

Блокировками занимается не РКН, а нанятый ими подрядчик.

Предполагаю, фильтр по размеру пакета, проверьте.

Дорогие абоненты Ростелекома, в частности те, кто пользуется его услугами в Московской области, здравствуйте! Не замечали ли вы проблем с установлением соединения WireGuard к любым хостам?
Лично я 2 дня назад обнаружил для себя, что WireGaurd перестал делать хендшейк в сети Ростелеком — пакет я могу отследить в своей сети, но не могу наблюдать его на сервере, с которым пытаюсь соединиться. При всём при этом через netcat пакеты на тот же порт уходят прекрасно. В следствие чего делаю вывод, что по каким-то причинам DPI у РТ настроен таким образом, что пакеты WG фильтруются.

В общем, как и ожидалось — проблема носит массовый характер. Пришлось быстро переводить все тоннели на порты а-ля 80, 443. Проблема также наблюдается и на других провайдерах, например, на Билайне.

Мегафон спб с wireguard на финском hetzner сервере, поймал момент, когда есть явный “провал” в коннекте, через некоторое время проходит, затем снова повторяется, уже 3 дня такие аномалии есть (вышки сотовой связи разные).


Вот, если кому интересно:

nping --udp -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"

Ответ должен быть таким, если DHT работает корректно:

Starting Nping 0.7.80 ( Nping — Network packet generation tool & ping utility ) at 2021-09-06 19:46 MSK
SENT (0.0028s) UDP packet with 111 bytes to dht.libtorrent.org:25401 (185.157.221.247:25401)
RCVD (0.1604s) UDP packet with 156 bytes from dht.libtorrent.org:25401 (185.157.221.247:25401)

Max rtt: 157.638ms | Min rtt: 157.638ms | Avg rtt: 157.638ms
UDP packets sent: 1 | Rcvd: 1 | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.16 seconds

На другой домен и порт:

nping --udp -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"

@personalfd, @valloon, попробуйте выполнить команду выше, чтобы проверить, репрезентативны ли в ней передаваемые данные, блокируются ли они вашим провайдером, пожалуйста.

Первый:

$ nping --udp -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 )
SENT (0.0051s) UDP packet with 111 bytes to dht.libtorrent.org:25401 (185.157.221.247:25401)
RCVD (0.0695s) UDP packet with 156 bytes from dht.libtorrent.org:25401 (185.157.221.247:25401)

Max rtt: 64.369ms | Min rtt: 64.369ms | Avg rtt: 64.369ms
UDP packets sent: 1 | Rcvd: 1 | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.07 seconds

Второй:

$ nping --udp -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.80 ( https://nmap.org/nping )
SENT (0.0054s) UDP packet with 111 bytes to router.bittorrent.com:6881 (67.215.246.10:6881)

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
UDP packets sent: 1 | Rcvd: 0 | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.01 seconds

router.bittorrent.com при этом, конечно же, пингуется?

Да:

$ ping router.bittorrent.com
PING router.bittorrent.com (67.215.246.10) 56(84) bytes of data.
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=1 ttl=51 time=210 ms
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=2 ttl=51 time=209 ms
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=3 ttl=51 time=209 ms
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=4 ttl=51 time=209 ms
^C
--- router.bittorrent.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 208.696/209.197/209.817/0.407 ms

Теле2 Санкт-Петербург — DHT отвечают (обе команды выдают ответ).
ОБИТ Санкт-Петербург (где был установлен ТСПУ и замедлялся твиттер) — DHT отвечают (обе команды выдают ответ).

спб, домру

nping --udp -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-07 03:46 MSK
SENT (0.0316s) UDP packet with 111 bytes to dht.libtorrent.org:25401 (185.157.221.247:25401)
RCVD (0.0577s) UDP packet with 495 bytes from dht.libtorrent.org:25401 (185.157.221.247:25401)
nping --udp -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.80 ( https://nmap.org/nping ) at 2021-09-07 03:50 MSK
SENT (0.0309s) UDP packet with 111 bytes to router.bittorrent.com:6881 (67.215.246.10:6881)
RCVD (0.1881s) UDP packet with 486 bytes from router.bittorrent.com:6881 (67.215.246.10:6881)

Блокировку DHT похоже сняли. Пакеты пошли, как и положено. qBittorrent при старте обнаруживает 72 DHT узла:

$ nping --udp -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.80 ( https://nmap.org/nping )
SENT (0.0032s) UDP packet with 111 bytes to router.bittorrent.com:6881 (67.215.246.10:6881)
RCVD (0.2007s) UDP packet with 486 bytes from router.bittorrent.com:6881 (67.215.246.10:6881)

Max rtt: 197.552ms | Min rtt: 197.552ms | Avg rtt: 197.552ms
UDP packets sent: 1 | Rcvd: 1 | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.20 seconds

Возможно, что либо тестировали возможность полной блокировки DHT только на одном Ростелекоме Урал, либо эта блокировка была личной инициативой провайдера.

Буду продолжать делать замеры.

UPD. Итого, хронология следующая:

  • 03.09.2021 года - полная блокировка торрентов (DHT и все аноунсеры были заблокированы, в т.ч. Ubuntu, Debian и Fedora). Торренты не качались вообще до позднего вечера.
  • 04.09.2021 года - анноунсеры популярных дистрибутивов вывели из под блокировки и хотя бы ISO образы начали качаться, но DHT сеть продолжала быть недоступной.
  • 07.09.2021 года - блокировку DHT похоже сняли, хотя неизвестно временно на время хайпа в СМИ (ряд Telegram каналов и несколько СМИ запостили новости об этом).
1 Like

Ростелеком сегодня начал блокировать DHT и протокол BitTorrent на своем DPI целиком. Ни один торрент ни одного дистрибутива GNU/Linux больше не качается. Тех поддержка Ростелекома отвечает, что торренты — это пиратство, поэтому они теперь блокируются на постоянной основе по требованию РКН. Надо бы как-то теперь оптимизировать Goodbye Dpi под это дело чтоб он мог обходить эти блокировки.

Рязань, провайдер МТС, проводной:

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2021-09-07 11:35 MSK
SENT (0.0548s) UDP packet with 111 bytes to dht.libtorrent.org:25401 (185.157.221.247:25401)
RCVD (0.0974s) UDP packet with 495 bytes from dht.libtorrent.org:25401 (185.157.221.247:25401)
 
Max rtt: 42.564ms | Min rtt: 42.564ms | Avg rtt: 42.564ms
UDP packets sent: 1 | Rcvd: 1 | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.10 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2021-09-07 11:35 MSK
SENT (0.0547s) UDP packet with 111 bytes to router.bittorrent.com:6881 (67.215.246.10:6881)
RCVD (0.2364s) UDP packet with 486 bytes from router.bittorrent.com:6881 (67.215.246.10:6881)
 
Max rtt: 181.631ms | Min rtt: 181.631ms | Avg rtt: 181.631ms
UDP packets sent: 1 | Rcvd: 1 | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.24 seconds

Блокировки не наблюдал, торренты качались исправно. Размер ответов как и у @personalfd больше 156 байт, не знаю влияет ли это на что-нибудь.
Ping до router.bittorrent.com

PING router.bittorrent.com (67.215.246.10) 56(84) bytes of data.
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=1 ttl=45 time=180 ms
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=2 ttl=45 time=180 ms
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=3 ttl=45 time=180 ms
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=4 ttl=45 time=180 ms
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=5 ttl=45 time=180 ms
64 bytes from 67.215.246.10.static.quadranet.com (67.215.246.10): icmp_seq=6 ttl=45 time=180 ms
^C
--- router.bittorrent.com ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 179.791/179.905/180.179/0.128 ms

Do you know, was there an RKN press release for the (Psiphon, Tunnelbear, Thunder, Redshield) announcement to banks, as there were for VyprVPN and Opera VPN?

Officially - no, I haven’t found it. In this case, the source of the information is a letter from the Central Bank of the Russian Federation.
The latest press release from the RКN for (Hola! VPN, ExpressVPN, KeepSolid VPN Unlimited, Nord VPN, Speedify VPN, IPVanish VPN)

How did you discover the protocol signature ^\x01\x00?

The first initiator-to-responder message (Section 5.4.2) is supposed to begin with \x01\x00\x00\x00, so apparently it would be possible to make the signature more conservative. But I don’t know, maybe there is a protocol extension or something that makes some of the reserved bytes non-zero.

Aha, somehow I missed the connection with uTP in all these threads. But I am still confused. The recent posts here about BitTorrent blocking were about the DHT protocol, not uTP. For example, “Запросы DHT ушли, ответ обрезал DPI”.

The DHT protocol does not resemble \x01\x00, as you observed; rather it looks more like d1:ad2:id20:... (i.e. Bencode). And by my reading, the uTP header may begin with \x00\x01, but not \x01\x00. (I actually don’t know much about BitTorrent protocols.)

RKN will try to block the following VPN services - #38 by valloon speculates that the blocking of the DHT protocol is accidental as the result of blocking VPNs, not the other way around.

What is my misunderstanding?

Ah, you’re right, I misread the length of the type and ver fields. As you say, they are 4 bits each, not 8 bits. So type=ST_DATA, ver=1, extension=0 would encode to \x01\x00. To be sure, I downloaded a torrent and I see UDP payloads beginning with \x01\x00. Thank you for the explanation.