Утечки DNS, WebRTC и IPv6 в VPN: как проверить

VPN протекает, когда часть вашего трафика идёт в обход туннеля, а не через него. Проверять стоит три утечки: DNS (ваши запросы по-прежнему уходят к резолверу провайдера или локальной сети), IPv6 (туннель несёт IPv4, а устройство спокойно пользуется собственным IPv6-адресом) и WebRTC (браузер раскрывает адрес через функцию звонков и peer-to-peer, которую он использует для видео). Проверка занимает пять минут: подключитесь, откройте тест утечки DNS и запустите расширенную проверку, откройте страницу проверки IPv6, откройте страницу проверки WebRTC и ищите всё, что принадлежит вашей собственной сети. Если что-то нашлось, исправление почти всегда - настройка клиента, а не новый VPN.

Детали важны, потому что «тест на утечку DNS показывает Google» - не утечка, а «браузер работает, а игра не идёт через туннель» - утечка, и тесты помогают, только если вы понимаете, на что смотрите.

Что такое утечка и почему это важно#

Когда вы вводите имя в браузере, устройство спрашивает его адрес у DNS-резолвера. Тот, кто держит этот резолвер, получает список всех имён, которые вы ищете, с временем запросов, а тот, кто находится на пути к нему, может читать и изменять запросы, если они не зашифрованы. Без VPN этот резолвер - обычно резолвер вашего провайдера или тот, что выдаёт локальная сеть.

VPN с полным туннелем должен отправлять эти запросы через туннель к резолверу на дальнем конце. Утечка DNS - это случай, когда туннель поднят, сёрфинг идёт через него, а запросы всё равно уходят к локальному резолверу. Страницы скрыты; список того, что вы посещали, - нет.

Утечки IPv6 и WebRTC в одном отношении хуже: они раскрывают ваш настоящий адрес, а не только запросы. Это важно, если смысл VPN был в том, чтобы сервис не видел, откуда вы подключаетесь.

Как возникают утечки DNS#

Операционная система спрашивает все известные ей резолверы. Windows, начиная с Windows 8, использует умное разрешение имён в многоадаптерной конфигурации (smart multi-homed name resolution): она может отправить запрос через все сетевые адаптеры и взять первый ответ. Когда подняты и VPN-адаптер, и адаптер wifi, ваши запросы уходят и к резолверу сети wifi, и к резолверу туннеля. Опция block-outside-dns в OpenVPN существует именно для того, чтобы это остановить: она добавляет правила файрвола, которые отбрасывают DNS на других адаптерах, пока туннель поднят.

Клиент - прокси, а не VPN. Многие VLESS-клиенты на десктопе по умолчанию работают в режиме системного прокси. Приложение, которое учитывает прокси, отправляет имя хоста прокси, и тот разрешает его на дальнем конце - утечки нет. Приложение, которое прокси игнорирует, разрешает имя локально и подключается напрямую. Утекают и его DNS, и его трафик, а это проблема посерьёзнее утечки DNS.

Резолверы IPv6. В сети с двойным стеком устройство узнаёт резолверы IPv6 из объявлений роутера. Если VPN перенастраивает только DNS для IPv4, запросы могут уходить к резолверу IPv6 локальной сети.

Шифрованный DNS, настроенный на устройстве. Параметр «Частный DNS-сервер» в Android или безопасный DNS в браузере отправляют запросы выбранному вами провайдеру. Внутри полного туннеля эти зашифрованные запросы идут через туннель и ничего не раскрывают локальной сети; провайдер их всё равно видит. При раздельном туннелировании или в режиме прокси они могут идти напрямую.

Кэшированные ответы и ранние запросы. Имена, разрешённые до подключения VPN, остаются в кэше, а приложения, которые начинают синхронизацию в момент появления сети, делают запросы до того, как туннель поднят. Это утечка по времени, и именно с ней работает kill switch.

Как прокси-клиенты обращаются с DNS#

У клиентов на основе Xray больше движущихся частей, чем у приложения WireGuard, поэтому полезно знать режимы.

