Можете назвать источник или отправить полный документ (публично или приватно)? Выглядит не внушающе доверия: часть сервисов заблокируют в этом году, часть — в следующем? В списке отсутствует, как минимум, PIA из крупнейших, а они заявляли о том, что не будут сотрудничать с Россией.
Attempted transcription and translation:
Subject: Блокировка сервисов Роскомнадзором
Коллеги, добрый день,
У нас появился список VPN-сервисов, который РКН планирует заблокировать в ближайшее время.
Уточите, пожалуйста, блокировка данных сервисов может как-то повлиять на непрерывное ведение бизнеса в вашем ДЗО?Будем благодарны за оперативный ответ.
Конец опроса назначен на сегодня – 17:00, 18.03.2021
ДЗО Блокировка сервисов влияет?
Да/НетКомментарий
(если есть)
Subject: Blocking of services by Roskomnadzor
Colleagues, good afternoon,
We have a list of VPN services that RKN plans to block in the near future.
Could you please explain if blocking these services might somehow affect the uninterrupted conduct of business in your subsidiaries and affiliates [DZO]?A prompt reply would be appreciated.
The end of the survey is set for today - 17:00, 18.03.2021
DZO Does the blocking of services have an effect?
Yes/NoComment
(if any)
Порядок разработка сигнатур дла VPN-сервисов
Signature development for VPN services
Наименование VPN-сервиса
Name of VPN serviceГод
YearOpera VPN 2021 Vypr VPN 2021 Hola!VPN 2021 ExpressVPN 2021 PrivateTunnel 2021 KeepSolid VPN Unlimited 2021 Nord VPN 2021 Getcontact 2021 NumBuster 2021 Psiphon 2021 Turbo VPN 2021 SuperVPN Free VPN Client 2021 Hotspot Shield Free VPN 2021 Hola Free VPN Proxy 2021 Snap Master VPN 2021 Betternet WiFi Прокси 2021 Lantern 2022 X-vpn 2022 Cloudflare WARP 2022 Speedify VPN 2022 IPVanish VPN 2022 Tachyon VPN 2022 HideMyAss 2022 Torguarg 2022 Krot.io 2022 TrustZone 2022
Yes, I think it’s my last message on the forum.
I hope you will delete my account and any logs tied with me 
I’ve anonymized your account. Would be grateful for any additional information in PM or by email (full email .eml file would be useful).
I’ve also deleted the PDF file with service list. It contained the author’s name, I hope that wasn’t you.
Такое письмо действительно рассылалось внутри Сбера.
Очень интересно тем, что там идет речь не о сигнатурах для конкретных протоколов, а о сигнатурах для конкретных vpn-сервисов (и не совсем vpn-сервисов)
А есть пруфы? Просто верится с трудом. Это довольно сильно ударит по бизнесу в Ru сегменте.
Факт рассылки письма внутри Сбера, скриншоты которого выше, я подтвердил самостоятельно. Действительно ли его отправлял Роскомнадзор (или это подделка), и когда это произошло, мне установить не удалось.
Очень жаль. Спасибо за развёрнутый ответ!
Первые два идеально совпадают с анонсом Роскомнадзор - ВНИМАНИЮ КОМПАНИЙ, ИСПОЛЬЗУЮЩИХ В РАБОТЕ VPN-СЕРВИСЫ
А вот и почалось:
Ставлю сотку, что следующая жертва - Hola VPN
Ну, в списке выше он и так следующий 
В листе блокировки ничего касательно Opera VPN нет (по крайней мере, на первый взгляд). Предполагаю, что подобные заявления отныне будут сопровождаться включением сервисов в ТСПУ, без включения в публичный лист.
$ host api.sec-tunnel.com
api.sec-tunnel.com has address 77.111.247.18
api.sec-tunnel.com has address 77.111.247.17
{'return_code': {'0': 'OK'}, 'data': {'ips': [{'ip': '77.111.245.11', 'geo': {'country_code': 'AS'}, 'ports': [443]}, {'ip': '77.111.245.14', 'geo': {'country_code': 'AS'}, 'ports': [443]}, {'ip': '77.111.245.12', 'geo': {'country_code': 'AS'}, 'ports': [443]}, {'ip': '77.111.245.13', 'geo': {'country_code': 'AS'}, 'ports': [443]}]}}
{'return_code': {'0': 'OK'}, 'data': {'ips': [{'ip': '77.111.246.38', 'geo': {'country_code': 'AM'}, 'ports': [443]}, {'ip': '77.111.246.41', 'geo': {'country_code': 'AM'}, 'ports': [443]}, {'ip': '77.111.246.45', 'geo': {'country_code': 'AM'}, 'ports': [443]}, {'ip': '77.111.246.31', 'geo': {'country_code': 'AM'}, 'ports': [443]}]}}
Ни один из этих доменов и IP-адресов ни включён в лист.
Более того, сервисы все еще доступны и нормально работают. Походу они там ручками настраивают все эти блокировки на черных ящиках. В ближайшее время, возможно, могут быть отвалы инета, как были при начале замедления twitter, если они с первого раза нормально сделать не смогут
https://rkn.gov.ru/news/rsoc/news73700.htm
О принятии мер в отношении сервисов обхода ограничения доступа к противоправному контенту
17 июня 2021 года
В соответствии с регламентом реагирования на угрозы обхода ограничений доступа к детской порнографии, суицидальному, пронаркотическому и иному запрещённому контенту с 17 июня 2021 года вводятся ограничения на использование VPN-сервисов VyprVPN и Opera VPN.
Данные VPN-сервисы отнесены к угрозам в соответствии с Постановлением Правительства РФ от 12 февраля №127.
Ограничения не затронут российские компании, использующие VPN-сервисы в непрерывных технологических процессах.
В “белые списки” включены более 200 технологических процессов 130 российских компаний.
В соответствии с регламентом компании были проинформированы о возможности включения в “белые списки” 14 мая 2021 года.
В случае поступления новых запросов, после проведения проверки, “белые списки” могут быть оперативно дополнены.
On taking action against services circumventing restrictions on access to illegal content
June 17, 2021
In accordance with the regulations on responding to threats to circumvent restrictions on access to child pornography, suicidal, pro-drug and other illicit content, restrictions on the use of VPN services VyprVPN and Opera VPN are introduced from June 17, 2021.
These VPN services are classified as threats in accordance with the Decree of the Government of the Russian Federation №127 of February 12.
The restrictions will not affect Russian companies that use VPN-services in continuous technological processes.
The “white lists” include more than 200 technological processes of 130 Russian companies.
In accordance with the regulations, the companies were informed about the possibility of inclusion in the “white lists” on May 14, 2021.
In the event of new requests, the “white lists” may be promptly supplemented after the audit.
I searched “Постановление Правительства РФ 127” (“Government Decree of the Russian Federation 127”) and found “Об утверждении Правил централизованного управления сетью связи общего пользования” (“On Approval of the Rules for Centralized Management of Public Telecommunications Network”) at publication.pravo.gov.ru, dated 2020-02-12. Does that look like the right one? What does the decree say?
4 posts were split to a new topic: Обсуждение блокировки VPN-сервисов
Руководителям подведомственных
Минобрнауки России организаций15.06.2021 № MH-19/394
На № ____ от ____
Об использовании протоколов VPN
и VPN сервисовУважаемые коллеги!
Во исполнение письма Роскомнадзора № 07ТО-558-ДСП от 23.04.2021 г. об использовании протоколов VPN и VPN сервисов, а так же в целях противодействия угрозам устойчивости, безопасности и целостности функционирования на территории Российской Федерации информационно-телекоммуникационной сети «Интернет» и сети связи общего пользования, Центр мониторинга и управления сетью связи общего пользования Роскомнадзора планирует осуществить комплекс мер по ограничению использования сервисов VyprVPN, Opera VPN работающих по протоколам openvpn и Wireguard.
С целью исключения VPN соединений, работающих по протоколам openvpn и Wireguard из политик ограничения доступа Роскомнадзора, Минобрнауки России просит в срок до 30.06.2021 г. заполнить отчетную форму, размещенную в информационной системе «Система формирования сводной отчетности Минобрнауки России», расположенную в сети Интернет по адресу https://svod.minobrnauki.gov.ru/WebSVOD/parusjs/.
Руководство пользователя по заполнению отчетной формы дополнительно размещено в сети Интернет по адресу https://svod.minobrnauki.gov.ru/index.php?do=cat&category=novosti-po-vedomstvennoy-otchetnosti.
Приложение: Руководство пользователя по заполнению формы «Роскомнадзор_21» в информационной системе «Система формирования сводной отчетности Минобрнауки России» на 11 л. в 1 экз.
To the heads of organizations subordinated to the
Ministry of Education and Science of Russia15.06.2021 № MH-19/394
At № ____ from ____
On the use of VPN protocols
and VPN servicesDear colleagues!
Pursuant to Roskomnadzor letter № 07ТО-558-ДСП from 23.04.2021 on the use of VPN protocols and VPN services, and in order to counter threats to the stability, security and integrity of the Russian Federation information and telecommunications network Internet and public communication network, the Monitoring and Control Center of public communication network Roskomnadzor plans to implement a set of measures to restrict the use of services VyprVPN, Opera VPN working on protocols openvpn and Wireguard.
In order to exclude VPN connections working via openvpn and Wireguard protocols from the access restriction policy of Roskomnadzor, the Ministry of Education and Science of Russia requests filling in the reporting form posted in the information system “System of consolidated reporting of the Ministry of Education and Science of Russia” located on the Internet at https://svod.minobrnauki.gov.ru/WebSVOD/parusjs/ (archive) until June 30, 2021.
The User’s Guide for completing the reporting form is additionally available on the Internet at https://svod.minobrnauki.gov.ru/index.php?do=cat&category=novosti-po-vedomstvennoy-otchetnosti (archive).
Appendix: User’s Guide for filling in the form “Roskomnadzor_21” in the information system “System of consolidated reporting of the Ministry of Education and Science of Russia” on 11 pages, 1 copy.
I understand from this that Roskomnadzor plans next to block OpenVPN and WireGuard protocols, and the Ministry of Education and Science is asking organizations under its purview that might be affected by the blocks to submit a form by 2021-06-30.
С недавних пор, используется DPI, МТС. Помогает goodbyedpi. В последней версии Оперы 77.0.4054.146 уже сами разработчики Оперы отключают свой псевдо VPN для российских IP.
На текущий момент Роскомнадзор уже ведёт поэтапную процедуру блокировки VPN-сервисов. В первую очередь были введены ограничения работы сервисов Opera VPN и VyprVPN. Представители Роскомнадзора заявили, что VPN представляют собой угрозу для безопасности и стабильности российского сегмента интернета. Сейчас в список кандидатов на блокировку входят более двухсот техпроцессов российских компаний.
В июне 2021 года Роскомнадзор разместил на своём официальном сайте релиз о мерах, которые планируется предпринять в отношении упомянутых сервисов.
В релизе VPN упомянуты как «сервисы, используемые для обхода ограничений доступа пользователей к противоправному контенту».
В релизе указывается, что основанием для блокировки является регламент реагирования на подобные угрозы. Под «угрозой» подразумеваются алгоритмы, которые позволяют обходить ограничения на доступ к запрещенному контенту (призывы к суициду, детская порнография, реклама наркотиков и прочие противоправные материалы). Процедура блокировки сервисов Opera VPN и VyprVPN начиналась 17 июня 2021 года. Роскомнадзор обосновал свои действия Постановлением Правительства Российской Федерации от 12 февраля №127.
В релизе также было отмечено, что введенные ограничительные меры не коснутся тех российских компаний, которые применяют VPN в непрерывных техпроцессах.
https://rkn.gov.ru/news/rsoc/news73720.htm
Следующие VPN (Hola!VPN, ExpressVPN, KeepSolid VPN Unlimited, Nord VPN, Speedify VPN, IPVanish VPN). Блокировка (фильтрация) видимо также будет идти через DPI ТСПУ.
It’s strange to me that RKN lists the names of VPN services. @libneko made the same observation earlier. I had the impression that at least some of these VPN services are multi-modal: they are not built on only a single protocol, but may use many protocols (possibly obfuscated) in different situations. The VPN service’s name is just a “brand” for a combination of protocols. To me, it doesn’t make much sense to say simply “block ExpressVPN”. From a technical point of view, it would be more like: “block ExpressVPN in configuration A”, “block ExpressVPN in configuration B”, etc.
These observations make me think that the VPN plans are not so much about protocol detection and DPI. (Maybe in simple cases they are.) Rather, I see two more likely possibilities:
-
IP address enumeration. It may be that a VPN service has a relatively small number of server IP addresses. If the VPN uses that pool of IP addresses for all its connections, even obfuscated ones, you can block the VPN service entirely by blocking some IP address ranges.
-
Out-of-band pressure. The authorities could approach the VPN companies in real life, and say, “we want you to stop giving service to users in Russia” with threats of what will happen if they don’t. As far as I can tell, Opera VPN was not directly blocked by RKN/TSPU; rather Opera themselves made the VPN stop working in Russia. The proof is
"blacklisted_locations":["cn","ru"]in a configuration file. You can also see posts to that effect by moderators on the Opera forums:Mysterious disappearance of VPN settings from settings. | Opera forums
Only in Russia. The VPN was always “where allowed by law”, so if the legal authority tells them to turn it off it is gone.
VPN Disappear after Opera GX automatically restart | Opera forums
Opera’s VPN was always “where allowed by law”, so if the Russian government tells them to disable it in Russia that is what happens.
At ExpressVPN, they will not cooperate with RKN, they are full of nonsense, since they are representatives of Roskomnadzor, they were threatened with blocking me three years ago, I liked their VPN, I also use VPN Unlimited. But they also said that we are working fine in China and we will cope with Roskomnadzor and they will fight for our digital rights.
An acquaintance of mine lives in China and has been working there for over a year. He calmly uses VPN Unlimited and ExpressVPN using special protocols, and for ExpressVPN servers, only special ones can be selected that are given by technical support bypassing the Great Firewall helps, although it happens sometimes that ip servers are jammed only later, developers fix problems after updating DPI locks. Some prohibitions all around. Soon we will have a second North Korea, but understand one thing - those who do this want to control everything! And in order to punish and fine, prohibit, there is no logic in the actions, it will be worse further, they will come home and allow you to watch a movie, allow you to love your wife, allow you to eat and feed your children. And everything else will be banned. We bury ourselves … by introducing total censorship over our citizens.
Yes, this RKN release also looks strange to me. While for blocking “VPN Opera” is just a proxy, the provider’s DPI is used for the api.sec-tunnel.com authorization addresses and the pool of their proxy addresses. By using goodbyeDPI, blocking these addresses is bypassed.
As far as disabling the VPN setting from the Opera side, yes, it was bypassed by editing the config files. Problems appeared in the last two versions of the normal Opera installation (not portable). Now it is also possible to enable the Opera VPN setting from Russian IP addresses, but it is a little more complicated. I think that in this particular topic it is offtopic.
Intresting that there have been close to zero messages about Vyrp’s performance after the block. I have seen basically only 3 guys (one of them on Megafon) who said that it stopped working for them. Others were either silent or OK. Also I wonder if people for whom it stopped working contacted Vyrp in any way? Like if they advertise that they work in China, Russian DPI should be an easy thing?
Очередные VPN сервисы под вопросом.
Psiphon, Tunnelbear, Thunder и Redshield
Да тут понятно уже, что будут бомбить
Провайдеры с ТПСУ начали сегодня блокировать сеть DHT целиком. Видимо эхо от новых блокировок VPN сервисов. Ни один торрент-клиент не подключается и соответственно ничего не качает.
Техподдержка прямо говорит, что виноват ТПСУ, но ничего они сделать не могут, а следовательно предлагают искать способы обхода самостоятельно.
Я тебе больше скажу: они вроде как начали блокировать doh сервер от гугла. Почитай соседнюю тему
Для сети dht, кстати, кроме vpn можно что-нибудь сделать? Даже не представляю, как их можно замаскировать от ТСПУ
Какой у вас провайдер и регион?
Ростелеком Урал.
Некоторое время не было доступа к ntc.party. Это как-то связано с блокировками через ТСПУ или просто совпало ?
Несвязанные вещи, были проблемы на сервере.
Не проходит хендшейк WireGuard в мобильной сети Билайна до двух разных эндпоинтов. Из домашней проводной сети Искрателеком всё ок.
Совпадение?
Edit: Tailscale прямые соединения устанавливает.
https://www.opennet.ru/openforum/vsluhforumID3/125174.html#9
У мну не далее чем сегодня на одном жолтом опсосе внезапно два WG (разные vps, разные хостинги, разные страны) перестали работать на какое-то время. Очень надеюсь что это кривые руки, а не что-то ещё.
https://www.opennet.ru/openforum/vsluhforumID3/125174.html#101
Ростелеком сегодня начал блокировать DHT и протокол BitTorrent на своем DPI целиком. Ни один торрент ни одного дистрибутива GNU/Linux больше не качается.
Техподдержка отвечает, что торренты - это пиратство, поэтому они теперь блокируются.
Запросы DHT ушли, ответ обрезал DPI:
Кстати, утром и DHT начинал работать. Видимо DPI в режим байпасс перешел. Но к обеду снова обрезали.
Скачивание дистрибутивов сегодня починили - анноунсеры Fedora, Ubuntu и прочих вывели из блокировки, поэтому они начали качаться. DHT также не работает.
А dht.vuze.com (174.129.43.152) пингуется?
Другой замер через подключение провайдерского роутера напрямую:
Да:
$ ping 174.129.43.152
PING 174.129.43.152 (174.129.43.152) 56(84) bytes of data.
64 bytes from 174.129.43.152: icmp_seq=1 ttl=43 time=165 ms
64 bytes from 174.129.43.152: icmp_seq=2 ttl=43 time=164 ms
64 bytes from 174.129.43.152: icmp_seq=3 ttl=43 time=164 ms
64 bytes from 174.129.43.152: icmp_seq=4 ttl=43 time=164 ms
^C
--- 174.129.43.152 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 164.002/164.204/164.678/0.274 ms
Игра World of Warships, использующая UDP для игрового трафика, не работает у части пользователей.
На данный момент ситуация следующая:
Оборудование DPI у глобальных провайдеров блочит/режет некоторые порты, что в свою очередь влияет на невозможность залогиниться в игре и разлогины в бою. Мы совместно с провайдерами пытаемся решить проблему. Так как глобальных провайдеров интернета в России не так уж и много, затронуто много игроков с абсолютно разными местными провайдерами.
На текущий момент мы рекомендуем вам:
- Обращаться к своему провайдеру с жалобами на соединение в World of Warships.
- Сегодня после 09:00 (МСК) проверить: зайти в порт, выйти в бой, и если любая проблема повторяется (нелогин или дисконнект) собрать WGCheck с полной диагностикой сети (прислать нам) или Pingplotter - его можно продублировать своему провайдеру.
Пишу по памяти. Многое было мимолётно и так редко, что я долгое время думал что это случайности.
- три-два года назад на крупном локальном провайдер 100мбит начали резать p2p трафик ровно до 30 килобайт/сек. На несколько часов. Вот что странно примерно - в 01:00 ночи UTC+3. То есть нагрузки на сеть не было. А вечером в диапазоне 19-23 часа просадок почти не было. Потом были случаи что резали трафик до 30 килобайт/сек только после того как начинал скачивать что-то на большой скорости на все 100мбит. Если пиров на раздаче было мало то скорость достигала 30-40мбит и скорость не резалась.
Случалось это в среднем 1 раз в месяц, но это потому что я редко ночью что-то качал, так то может и это чаще бы происходило бы.
Да, и это было на весь p2p трафик, не только Bittorent.
Все спидтесты на разных сайтах показывали нормальную скорость. Но пару раз было что ограничивали скорость на часть обычного трафика. Лечилось тем, что надо было включить в русских соцсетях любое видео и тогда ограничения на обычный трафик снимались. Снимались ли на p2p в этом случае я уже не помню. Техподдержка мычала.
Года полтора назад это пропало. - Два года назад на локальном крупном провайдере начали периодически блокировать самые популярные DoH адреса. Сначала по домену, потом и по IP. малоизвестные работали, но таких было тяжело найти.
- В регионах на крупных федеральных провайдерах заблокированы многие популярные DoH адреса. Заблокированные даже малоизвестные от гигантов, которые можно найти только на форумах поддержки.
Полгода назад наблюдалось поочередное блокирование всех DoH адресов подряд. Причем сложилось впечатление что блокируют по сигнатурам, потому что через 1-12 часов после начала использования очень редких адресов блочились тоже. И по IP и по доменам. Через время можно было ротировать некоторые редкие DoH адреса назад, но я уже плюнул и пустил DNS трафик совсем в обход. Подозреваю что погоня за серверами с DoH идёт до сих пор. Обычный DNS трафик конечно же перехватывается и пускается через DNS сервера провайдера. - В регионах Bittorrent c DHT начали пробовать блокировать месяца 3 назад. На ростелекоме. Раздавал много и немного скачивал старого поднять паруса контента через приватные анонсеры и обычные публичные сервера. Ничего из новинок или запрещённого не было. В один момент трафик упал. Новые раздачи перестали скачиваться. Ни через DHT ни через анонсеры не находил пиров. qBittorrent показывал DHT 0 соединений. Пиры которые были подлключены - продолжали обмен трафиком со мной чутка времени.
- Сейчас наблюдаю что на тарифах 300МБИТ p2p+мосты tor+i2p трафик шейпится до 100МБИТ. На тарифах 100МБИТ даже на оптике p2p+мосты tor+i2p трафик шейпится до 60-70мбит. Возможно QoS у провайдера.
- и ещё очень много мелких непонятностей чьи закономерности выявить не успел.
Что имеем товарищи. Пока мы спим враг качается. Я предполагаю что РКН давно выучил урок и уже давно тестирует ограничения локально в регионах. И не на всех подряд, а точечно. И периодически. И в рабочее время. Очень тяжело их поймать. Ограничение DHT словил случайно так как в этот момент сидел дома на больничном.
Хотя DoH’у война уже давно объявлена по полной и это очевидно.
Доступность сайтов можно проверить, например, через 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 каналов и несколько СМИ запостили новости об этом).
Ростелеком сегодня начал блокировать 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.
https://vk.com/wall-4350621_21198
Уважаемые абоненты!
В последние несколько дней стали поступать жалобы на плохую работу Avito, World of Tank, World of WarShips.Мы начали разбираться и вот, что удалось выяснить в первом приближении. Проблемы, с которыми столкнулись наши абоненты, по всей видимости, связны с попыткам Роскомнадзора заблокировать некоторые сервисы VPN. Делается это при помощи ТСПУ, о которых мы много писали и говорили в прошлом году Всем доброе утро, независимо от того времени,.. | Март - оператор связи в Псковской области | VK. Именно таким способом блокировки можно объяснить то, что затруднения возникли не везде, а только на сетях части провайдеров, и то, что сами провайдеры оказались не в курсе того, что происходит, поскольку ТСПУ для нас “чёрный ящик” и, никто не сообщает нам о конкретных действиях и конкретных сетях, с которых собираются начать. В целом, ситуация напоминает “погоню за Телеграмом” в 2018 году.
Мы будем продолжать следить за тем, что происходит и пытаться анализировать инцидент, а для нас это именно сетевой инцидент, с технической точки зрения. И, конечно, будем держать вас в курсе новостей, если они будут.