Тихий доносчик: почему корпоративный VPN выдает ваше реальное местоположение

Удаленный подрядчик подписывает контракт с заказчиком, где прописаны жесткие требования к географии: вся разработка должна вестись строго из стран Европейского союза. Подрядчик добросовестно включает корпоративный VPN, настроенный на выделенный шлюз во Франкфурте. Проверка на сайтах определения IP подтверждает: немецкий адрес, никаких сомнений.

Спустя две недели служба безопасности клиента присылает уведомление об инциденте: система аудита зафиксировала вход во внутренний GitHub с IP-адреса домашнего провайдера на Бали.

Подрядчик не выключал VPN. Туннель не падал ни на секунду. Но корпоративный дашборд безопасности зафиксировал его настоящее местоположение с точностью до индонезийского провайдера.

Причина утечки крылась не в сбое туннеля, а во встроенной технологии современных браузеров — протоколе WebRTC.

Карнавальная маска со светящимся маяком

Реклама VPN часто обещает полную маскировку: достаточно нажать кнопку, и весь трафик пойдет по зашифрованному маршруту.

У операционных систем и веб-браузеров другие приоритеты.

Браузеры стремятся минимизировать задержку при звонках и видеоконференциях без промежуточных серверов. Для этого протокол WebRTC использует механизм ICE (Interactive Connectivity Establishment). Чтобы соединить двух собеседников напрямую, технология опрашивает внешний STUN-сервер обо всех доступных сетевых интерфейсах компьютера, включая прямое подключение к домашнему роутеру в обход виртуального адаптера.

Это напоминает появление на закрытом маскараде в карнавальной маске и темных очках, но с телефоном в кармане, который по Bluetooth транслирует ваше настоящее имя и домашний адрес на все датчики в коридоре.

Радиус действия Bluetooth ограничен холлом здания. Запрос WebRTC STUN улетает в открытый интернет за тридцать миллисекунд, передавая реальный домашний IP любому скрипту аналитики на открытой веб-странице задолго до того, как сработает шифрование VPN.

Двойная брешь: WebRTC и параллельные DNS-запросы

WebRTC — не единственный канал, выдающий реальную локацию. В операционных системах есть еще одна незаметная брешь:

1. Опрос интерфейсов через STUN: Любая страница с поддержкой аудиозвонков или скриптами таргетинга запрашивает через WebRTC список локальных IP-адресов. В ответ браузер отдает скриптам страницы реальный внешний адрес домашнего роутера.
2. Параллельное разрешение DNS (Smart Multi-Homed Name Resolution): В Windows ради ускорения загрузки страниц DNS-запросы часто отправляются параллельно на все сетевые интерфейсы: и через туннель VPN, и напрямую домашнему провайдеру. Домашний DNS отвечает на несколько миллисекунд быстрее. В результате провайдер видит все посещаемые внутренние домены компании, а внешние серверы фиксируют реальный регион пользователя.

Как закрыть утечки на рабочих местах

Устранение утечек требует настройки политик самого браузера и операционной системы, а не только надежды на кнопку подключения в VPN-клиенте:

1. Блокировка прямых запросов WebRTC: Через профили MDM (Mobile Device Management) в корпоративных браузерах настраивается политика WebRtcIPHandlingPolicy в режим disable_non_proxied_udp. Браузер перестает опрашивать домашние сетевые интерфейсы напрямую и пускает мультимедийный трафик строго через туннель.
2. Запрет параллельных DNS-запросов: На уровне политик операционной системы отключается механизм Multi-Homed Name Resolution. Корпоративный туннель (WireGuard, VLESS или OpenVPN) должен принудительно перехватывать все DNS-запросы без возможности отката к локальному роутеру.
3. Раздельные профили браузера для работы: Рабочие сервисы изолируются в отдельном управляемом профиле, где отключены сторонние расширения и жестко ограничены сетевые возможности фоновых скриптов.

Зашифрованный туннель без контроля браузерных настроек создает лишь видимость защищенности. Проверяла ли ваша служба безопасности, что показывает тест на утечку WebRTC на рабочих ноутбуках сотрудников?