В режиме SOCKS у Firefox есть отдельная настройка «Отправлять DNS-запросы через прокси при использовании SOCKS v5» в параметрах соединения; если она выключена, Firefox разрешает имена локально, а через прокси идут только соединения. Chrome по умолчанию отправляет имена хостов прокси SOCKS5 для удалённого разрешения.

В режиме VPN или TUN клиенты на sing-box или Xray перехватывают DNS на виртуальном интерфейсе. Некоторые используют схему «fake IP»: клиент мгновенно отвечает на каждый запрос адресом-заглушкой из зарезервированного диапазона, например 198.18.0.0/15, а настоящее имя разрешается на сервере при установке соединения. Если при подключении вы видите адреса из этого диапазона в выводе nslookup, это клиент работает как задумано, а не сбой.

У клиентов есть и собственные настройки DNS - удалённый DNS для трафика через туннель и прямой DNS для трафика в обход него. Удалённым должен быть резолвер, доступный через сервер. Если вы задали правила, отправляющие местные сайты напрямую, то их запросы к вашему локальному резолверу - ожидаемое поведение; как взаимодействуют правила маршрутизации и DNS, разобрано в статье раздельное туннелирование простыми словами.

Проверка на утечки DNS#

Подключите VPN, затем воспользуйтесь любым из известных тестовых сайтов - dnsleaktest.com, browserleaks.com или ipleak.net. Они заставляют ваш браузер запросить серию случайных уникальных имён в домене, который они контролируют, и записывают, какие резолверы обращаются за ними к их авторитативным серверам.

На что смотреть в результатах:

• Хорошо: резолверы в стране VPN-сервера или принадлежащие публичному резолверу (Google, Cloudflare, Quad9), который ваш клиент настроен использовать через туннель.
• Утечка: любой резолвер вашего домашнего провайдера, мобильного оператора или сети отеля либо любой резолвер в вашей собственной стране, когда сервер находится в другой.

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

То же самое можно сделать из терминала. Некоторые DNS-операторы отвечают на специальное имя адресом резолвера, который спросил:

$ dig +short whoami.akamai.net$ dig +short TXT o-o.myaddr.l.google.com

В Windows без dig:

nslookup whoami.akamai.net

Выведенный адрес - исходящий адрес резолвера, каким его увидели Akamai или Google. Он должен принадлежать стороне VPN, а не вашему провайдеру. Это заодно проверяет и приложения помимо браузера, потому что здесь используется системный резолвер.

Утечки IPv6#

Многие конфигурации VPN несут только IPv4. Если сеть выдаёт вашему устройству IPv6-адрес, а туннель с IPv6 ничего не делает, то каждый сайт, доступный по IPv6, открывается напрямую, с вашим настоящим адресом, а сайты на IPv4 идут через туннель. Google, Facebook, Netflix, сайты за Cloudflare и большая часть крупного веба доступны по IPv6, так что это не экзотика.

Проверьте это на странице проверки IPv6 (стандартная - test-ipv6.com) или из терминала:

$ curl -4 https://ifconfig.me   # should print the VPN server's address$ curl -6 https://ifconfig.me   # should fail, or print an address not your own

Способы исправления в порядке предпочтения:

1. Клиент, который направляет IPv6 в туннель. VPN, у которого на дальнем конце есть IPv6, несёт его; тот, у которого нет, всё равно должен захватывать ::/0 и отбрасывать его, чтобы приложения откатывались на IPv4 через туннель.
2. Настройка IPv6 в клиенте. У некоторых VLESS-клиентов есть параметр, управляющий использованием IPv6; выставьте его так, чтобы IPv6 либо туннелировался, либо блокировался.
3. Отключение IPv6 на адаптере, который вы используете с VPN. В Windows снимите флажок IP версии 6 (TCP/IPv6) в свойствах сетевого адаптера. Грубо, но эффективно и легко отменить.

Подробнее о том, как сети с двойным стеком выбирают между двумя протоколами, - в статье IPv6 и игровые серверы.

Утечки WebRTC#

