Ваш сервер видит выход VPN, а не посетителя

Посетитель подключается через коммерческий VPN, и ваше приложение записывает адрес выхода. Это не скрытая личность: это единственный адрес источника, который есть у TCP-соединения. Всё остальное, что люди называют обнаружением, — это вывод, надстроенный над этим единственным фактом.

Что на самом деле несёт запрос

Приложение видит адрес и порт источника соединения, завершённое рукопожатие и байты, которые клиент решил отправить. При полном туннеле этот источник — выход, общий для всех, кто им пользуется. При разделённом туннеле запросы могут приходить из туннеля или из локального соединения в зависимости от назначения. Если клиент и сервер находятся внутри одного VPN, источник — это внутренний адрес туннеля клиента, который обозначает конечную точку, а не местоположение.

Ни одно поле обычного запроса не несёт адрес, который был у клиента до туннеля. Заголовок пересылки — это утверждение клиента или прокси, и его можно опустить или подделать.

Обнаружение — это классификация, а классификация — это догадка

Практические методы — это списки известных диапазонов VPN и хостинга, задержка, не соответствующая заявленному региону, формы traceroute и поведение учётной записи. Каждый из них даёт вероятность. Корпоративный VPN может находиться на адресах, которые выглядят жилыми, жилой прокси может выглядеть как домашняя линия, а NAT оператора может выглядеть как диапазон хостинга.

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

Если VPN принадлежит вам, у вас есть надёжный сигнал, не имеющий отношения к обнаружению: выделите отдельный пул и сопоставьте с ним наблюдаемый источник. Это работает, потому что вы контролируете оба конца и можете документировать пул. Но это не обобщается на посетителей, которыми вы не управляете, и перестаёт быть надёжным в тот момент, когда пул используется совместно с другими сервисами.

Локальные доказательства против доказательств на стороне сервера

На самой машине туннель виден: виртуальный адаптер, маршрут по умолчанию, указывающий на туннельное устройство, изменённый resolver. Код, работающий там, может перечислить интерфейсы и поискать PPP, TAP или драйвер производителя.

Веб-страница не может прочитать ничего из этого. Обычный обходной путь загружает ресурс, который отдаётся только из внутренней сети, и считает успех доказательством использования туннеля. На самом деле он проверяет доступность: разделённый туннель, устаревший кэшированный файл или перехватывающий прокси дают одинаковый результат в обоих состояниях. Локальные доказательства остаются локальными.

Выбирайте средства контроля доступа, которые переживут неопределённость

Стройте контроль доступа на подтверждённой личности, состоянии устройства и авторизации для каждого ресурса. Эти предикаты описывают, кто спрашивает и чего он может достичь, и остаются осмысленными независимо от того, участвует ли туннель. Пришёл ли запрос через VPN — это слабый сигнал, дающий и ложные допуски, и побочные блокировки. Держите доказательство и решение в отдельных полях, чтобы у спорной блокировки было что проверить.

IP-геолокация — один из нескольких входов, а службы геолокации браузера могут использовать Wi-Fi или GPS, которые никогда не следуют за туннелем. Карта, которая всё ещё показывает город посетителя, — это доказательство о службах геолокации, а не доказательство того, что туннель не сработал.

Запишите, какой сигнал определил каждое решение. Когда клиент оспаривает блокировку, эта запись — разница между проверкой и спором.