Один из самых незаметных для пользователя способов утечки трафика в обход VPN — через DNS. Само VPN-подключение может честно показывать статус "подключено", но если запрос на определение адреса сайта уходит к DNS-серверу провайдера в открытом виде, провайдер видит, какие домены вы посещаете, даже не заглядывая в зашифрованный туннель. Хуже того: часть провайдеров идёт дальше и подменяет ответы — на запрос о заблокированном домене намеренно возвращается "такого адреса не существует", хотя сайт работает.

Почему нельзя просто доверять DNS от провайдера

Доверие к DNS-серверу провайдера в принципе не должно быть по умолчанию: помимо подмены ответов по заблокированным ресурсам, часть провайдеров стала ограничивать зашифрованные протоколы DNS (DoH, DoT) — то есть даже попытка обезопасить DNS-запросы шифрованием у части пользователей уже блокируется на уровне сети. Подробнее о том, как блокировки добрались до самого DNS-обхода, — в материале про блокировку DNS-обхода и роль шифрованного DNS.

Решение — не полагаться на DNS провайдера вообще. В Meridian каждому пользователю поднимается собственный DNS-сервер, который заворачивает запросы в туннель до серверов Google и Cloudflare, а не идёт напрямую к провайдеру. Это устраняет саму возможность подмены ответа: запрос физически не покидает зашифрованный канал. Тот же принцип реализован и на роутерных клиентах — с версией под OpenWrt и Keenetic, — и в мобильных приложениях, где имена сайтов теперь разрешаются сразу через два независимых сервера внутри туннеля вместо одного, так что резолвер провайдера вообще не участвует в процессе.

Вторая утечка: IPv6 в обход туннеля

Менее очевидный, но не менее реальный канал утечки — IPv6. Мобильные операторы всё чаще выдают телефону IPv6-адрес наравне с обычным. Если приложение туннелирует только IPv4-трафик, то запросы к сайтам, у которых есть IPv6-адрес, могут уйти напрямую через сеть оператора — при этом приложение будет по-прежнему показывать статус "подключено", создавая ложное ощущение полной защиты.

В мобильном клиенте Meridian эта утечка закрыта: весь IPv6-трафик теперь принудительно забирается в туннель наравне с IPv4, независимо от того, к какому именно ресурсу идёт обращение. Это тот же класс проблемы, что и раздельное туннелирование, о котором подробно — в материале про настройку split tunneling один раз без постоянного отключения VPN: если часть трафика не описана явным правилом, она рано или поздно найдёт путь в обход.

Что стоит проверить у любого VPN

Утечки DNS и IPv6 — это ровно то, что не видно в интерфейсе большинства приложений и что стоит спрашивать у любого сервиса отдельно, а не считать решённым по умолчанию. Признаки надёжного решения: собственный или явно контролируемый DNS-сервер внутри туннеля вместо DNS-сервера сети, в которой находится устройство, и отдельная обработка IPv6-трафика, а не расчёт на то, что весь трафик "как-то" пойдёт через IPv4-туннель.