WebRTC - то, что браузеры используют для видеозвонков и peer-to-peer-соединений. Чтобы установить звонок, браузер собирает адреса-кандидаты: свои локальные и свой публичный, каким его видит STUN-сервер. Веб-страница может запустить этот сбор несколькими строками JavaScript и прочитать результаты, не совершая никакого звонка.

Современные браузеры скрывают локальные адреса за случайными именами .local (mDNS), поэтому старый трюк с чтением вашего частного адреса 192.168.x.x в основном больше не работает. Публичный кандидат по-прежнему на месте. С VPN с полным туннелем STUN-запрос идёт через туннель и сообщает адрес VPN-сервера, и это нормально. Утечка случается, когда STUN-запрос идёт не через туннель: в режиме прокси, потому что WebRTC использует UDP и часто игнорирует прокси, или по IPv6 в обход туннеля.

Проверьте на странице WebRTC сайта browserleaks.com или на ipleak.net при подключённом VPN. Если появился ваш настоящий публичный адрес, устраните причину (используйте режим VPN вместо режима прокси, закройте брешь IPv6) или ограничьте WebRTC в браузере:

Отключение WebRTC ломает видеозвонки в браузере. Ограничение политики обработки - более мягкая середина.

Пятиминутная проверка#

Делайте это один раз для каждого устройства, после любого обновления клиента и в любой новой сети, на которую собираетесь полагаться.

1. Отключите VPN и запишите свои настоящие публичные адреса IPv4 и IPv6 и резолвер провайдера со страницы теста на утечки.
2. Подключите VPN.
3. Запустите расширенный тест на утечку DNS. Никаких резолверов провайдера или локальной сети.
4. Запустите тест IPv6. Либо IPv6 нет, либо он не ваш настоящий.
5. Запустите тест WebRTC. Никакого настоящего публичного адреса.
6. Из терминала выполните dig +short whoami.akamai.net, чтобы проверить и системный резолвер.
7. Откройте приложение, которое не является браузером, - лаунчер игры, почтовый клиент - и проверьте, что оно работает с включённым VPN. Если в режиме прокси оно перестаёт работать, значит, прокси оно никогда и не использовало.

В Windows после изменения настроек очистите кэш, чтобы старые ответы не путали результат:

ipconfig /flushdns

Исправления по платформам#

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

Утечки и приватный сервер#

На приватном сервере, которым вы управляете, «резолвер на дальнем конце» - тот, которым пользуется ваш сервер, а адрес, который видят сайты, - адрес вашего сервера. В линейке приватных VPN RE:NODE сервер работает на Xray с VLESS и Reality, у него свой адрес и ключ, на нём больше никого нет, и он находится в Германии - поэтому правильный результат теста показывает немецкий адрес и никаких резолверов вашего провайдера. Приложение Renode VPN для Windows подключается по ссылке, которую выдаёт сервер; на телефонах и Mac та же ссылка вставляется в v2rayNG, Hiddify, Streisand или Shadowrocket, и описанные выше тесты применяются к каждому из них одинаково. Режимы каждого клиента разобраны в руководстве по настройке VLESS-клиентов.

FAQ#

Тест на утечку DNS показывает резолверы Cloudflare или Google. Это утечка?

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

Может ли сайт увидеть мой настоящий IP через WebRTC при включённом VPN?

Только если трафик WebRTC идёт в обход туннеля, а это бывает в режимах только с прокси и при нетуннелированном IPv6. С полным туннелем найденный адрес - адрес VPN-сервера. Проверяйте, а не предполагайте.

Избавляет ли шифрованный DNS от необходимости проверять утечки?

Нет. Шифрованный DNS скрывает содержимое запросов от локальной сети, но если он идёт в обход туннеля, то всё равно раскрывает ваш настоящий адрес DNS-провайдеру, и ничего не делает для IPv6 или WebRTC. Проверяйте с ним включённым.

Почему дома тест проходит, а в отеле нет?

Разные сети выдают разные резолверы и по-разному настраивают IPv6. Отель с IPv6 обнаруживает утечку IPv6, которую ваша домашняя сеть только с IPv4 никогда не показывала. Проверяйте в каждой сети, от которой зависите.

Может, просто отключить IPv6 везде?

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