Временны̀е методы определения VPN

Интересная идея, спасибо! У меня корректно обнаруживает (пробовал разные сервера и прямое подключение).

UPD: для повышения надёжности детектирования можно проверять является ли ip residential или принадлежит какому-нибудь дата-центру (по идее с таких адресов штатно только админы тамошних серверов будут ходить в инет, это ничтожная доля пользователей, кмк)

UPD2: а если уж добавить проверку соответствия часового пояса местоположению ip, и наличия языка старны местоположения ip в Accept-Language..

UPD3: и ещё на TTL можно же смотреть(?), выявив количество хопов за внешним ip ;(

А разница может быть большой из-за неоптимального маршрута вашего чекера. Например, челу (клиенту) из Индии не повезло и он соединяется с VK (MSK) через США, а VK чекеру повезло и он соединился с индийским IP через Европу.

Все равно не понятно где у меня дыра))

Скажите, а как вариант имеет смысл на самом сервере\конфиге поставить тотальный блок всего русского (кроме заблокированного русского)? Да,минус удобства пользования, но зато понадежнее чем заблокированное -прокси. незаблокированое- директ

Правда,злоумышленники конечно могут поднять на зарубежных айпи свои определялки..но если нас роутинг через прокси ТОЛЬКО заблокированные ресурсы,то почти беспалевно.. а вот пользователям эппл неповезло.. там и per app нельзя, и нормальный роутинг не сделать чтобыТОЛЬКО заблокированное к прокси шло а все остальное напрямую/блок

Это VPS на Jino.ru, достаточно популярном хостинге.

Предположим условный мах/самех (или теперь любой другой софт из РФ типа банковского приложения) стоит на телефоне - тогда он сможет при включённом ВПН через заграничный чекер узнать IP, но не сможет эту информацию передать на свой сервер, т.к. тот заблокирован, верно?

Но что помешает ему передать эту сохранённую информацию после отключения ВПН?

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

  • Ассиметрия маршрутов. На mtr отвечать может не клиент, а промежуточный хоп.
  • E[HTTP_RTT] ≠ E[ICMP_RTT]

Или, например, другой подконтрольный сервис, не входящий в geosite:ru


офф-топ

Потому что конечные устройства не предназначены на всякую фигню с разделением чего-либо. Это пока-что здесь люди придумывают всякие костыльные схемы, вместо того чтобы воспользоваться нормальным решением с переносом точки наблюдения.

См. android.net.utls.SocketUtils.bindSocketToInterface.
Оно аннотировано как SystemApi, но, насколько я понимаю, через рефлексию его можно вызвать?

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

такая вероятность есть.но такая легкая настройка критически снижает площадь возможной атаки. особенно если в впн настроена маршрутизация- все напрямую кроме заблокированого+только паре приложений дан доступ к впн через per app настроку клиента впн

del

Контр-пример:
CDN, потом фейки SNI. Эту атаку ваша маршрутизация “только заблокированное” – не чинит. Либо Reality с заблокированным SNI, и там будет IP чекер.

Спровоцировать вызов браузера (если он в VPN) через CustomTabsIntent.

По сути нужно начинать с начала
Со своей операционной системы, потом браузера и только после всего этого ада только к VPN на минималках…
Супер

PS а так-же микроэлектроники и своего компьютера на своих чипах

Переусложнять не требуется. Локально это невозможно исправить полностью. Просто пофиксите это архитектурно на 100% закрыв любые утечки, настроив удобную прозрачную маршрутизацию.

Если коротко, перенесите точку наблюдения и ограничьте ущерб (бан выходного IP).

Детали, и дальнейшие обсуждения конкретного фикса можно продолжить в теме.

Метод не даёт 100 % уверенности в наличии или отсутствии VPN, но он не единственный и может комбинироваться с другими (например, признаком датацентрового иностранного IP, разными адресами на наших и иностранных чекерах, разными адресами в приложении и браузере, доступности отдельных заблокированных сайтов, наличия установленных приложений и признака активности VPN в системе, несоответствия часового пояса, языка, геолокации стране принадлежности IP и др.). К сожалению, совокупность признаков может достаточно надёжно отличить иностранного пользователя от нашего под VPN. И если сервисы по требованию Минцифры будут добавлять такие проверки, и ещё временно блокировать тех, кто пользуется VPN “в целях безопасности”, “в целях предотвращения утечек данных” - для массового пользователя это будет неудобно. Хотя опытные пользователи все равно найдут способы обхода (самый простой - пользоваться нашими сервисами с другого устройства и лучше через браузер), неудобство для массового использования приведёт к тому, что предложения подключения к VPN будут закрываться, пользователям придётся самим покупать VPS и поднимать там свои серверы, ещё и за дополнительный IP платить, чтобы входной не совпадал с выходным - это тоже решение не для всех. К сожалению, приходится признать, что такая стратегия борьбы с VPN правильнее, чем тупые блокировки, из-за которых ложатся банковские и прочие важные системы.

Хотя как хороший вариант - если в отдельных приложениях будет поддержка прокси, как в телеграме, и прокси будет стоять в домашней сети или где-то в России, и лучше работать не через socks, а через что-то более трудноопределяемое, например, HTTPS - это тоже позволит обойти такие ограничения, но потребует усилий от разработчиков приложений и изменения стандартов. Например, обычный прокси с поддержкой HTTPS открытым текстом принимает запрос CONNECT с указанием адреса для соединения, а это палится, наверное, нормальный HTTPS-прокси должен сначала устанавливать SSL-туннель, а потом уже в нём принимать запросы, тогда его трудно будет отличить от обычного веб-сайта.

Ещё такая мысль появилась, как операторы могут палить даже входные адреса VPN.
Они собирают netflow за небольшое время и группируют по пользователям, отправляют в Минцифры. Если чекер обнаружил VPN, а приложение обнаружило наличие сети российского оператора, посылается последовательность трафика с модуляцией по времени (например, 100 Кб в первую секунду, 0 во вторую, 50 Кб в третью и т.п.), а дальше идёт обращение к данным netflow этого оператора за это время (за небольшое время объём данных для анализа не такой большой) с поиском пользователя, у кого есть сессия, промодулированная похожим образом. Так можно определить входной адрес VPN и заблокировать его. Можно ещё послать пользователю СМС, что “мы спалили ваш VPN, это не запрещено, но мы за вами следим!”.
На мой взгляд вполне технически реализуемо, к сожалению.

Что значит совсем работать не будет? :wink: бинарка-то запустится :wink:
То, что не сможет подключиться к своему серверу из-за блока не значит, что не сможет зарубежные ip чекеры опросить, которые будут доступны через vpn..

И даже ещё проще - административным методом: приказать ру-хостерам внести в договор обслуживания запрет на vpn/proxy (под угрозой отъёма лицензии, например) и хостеры сами быстро начнут сканировать диски виртуальных серверов на предмет наличия openvpn/wireguard/etc..

На этом форуме кто-то писал, что vk cloud так делает уже сейчас ;(

Я давно уже применяю полнодисковое шифрование на VPS.

А как такой сервер автоматически перезагрузить? Всё равно же ключ где-то будет (grub?) - не по vnc же каждый раз заходить после того, как в ЦОДе его ребутнут (нечасто, но бывает).

Ну и потом тогда следующий шаг - сканировать ОЗУ виртуалки, гипервизор-то имеет к ней полный доступ ;(