Заблокирован сайт vpngate.net со списком vpn серверов от волонтеров. Блокировка датируется началом августа. Тип блокировки похож на реестровый (без url: адрес с доменом), но в реестре сайт не обнаружен.

Блокируют на ТСПУ.
https://bitbucket.org/anticensority/russian-unlisted-blocks/src/master/readme.txt

На мобильном операторе Мегафон сайт vpngate.net не открывается даже через GoodbyeDPI.

Большую часть IP-адресов сайта блокируют через RST/ACK, оставшиеся – прежним способом (похож на реестровую блокировку rutracker и др.)

Блокируют сертификаты используемые серверами участников. Пострадал протокол SoftEther на 443 порту без поддержки TLSv1.3.
Возможно задели другие порты и/или протоколы (OpenVPN при обмене ключами c использованием TLSv1.2)

Что насчет SoftEther UDP? Он тоже использует сертификаты? Вроде ему нет нужды маскироваться под TCP. Под QUIC он тоже не косит.

Ethernet over UDP это Ethernet over HTTPS over UDP (TCP-over-UDP) c обфускацией. При желании сертификат можно расшифровать из сетевого трафика, но это же не QUIC. За всеми обфускаторами не угонишься. Вероятно для собранных адресов есть дополнительные блокировки. Например блокируют весь UDP, поскольку порты случайные, или что-то еще (есть где зацепиться).

Есть приложения где проверенные сервера vpngate добавляют бонусом к своим, если родного под Windows не хватило. Приложение == блокировка.

Похоже бинарник vpngate-client не совпадает с публикуемыми сорцами той же версии.

В коде:

					UINT size_of_padding = 19;

В бинарнике:

					UINT size_of_padding = Rand32() % 19;

Т.е. udp vpngate в фирменной проге тоже не работает? Хоть она и едкая, но… А вы собираете ее? Я собирал линуксовую 5 версию, работает. Но маршрутами надо самому рулить и нет vpngate.
Отличается код, ну может бардак (нет даже доков) или специально для запутывания цензора.

Пока ничего не понятно, но очень интересно. Сертификаты блочат, но неизвестно почему и что за приложение сливает. Сервера участников с SoftEther на 443 поддерживающие TLSv1.3 есть, примерно каждый третий, если японские сервера исключить. Разрыв невелик, чтобы выделять этот признак для блокировки.

Код не должен отличаться, это красный флаг. Они и так вырезали секретные части, отвечающие за скачивание более детального списка, без которого Ethernet over UDP неизвестно куда подключать (порты бывают разные для протоколов, “UDP: Supported” это заглушка)

Найден заблокированный сервер: public-vpn-97.opengw.net. Вероятно, блокировка напрямую связана с VPN Gate, cледов других сервисов не найдено. Блокируют по IP адресу. Другие public-vpn-xxx были доступны, 96 и 98, например, они ничем кроме адреса не отличаются.

del

Все стоящие VPN сервера участников проекта заблокированы на ТСПУ. Правила блокировки разные, что указывает на разные источники адресов. У одних блокируют весь транспортный протокол, других – паттерны протоколов. Похоже РКН добрался до приложений категории Б, использующих чужие сервера. Как минимум два мобильных VPN приложения предлагали проверенные сервера взятые у vpngate.

На сайте проекта заявлено 6k серверов онлайн. Блокируют на ТСПУ 3k адресов.

Сертификаты блочат, но неизвестно почему и что за приложение сливает.

Не знаю, как сейчас, но еще буквально год назад SoftEther элементарно детектировался active probing’ом. То есть подключаясь по HTTP к нему и делая запрос на определенный URL, сервер давал очень характерный ответ, позволяющий понять, что там именно SoftEther.

Can you give me a reference for active probing of SoftEther in Russia?

