В открытый доступ попал внутренний документ с методикой поиска VPN и прокси на клиентских устройствах — предположительно разработанный в интересах регуляторов. Новость уже разошлась по профильным каналам с предсказуемым градусом паники. Паника как обычно не помогает. Давайте лучше разберем, как методика устроена технически, где у нее реальный потолок, и что конкретно создает ложные срабатывания для корпоративных пользователей, разработчиков и всех, кто держит на телефоне блокировщик рекламы.
Сразу зафиксирую границы. Это не инструкция по сокрытию обхода блокировок. Это анализ технической логики документа с упором на законные сценарии, которые эта логика задевает. Часть формулировок в документе выглядит как рабочий проект, а не окончательный регламент, и местами сами авторы честно признают ограничения метода.
Обход блокировок Роскомнадзора является нарушением российского законодательства. Использование VPN допускается только в случаях, предусмотренных законом: корпоративный доступ, защита персональных данных в рамках закона, иные законные цели. Материал ниже не является руководством по обходу блокировок и не заменяет правовую консультацию.
Три уровня проверки: как устроена методика
Документ делит процесс на четыре этапа с чёткой очерёдностью внедрения. Первый — GeoIP-анализ на серверной стороне. Второй (этап 2а) — анализ прямых признаков VPN и прокси на мобильных устройствах. Третий (этап 2б) — косвенные признаки на тех же Android и iOS. Четвертый — охват остальных платформ: Windows, macOS, Linux.
Приоритет мобильного сегмента объясняется прямо: больше половины клиентских устройств — телефоны, и, по оценке авторов, 80% приложений для обхода блокировок установлены именно там. Важный момент, который многие упустили: документ прямо запрещает непрерывный мониторинг. Проверка должна выполняться только при запуске приложения, аутентификации или ключевом действии (подтверждение платежа, указание маршрута). Постоянный сбор данных запрещён, потому что это влияет на трафик и батарею устройства.
| Этап | Что проверяют | Главные источники ложных срабатываний |
|---|---|---|
| 1: GeoIP | IP, страна, ASN, наличие в списках VPN/Tor/Proxy, признак хостинга | Роуминг, CGNAT, корпоративные шлюзы, CDN, пограничные регионы |
| 2а: прямые признаки | Системные флаги VPN/прокси на Android и iOS через стандартные API | Блокировщики рекламы, антивирусы, корпоративные профили, iCloud Private Relay |
| 2б: косвенные признаки | Имена интерфейсов, MTU, маршрутизация, DNS, NOT_VPN-флаг | Виртуальные машины, Docker, WSL, VirtualBox, антивирусы с сетевым фильтром |
| 3: прочие платформы | Windows, macOS, Linux — та же логика, расширенный охват | Разработческие окружения, контейнеры, WSL2, Hyper-V, QEMU |
GeoIP: самый дешевый метод с самым широким промахом
Серверная проверка — первый и самый быстрый этап. Сервис получает IP клиента, определяет страну и регион, смотрит ASN, проверяет признак хостинга и прогоняет адрес по репутационным спискам VPN, Proxy и Tor. В качестве основной референсной базы документ называет РАРС (реестр адресно-номерных ресурсов), до её запуска допускается MaxMind и IP2Location.
Алгоритм принятия решения у GeoIP-этапа довольно прямолинейный. Если серверная и клиентская проверки оба говорят «устройство в РФ, нет признаков хостинга» — решение «VPN не выявлен». Если IP имеет признак хостинга или входит в списки подсетей VPN/Proxy/Tor — «Выявлен VPN» независимо от страны. Расхождение между серверной и клиентской частью — «Требуется дополнительная проверка».
Фундаментальная проблема этого этапа в том, что документ сам честно её признаёт: резидентные прокси с обычным домашним IP провайдера по ASN и hosting-признаку не выявляются вообще. Новые VPN-серверы появляются быстрее, чем обновляются репутационные базы. CGNAT создаёт ситуацию, когда десятки пользователей сидят за одним IP, и неверная геолокация одного задевает соседей. Роуминг — отдельная история: точка выхода в интернет может физически находиться в стране пребывания, а не в стране оператора.
Интересный пункт, который статья в исходном варианте проигнорировала: документ предлагает использовать альтернативные источники геолокации — PLMN мобильной сети, идентификаторы базовых станций, BSSID Wi-Fi точек с координатами из публичных баз. При наличии согласия пользователя — GPS-координаты. Всё это идёт как вспомогательный фактор, не как основное доказательство, и координаты прямо не могут заменить GeoIP. Но сам факт, что в методике рассматривается геолокация по вышкам и Wi-Fi, интересен.
Android: ConnectivityManager как главный источник информации
На Android методика опирается на два системных API: ConnectivityManager и NetworkCapabilities. Это стандартные интерфейсы, не требующие root. Прямыми признаками VPN считаются: флаг IS_VPN в Score(Policies), наличие транспорта VPN в Transports, наличие VpnTransportInfo, свойство TRANSPORT_VPN у activeNetwork при проверке hasTransport.
Вот как выглядит типичный диагностический вывод при активном VPN:
Score(Policies): EVER_EVALUATED&IS_UNMETERED&IS_VPN&EVER_VALIDATED&IS_VALIDATED
Transports: WIFI|VPN
VpnTransportInfo{type=1, sessionId=PCAPdroid VPN, bypassable=false
А вот как выглядит обычная сеть без VPN:
Transports: WIFI Capabilities: NOT_METERED&INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VPN&VALIDATED
Это и есть косвенный признак этапа 2б: флаг NOT_VPN в Capabilities. Для обычных сетей он присутствует, при активном VPN — отсутствует. Такой флаг не является самостоятельным доказательством, но в сочетании с другими данными повышает уверенность детектора.
Что здесь важно понимать: любое приложение, поднимающее локальный VPN-интерфейс ради фильтрации трафика, будет неотличимо от настоящего VPN на уровне этих API. Так работают AdGuard, Blokada, большинство мобильных антивирусов с сетевой защитой, корпоративные агенты и часть приложений родительского контроля. Пользователь не использует VPN для обхода блокировок — но флаги говорят то же самое, что и при обходе.
Прокси на Android определяется через System.getProperty. Список характерных портов из документа:
- SOCKS: 1080, 9000, 5555, 16000–16100
- HTTP: 80, 443, 3128, 3127, 8000, 8080, 8081, 8888
- Прозрачные прокси: 80, 443, 4080, 7000/7044, 8082, 12345
- Tor: 9050, 9051, 9150
Как видно, среди «подозрительных» портов сидят 80 и 443 — то есть любой локальный прокси для отладки трафика попадает в эту же таблицу. Charles Proxy, mitmproxy, Proxyman — всё это стандартный рабочий инструмент разработчика, который по этим критериям неотличим от средства обхода.
iOS: закрытая система, которую сложно читать снаружи
На iOS доступ к системным данным существенно ограничен. Прямые признаки VPN практически недоступны для стороннего приложения — система не отдаёт нужные внутренние данные. Исключение: если само приложение создаёт конфигурации, которые могут быть расценены как средства обхода.
Из доступного: системный прокси можно прочитать через CFNetworkCopySystemProxySettings(). Наличие IP и порта указывает на прокси и означает, что весь трафик устройства идёт через него. На этом, по существу, прямые проверки на iOS заканчиваются. iCloud Private Relay в документе фигурирует в списке ложных срабатываний — его авторы методики предлагают не относить к запрещённому VPN автоматически.
Это означает фундаментальный предел метода на iOS: устройство Apple с VPN-клиентом, не создающим обнаруживаемой конфигурации через системные API, остаётся закрытым для таких проверок. Авторы документа это признают: ограничения iOS прямо упомянуты в разделе 6.6.
Косвенные признаки: где методика начинает фантазировать
Этап 2б — анализ косвенных признаков — самая скользкая часть документа. Сюда входят: имена сетевых интерфейсов (tun, tap, wg, ppp, utun и похожие), значения MTU (уменьшенный MTU характерен для туннелей), аномалии в таблицах маршрутизации, изменённые DNS-серверы.
Документ сам оговаривается чётко: косвенные признаки недопустимо использовать как самостоятельное основание для решения. Только для повышения точности в связке с прямыми. На практике именно здесь больше всего пересечений с законными сценариями. Docker создаёт виртуальные сети с нетипичными интерфейсами. WSL2 и Hyper-V — тоже. VirtualBox и QEMU оставляют виртуальные адаптеры. Антивирусы с сетевой фильтрацией меняют маршрутизацию. Всё это живёт на обычной рабочей машине разработчика.
Изменённый DNS — отдельный пример того, почему косвенное не равно доказательству. Ручной DNS есть у большинства технически грамотных пользователей: кто-то ставит 1.1.1.1 ради скорости, кто-то — ради фильтрации рекламы, кто-то держит Pi-hole внутри локальной сети. Без других сильных сигналов такой признак ничего не доказывает.
Что у методики не получается поймать в принципе
Документ честен насчёт пробелов, и это важно зафиксировать. VPN на маршрутизаторе — вообще вне области видимости клиентской проверки. Телефон или ноутбук, работающий через роутер с WireGuard или OpenVPN, не покажет никаких системных флагов VPN. Единственный шанс — GeoIP на серверной стороне, но если роутер стоит у провайдера с нормальной репутацией и адреса выхода нет в списках VPN, шанс детектирования невысок.
Резидентные прокси — ещё более слепое пятно. Если трафик выходит через IP домашнего провайдера в нужной стране, ASN и hosting-признак не срабатывают, а клиентские API не видят туннеля. Методика в этом сценарии практически беспомощна, и авторы это признают.
Новые VPN-серверы появляются быстрее обновления репутационных баз. Хорошо известная проблема индустрии: промежуток между вводом нового сервера в эксплуатацию и его попаданием в blacklist — от нескольких дней до нескольких недель.
Как снизить риск ложного срабатывания без нарушения закона
Всё сказанное выше дает практический совет для тех, кто хочет, чтобы их устройство выглядело предсказуемо для автоматических систем — не ради сокрытия чего-либо, а чтобы не попасть под ложное срабатывание с последующими проблемами доступа к легитимным сервисам.
- Удалите старые VPN-профили и профили прокси, которыми давно не пользуетесь. На iOS они живут в Настройки — Основные — VPN и управление устройством. На Android — в Настройки — Сеть — VPN.
- Проверьте настройки прокси в параметрах Wi-Fi-сетей: иногда прокси остаётся от корпоративной или гостиничной сети после поездки.
- Отключите неиспользуемые фильтры трафика и блокировщики рекламы, которые поднимают локальный VPN-туннель. Если приложение нужно — оставьте, но понимайте, что оно создаёт тот же системный след.
- На Windows удалите мёртвые виртуальные адаптеры после деинсталляции VPN-клиентов, эмуляторов и сетевых инструментов. Диспетчер устройств — Вид — Показать скрытые устройства — Сетевые адаптеры.
- На macOS и Linux проверьте активные интерфейсы командой ifconfig или ip addr: лишние tun/tap/wg-интерфейсы от давно удалённых программ иногда остаются.
- Для корпоративных сетей: ведите белые списки доверенных адресов и шлюзов. Документ явно рекомендует такой подход для минимизации ложных срабатываний.
Что методика говорит разработчикам приложений
Если ваше приложение использует системный VPN-режим Android не для обхода, а для фильтрации трафика — поднятый туннель с точки зрения ConnectivityManager неотличим от туннеля VPN-клиента. Это означает, что пользователи вашего приложения будут попадать под флаги детектора просто по факту его работы.
Минимум, что стоит сделать: прозрачно объяснять в интерфейсе, почему приложение поднимает локальный VPN и что происходит при его выключении. Реакция регуляторов на непрозрачные сетевые приложения в последнее время становится заметнее, и размытая граница между «фильтрацией» и «обходом» — не лучшее место для игры в угадайку.
Важный технический момент из документа: непрерывный мониторинг запрещён явно. Проверка должна выполняться только при запуске или ключевом действии. Если вы как разработчик строите систему детектирования на базе этой методики, это ограничение нужно уважать — иначе нарушаете собственный же регламент.
Реальная сила и реальный потолок
Сильная сторона методики — комбинирование нескольких источников. GeoIP сам по себе даёт много ложных срабатываний. Системные флаги VPN на Android сами по себе — тоже. В связке с историей подключений, динамикой сессий и верификацией по протоколам и портам точность растёт. Документ предлагает также использовать данные о сотовой вышке и историю успешных аутентификаций как вспомогательный контекст — это разумно.
Потолок тоже очевиден. VPN на роутере — невидим для клиентской части. Резидентные прокси — невидимы для GeoIP. iOS — закрытая система. Блокировщики рекламы создают те же системные следы, что и VPN. Виртуализация и контейнеры создают те же косвенные признаки.
Если попытаться превратить эту методику в автомат без белых списков, без истории подключений и без ручного разбора спорных случаев, поток ошибок будет ощутимым. Документ, впрочем, описывает это сам: ложноположительные срабатывания рассмотрены в отдельном разделе как известное ограничение, а не как досадная деталь реализации.
Практический вывод
Перед нами компиляция известных технических приёмов, собранная в последовательную схему с чёткой этапностью. Не революция и не серебряная пуля. Наиболее рабочая часть — GeoIP в сочетании с прямыми системными признаками на Android. Наименее рабочая — косвенные признаки, которые методика сама не позволяет использовать самостоятельно. Фундаментальные слепые пятна — VPN на роутере и резидентные прокси — остаются за пределами области видимости.
Для обычного пользователя совет скучный, но реальный: держите устройство в чистом сетевом состоянии, без залежей старых профилей и забытых фильтров. Чем предсказуемее сетевая картина вашего устройства, тем ниже риск попасть под ложное срабатывание. Для компании совет другой: не стройте автоматику без белых списков и без механизма разбора спорных ситуаций. Иначе система будет наказывать корпоративный VPN, антивирус и блокировщик рекламы с той же частотой, что и настоящий обход.
Может ли один только ручной DNS считаться доказательством VPN?
Нет. Документ прямо относит DNS к косвенным признакам и запрещает принимать решение только по ним. Публичный или локальный DNS используют для скорости, фильтрации рекламы, корпоративных политик и семейного контроля — это обычная практика.
Блокировщик рекламы на Android создаёт такой же системный след, как VPN?
Да, если приложение работает через локальный VPN-туннель. ConnectivityManager не различает «фильтрацию трафика» и «туннель для обхода» — флаги IS_VPN и TRANSPORT_VPN одинаковые. Это признанное ограничение методики.
VPN на роутере помогает обойти клиентскую проверку?
Клиентская часть методики его не видит: телефон или ноутбук не показывает никаких системных флагов VPN. Остаётся только серверная GeoIP-проверка, которая срабатывает, если IP выхода входит в репутационные списки.
iOS лучше защищена от такой проверки, чем Android?
В техническом смысле — да. Прямые признаки VPN на iOS практически недоступны для стороннего приложения. Документ сам признаёт это ограничением: анализ прямых признаков возможен только если приложение само создаёт соответствующие конфигурации.
Можно ли проверять присутствие VPN непрерывно в фоне?
Документ прямо запрещает непрерывный мониторинг: проверка только при запуске, аутентификации или ключевом действии. Постоянный фоновый сбор влияет на трафик и батарею устройства.
