VPN ещё вчера работал, а сегодня его уже нет. Частные серверы начали исчезать один за другим
Частные VPN-серверы стали попадать под блокировки значительно быстрее, несмотря на маскировку трафика. Администратор четырёх зарубежных серверов описал, как срок их работы сократился с нескольких месяцев до нескольких дней, и предложил объяснение, связанное с проверками VPN в российских приложениях.
Автор технического разбора столкнулся с четырьмя блокировками за шесть недель. Первый сервер перестал отвечать 22 сентября, проработав больше года. Второй заблокировали 28 октября после 41 дня работы, третий 31 октября после 38 дней, а четвёртый 1 ноября, всего через четыре дня после запуска. Три последних адреса попали под ограничения за пять дней.
Во всех случаях блокировка затрагивала конкретный IP-адрес. Проверка соседних адресов в подсетях /29 и /24 показала, что они оставались доступными. При этом заблокированные серверы продолжали устанавливать исходящие соединения с российскими сайтами. Позднее два из четырёх адресов снова стали доступны из России, один примерно через неделю. Состояние остальных автор проверить уже не мог.
Серверы использовали VLESS в сочетании с REALITY и транспортом XHTTP. Такая конфигурация позволяет маскировать VPN-подключение под обычный защищённый веб-трафик. Узлы размещались у разных хостинг-провайдеров, в разных странах и автономных системах. Несмотря на различия в инфраструктуре, все четыре адреса столкнулись с одинаковыми ограничениями.
Обычно для обнаружения VPN применяют DPI, технологию глубокого анализа сетевого трафика. Она позволяет распознавать характерные особенности соединений без расшифровки передаваемых данных. Однако автор обратил внимание, что два сервера, доступность которых автоматически проверялась одним клиентом, заблокировали с разницей в три дня. По его мнению, такая последовательность заставляет искать дополнительные причины.
Главная гипотеза связана с IP-адресами, которые видят мобильные приложения. Когда пользователь подключается к VPN, внешние сервисы обычно получают адрес сервера вместо адреса самого пользователя. Приложение может определить, что соединение идёт через иностранный сервер, и передать соответствующие сведения своему оператору. Если адрес затем попадает в систему блокировок, доступ к VPN прекращается независимо от используемого протокола.
Предпосылки для подобного механизма появились весной 2026 года. Минцифры направило крупнейшим российским интернет-компаниям методические рекомендации по выявлению VPN. В них предлагалось проверять географическую принадлежность IP-адресов, сравнивать их со списками ограниченных ресурсов и анализировать признаки защищённых подключений непосредственно на пользовательских устройствах.
В апреле исследователи RKS Global провели повторную проверку 30 популярных российских Android-приложений. Механизмы обнаружения VPN присутствовали во всех 30 программах, а 20 приложений ограничивали функциональность при выявлении защищённого подключения. Часть программ также передавала результаты проверки на серверы компаний. Однако наличие подобных функций само по себе не доказывает передачу конкретных VPN-адресов регулятору.
Автор разбора также не располагает прямыми доказательствами того, что российские приложения передавали адреса именно его серверов, после чего следовала блокировка. Разница во времени отключения узлов не исключает обнаружения средствами DPI или другими механизмами анализа трафика. Поэтому связь между проверками в приложениях и четырьмя блокировками остаётся гипотезой, а не установленной причиной.
Для проверки гипотезы администратор изменил архитектуру VPN. Главная идея заключается в разделении входного и выходного IP-адресов. Пользователь подключается к одному адресу, а запросы к сайтам и приложениям отправляются через другой. В результате сервисы видят адрес выходного узла, тогда как адрес сервера, принимающего VPN-подключения, не раскрывается через обычное определение внешнего IP.
Реализовать разделение можно с помощью дополнительного сервера, второго IP-адреса на существующем узле или промежуточной сети Cloudflare WARP. При таком подходе блокировка выходного адреса не обязательно лишает пользователей возможности подключаться к основному серверу. Однако схема требует правильной маршрутизации и не защищает от обнаружения самого входящего соединения средствами сетевой фильтрации.
Особое внимание автор уделил ошибкам конфигурации. Например, если резервный маршрут при отказе основного шлюза отправит трафик напрямую, сайты снова увидят входной IP-адрес. Аналогичная проблема возможна при неправильной обработке IPv6, DNS-запросов или настройке балансировщика. Поэтому при недоступности всех выходных узлов автор предлагает прекращать передачу пользовательского трафика, а не переключать его на прямое соединение.
Отдельную проблему создают российские сайты, ограничивающие доступ с иностранных IP-адресов. Для таких ресурсов автор предлагает дополнительный сервер в России, который обрабатывает местные подключения, а остальной трафик отправляет через зарубежную инфраструктуру. Подобная схема позволяет сократить число ситуаций, когда пользователю приходится вручную отключать VPN ради работы банковских приложений, магазинов и других сервисов.
Новую конфигурацию администратор запустил 1 ноября и проверял почти неделю. К моменту публикации разбора 7 ноября соединения продолжали работать без зафиксированных обрывов. Результат выглядит обнадёживающим на фоне предыдущих блокировок, однако недельное наблюдение за одной инфраструктурой не позволяет оценить долговременную устойчивость решения.
Масштаб изменений пока остаётся неизвестным. Наблюдения одного администратора показывают конкретные случаи адресных ограничений, но не позволяют установить единый механизм блокировок для всех операторов и регионов. Если гипотеза о передаче выходных IP-адресов через приложения подтвердится, одной маскировки VPN-трафика будет недостаточно. При этом разделение входного и выходного адресов не устранит другие способы обнаружения серверов, включая анализ соединений и ограничения целых диапазонов хостинг-провайдеров.