There was evidence of active probing for SoftEther in 2014 and 2015 in China (https://ensa.fi/active-probing/#probetype-softether, Figure 8). This is the first I have heard active probing could be used in other countries.

Да вы просто гений! Решили проблему VPN over UDP для Linux’овых клиентов. Я тут создал issue на своем кривом английском в официальном репозитории: Can't connect using VPN over UPD with NAT-T under Linux using vpncmd · Issue #2008 · SoftEtherVPN/SoftEtherVPN · GitHub Правда это уже 5 версия (имхо глючная и нестабильная, по крайней мере в OpenWrt, поэтому я юзаю 4ую), но баг гуляет еще со времен 4-ой. И, действительно, замена в коде SoftEtherVPN/src/Mayaqua/Network.c at master · SoftEtherVPN/SoftEtherVPN · GitHub

UINT size_of_padding = 19;

на приведенный вами вариант:

UINT size_of_padding = Rand32() % 19;

решило проблему. Только что пересобрал бинарник vpnclient под Арч, правда 4 версии, и коннект пошел. Для теста использовал SSL-VPN протокол с официального сайта vpngate.net Теперь надо покроскомпилить такой-же под OpenWrt для x86_64 (amd64) архитектуру и потестить на своем роутере. Если все пойдет нормально, то уже отписаться на соответствующих ресурсах - пусть накатывают фикс на разные релизы. Если конечно разрабам это вообще интересно.
P.S.
Я вот тут подумал - а может они специально это сделали, чтобы SSL-VPN по UDP фурычил только под Windows? Тогда не понятно, почему этот протокол прекрасно работает по TCP портам в обоих системах.

(порты бывают разные для протоколов, “UDP: Supported” это заглушка

Если речь идет о протоколе SSL-VPN Windows (comfortable) тот реальный порт можно подсмотреть, приконнектившись к такому серверу из списка, использую Windows клиент с их фирменным плагином. После установки соединения (обязательно выбирать вторую строчку VPN over UDP в диалоге инициализации соединения!) используем экспорт аккаунта через vpncmd утилиту в текстовый файлик и ищем строчку uint PortUDP. Там и будет нужный порт. Кстати, он всегда 0, если соединение идет через TCP и отличный от нуля если идет завертывание в UDP. В последнем случае порт TCP и строка uint Port игнорируется. Приоретет при чтении конфигурационного файла отдается UDP соединению и соответствующая строка обрабатывается первой. Вот интересно, можно ли как-то средствами Linux’а вытащить данные порты? Хотя, наверное, это закрытые куски кода и запихнуто это все в dll’ку плагина.

I don tknow about such cases in Russia, I just mentioned that it’s very easy to do.

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

if (p->Size == 39 && ...
	ok = false;

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

На гитхабе, в репе, хостится открытый код, он должен нормально работать через UDP. У SoftEtherVPN и VPNGatePlugin связь не прямая, а обратная, “баги” плагина через гитхаб не исправить.

А можно глупый нубский вопрос - а откуда у вас такая инфа? Вы реверс инжиниринг делаете что-ли под каким-нибудь виндовым отладчиком и дисассемблером?

Да

Вынужден признать вашу правоту. Добрался до роутера, но дальше получения адреса с сервера процесс не идет. Трафик тупо не туннелируется. Работает только под виндой даже без плагина, если импортировать файл с udp портом. Так что или проверка клиента идет или сервер тупо режет что-то. Кроме того на мой тикет мне ответили, что работа по udp не предусмотрена без закрытого плагина. Так что эту затею придется мне отбросить. И еще момент - при подключении по udp под виндой внешний ip такого сервера отличается от того, который прописывается для подключения. Походу используется какой-то виртуальный кластер или хаб.

Я осел. Все работает по udp после правки кода. Проблема была в том, что проверял я сервера из списка 219.100.x.x. Но не учел того, что помимо выдачи немного другого IP адреса там так же меняется и default gateway. У меня в статических маршрутах был прописан 10.21*.. для серверов не из универа японского, а для универских он другой - 10.2**... Так что если коннектитесь по udp не забывайте проверить таблицу маршрутизации и коректно указывайте шлюз, куда пойдет трафик.