Минцифры хочет заставить российские сервисы определять пользователей VPN. Но при этом не должны пострадать заграничные пользователи. Есть ли надёжный способ их отличить?
Пришла в голову мысль, что VPN может определяться на основании временнóго отклика.
Как отличить пользователя VPN от реального заграничного пользователя?
В браузере или через приложение делаем запрос и измеряем время отклика, и делаем определение времени пинга на внешний IP-адрес пользователя, если он заграничный. Если эти величины существенно различаются (как минимум на десятки миллисекунд, ведь трафик VPN должен из-за границы прийти), и разница стабильна по времени (т.е. это не плохой wi-fi) то это пользователь VPN. Правда адрес может не пинговаться, тогда можно запустить mtr и посмотреть время отклика последнего адреса с откликом, оно скорее всего близко к времени конечного адреса. Можно смотреть и время пинга предпоследнего адреса по маршруту, чтобы исключить задержку ответов на стороне VPN-сервера.
На мобильных и спутниковых сетях метод может давать ложные срабатывания, их можно исключить из проверки. Но на проводных сетях метод должен определять VPN достаточно надёжно. Или же у этого способа есть какие-то недостатки с точки зрения РКН, задача которого определять VPN, не мешая простым пользователям? В каком случае он может давать ошибки? Как защититься от этого администратору VPN-сервера, кроме как выставлять сервер максимально близко к пользователям? (а в России практически везде стоят ТСПУ, просто так такой сервер не поставишь).
по моему СМИ просто неправильно все трактовали. смысл гасить пользователей VPN, если многие не гоняют ру трафик зарубеж?
Cloudflare Warp egress.
По AS? Не даст финский домашний провайдер ip из AS24940 (HETZNER-AS - Hetzner Online GmbH).
Просто по AS фильтровать vpn сервисы и хостинг провайдеров. Для меня это выглядит как самая простая реализация.
Пользователь сидящий из РФ очень вряд ли домашний/мобильный ip из Европы получит.
То что Вы описали ниже может и работает, но это настолько сложно, что вряд ли этим будут заниматься (как минимум далеко не в первую очередь)
Датацентровые зарубежные IP естественно по умолчанию будут блокироваться (хотя они и так блокируются 16кб и прочими блокировками). Тут имеются в виду мелкие хостинги и так называемые “резидентские прокси”, которые по IP не отличаются от простых пользователей. Такие прокси сложнее и дороже, зато не блокируются так, как датацентровые.
Просто – обнаруживать IP принадлежащий ASN датацентра, а не ISP.
Не смогут обнаружить. Никакие пинги для этого использоваться не будут, это бред.
Лечится, – банально Warp (он как резидентский). Если сервис не уважает Warp, шлите нахер такой сервис.
Есть же сайты, которые показывают ваш IP, характеристики системы и заодно определяют, пользуетесь ли вы впн/прокси или нет. Почему бы точно так же не сделать? Список неблагонадежных IP (сообщит РКН), утечки DNS, WebRTC, несовпадение часовых поясов и т.д.
А еще можно переблокировать все нероссийские IP. Будет, конечно, некоторый сопутствующий ущерб, но что поделаешь… Лес рубят — щепки летят
Не знаю что тут можно обнаружить… Browser fingerprinting какой-нибудь, если используется раздельное туннелирование для координации атаки только.
Допустим один и тот же fingerpring, там сям разные IP => туннель.
Это почти невозможно обнаружить, если настроено не криво.
То есть уничтожить интернет? Нет.
Я не говорю про кривые сборки. А абсолют.
Я имею в виду, если некоторый сайт решает что IP не российский, то блокирует доступ. По-моему банки и госуслуги уже так делали или все еще делают.
WARP тоже не российский, если что…
А, да. Использовать рувпс, не иностранный. Как раз в данной статье нормальную надежную схему предложил, на данный момент решающую 100% проблем (типовых сценариев использования интернета).
Поэтому и нужен рувпс для получения ру egress.
Я имел в виду со строны сервисов, то есть траффик из ЕС в РФ.
Они слишком дорогие, иногда дороже роуминга, да и там есть ограничения по одновременно открытым TCP сессиям.
Просто трафик WARP из границы в РФ забанят. Очивидно же что сервер cloudflare не может подключаться к условному gosuslugi.ru сам и запрашивать страницы которые будет только пользователь запрашивать.
Через canvas в браузере можно будет определять по большей части кривые настройки. Например на yandex.ru будет один ip, а для yandex.com - другой. canvas при этом будет тот же.
или же обнаглевший ресурс, например yandex.ru сделает что-то типо такого
Promise.all([
fetch("https://ipinfo.io/json").then(r => r.json()).then(d => d.ip),
fetch("/get-ip-for-yandex-ru").then(r => r.json()).then(d => d.server_saw_ip)
]).then(([realIp, vpnIp]) => {
if (realIp !== vpnIp) console.log("split tunnel, real ip:", realIp);
});
Если yandex.ru будет видеть ip 1.2.3.4, а сделав запрос к ipinfo.io он увидет 5.6.7.8, то получается был спален vpn, упс.
Примечание
Но нужно что бы у зловредного ресурса был или Access-Control-Allow-Origin: * или конкретные домены вписаны, а так же ip checker проксировался, но тут как уж routing пользователь настроит.
По факту тут куча вариантов как может реализовать такой функционал ресурс в браузере (хоть и сложно), не говоря уже о приложении (разбор маха в помощь)
Многие разделяют на заблокированное и доступное, а не на русское и не русское. Такие большие конторы как яндекс хорошо задокументированы в фильтрах, но конечно никто не мешает чисто под закон им самим взять зарубежные ВПС для подобной проверки.
Очень давно в поисковике была надпись: вы сейчас в %Город ВПН%, при том надпись конечно была и просто при подключении к яндексу из зарубежного отеля, но полностью пропала, когда начал делить трафик.
В андройде слишком просто палить поднятое соединение, хоть на русский севрер, хоть на зарубежный, там в ОС какое-то обязательное сообщение всем приложениям, что включён ВПН. Очень давно моё рабочее приложение писало DioException [неизвестно]: null Ошибка: HandshakeException, а сейчас просто белый экран, типа, и так все должны понимать из-за чего
А зачем вообще пускать такой трафик через vpn? Если ресурс не заблокирован в рф, то и пускать не надо, просто нужны клиенты с раздельным туннелированием, задаваемые самим сервером, а на сервере просто все, что не заблокированно в рф, поставить в блок.
Если пускать через впн все, то у сервисов есть гораздо более простой способ определить, что человек использует впн, чем через какой то там пинг. Достаточно просто зайти в этот сервис с впн, и знать, что человек находится в рф (по геопозиции например, если дать разрешение). Да можно и просто блокировать, если сервис только для ру-сегмента, как будто ркн не пофиг на false-positive с мнимыми клиентами из Германии
При работе БС блокируется почти все) В этом и проблема. Условный Сбер - не пустил через ВПН, сбер не работает, пустил - Сбер сливает адреса. Если только как-то делать сложную маршрутизацию, но под каждый сервис это сложна. Да и стоит им новый какой-то адрес или домен добавить, который вы не учли, и все, маршрутизация не помогла.
Насчёт обязательного скорее всего нет. На android приложению нужны права android.permission.ACCESS_NETWORK_STATE и потом код в приложении на пример такого:
Код
val connectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
val networks = connectivityManager.allNetworks
val vpnActive = networks.any { network ->
val caps = connectivityManager.getNetworkCapabilities(network)
caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true
}
println("VPN active: $vpnActive")
Но VPN могут быть и корпоративные или для подключения ‘к себе домой’ для доступа к своеу серверу, так что это не 100% свидетельство обхода чего-либо.
Не знаю как на android, но на iOS нужно вручную дать разрешение на создания конфига, введя пин код, а так же легко удалить потом. А так на iOS так же, если другое приложение создаёт тунель, то первое падает.
Если на android можно так же регулировать кто может создавать интерфейсы, а кто нет, то это не должно быть проблемой. Если конечно приложение не откажется работать вовсе без такого разрешения
Я попробовал сделать тестовую страничку, работающую по такому принципу, и она действительно хорошо определяет, когда я зашёл с VPN.
Кинул ссылку пока своим знакомым из других стран, чтобы проверить, отличает ли она заграничных пользователей.
Вы здесь все додумываете не в том ключе.
- Любое Android-приложение может не просто определять наличие VPN, но и выбирать сетевой интерфейс, который используется для сетевых запросов. Для этого не нужны никакие привилегии, кроме стандартного internet. Можно выполнить запрос на получение IP-адреса через мобильную сеть/wi-fi/vpn, будучи подключённым ко всем трем сетям. Скорее всего даже в обход функции выбора приложений, которые маршрутизируются через VPN — предполагаю, что она контролирует только основной маршрут (нужно проверить).
- На ТСПУ видно весь netflow. Если пользователь из России, подключённый к забурежному VPN, заходит на российские сайты с этого же IP-адреса, к которому подключён, то это, очевидно, VPN, и какая-либо информация с российских сервисов для выявления этого факта не нужна.
Скорее всего изначальное заявление о «просьбе компаний выявлять VPN» — речь о чем-то другом, и нужно читать между строк. Рискну предположить, что речь о добавлении доп. телеметрии в их приложения для смартфонов.
Хоть я уже и ответил, суть в переносе точке наблюдения. Раскрою:
Нет, для правильной схемы
Надежного способа их отличить – невозможно.
Я проксирую трафик через рувпс, а оттуда – WARP.
Какой IP получают любые чекеры? WARP.
А у нас логи провайдера (netflow) и мы видим твой NAT IP. Значит сопоставим подключения к ру-сервисам и к туннелю.
Хорошо, тогда во-первых вам нужно два из трёх:
- Логи провайдера.
- Хостера
- Cloudflare
Причём чем больше людей с хостера проксируют в WARP, тем меньше РКН знает куда на самом деле идут подключения. Только по корреляции по множеству временных окон.
Всё. Проиграли.
Они наверняка уже это делают.
Люди всё пытаются закрыть все уязвимости/утечки IP адресов, пытаясь справляться с главной точкой наблюдения - ISP. А решается её переносом.
То есть это решение, как раз нацеленное на закрытие большинства уязвимостей в “100500 способах как обнаружить туннель”. Без него – они будут существовать всегда и все вы не найдете.