Утечки DNS и IP: что это такое и как их проверить
Вы включили туннель, индикатор горит зелёным — а тест всё равно показывает вашего провайдера и город. Так проявляются утечки DNS, IP и WebRTC: канал зашифрован, а отдельные запросы уходят напрямую и выдают вас.
Туннель шифрует то, что идёт внутри него, но сам по себе не гарантирует, что весь трафик туда попадает. Часть запросов способна уйти напрямую, мимо защищённого канала, — и именно они выдают вас: провайдера, город, а иногда и настоящий IP-адрес. Ниже три самые частые щели и способ проверить каждую за пять минут.
Три вида утечек простыми словами
Прежде чем что-то проверять, полезно понимать, что именно мы ищем. Утечки бывают трёх типов, и механизмы у них разные:
- Утечка DNS. Каждый раз, когда вы открываете сайт, устройство спрашивает у DNS-сервера, какому IP соответствует имя домена. Если этот запрос уходит к серверу вашего интернет-провайдера, а не через туннель, провайдер видит список сайтов, которые вы посещаете, — даже если сам трафик зашифрован.
- Утечка IP. Сайт или сервис определяет ваш реальный адрес вместо адреса VPN-сервера. По IP легко вычислить провайдера и приблизительное местоположение.
- WebRTC-утечка. Встроенная в браузеры технология для видеозвонков умеет узнавать ваши локальные и публичный IP-адреса напрямую, минуя настройки прокси и туннеля.
Почему DNS выдаёт вас чаще всего
DNS — это адресная книга интернета: она переводит понятные имена вроде example.com в числовые IP. Проблема в том, что классические DNS-запросы уходят открытым текстом и часто направляются к серверу, который прописан в настройках сети или назначен провайдером. Даже с активным туннелем система может по привычке спрашивать «свой» DNS — и тогда список ваших доменов виден на стороне сети.
Решение на уровне протокола — шифровать сами DNS-запросы. Стандарт RFC 8484 описывает DNS over HTTPS (DoH): запрос упаковывается внутрь обычного HTTPS-соединения, так что он неотличим от прочего веб-трафика и защищён от подмены. По документации Cloudflare, такой запрос идёт по порту 443 — том же, что и обычные сайты, — поэтому его сложно выделить в общем потоке. О том, что вообще даёт шифрование, мы писали в материале про основы шифрования, а чем смена DNS в принципе отличается от VPN — в статье VPN, proxy и DNS: в чём разница.
Утечка IP и коварство WebRTC
С «обычным» IP всё понятнее: если сайт видит адрес VPN-сервера, а не ваш — всё в порядке. Куда хитрее ведёт себя WebRTC. Это браузерная технология для звонков и передачи файлов напрямую между устройствами; чтобы наладить прямое соединение, ей нужно знать реальные адреса собеседников.
Для этого WebRTC обращается к так называемым STUN-серверам. Как поясняет документация MDN по WebRTC, STUN-сервер возвращает «server reflexive» кандидата — по сути, ваш публичный IP-адрес, каким он виден снаружи домашней сети. Браузер получает этот адрес и может передать его веб-странице через JavaScript, даже если весь остальной трафик идёт через туннель. Именно поэтому тест иногда показывает два адреса сразу: «правильный» от VPN и настоящий — от WebRTC.
Как проверить себя за пять минут
Это более глубокая проверка, чем базовая — если вы ещё не убедились, что туннель в принципе подключён, начните с материала как проверить, что VPN работает. Дальше — конкретно про утечки:
- Узнайте адрес без туннеля. Отключите VPN, откройте любой сервис вида «мой IP» и запишите адрес и провайдера — это ваша точка отсчёта.
- Включите туннель и обновите страницу. IP должен смениться на адрес и страну VPN-сервера. Если остался прежним — это утечка IP.
- Проверьте DNS. Откройте сайт с тестом DNS leak. В списке серверов не должно быть имени вашего домашнего провайдера.
- Проверьте WebRTC. Найдите онлайн-тест WebRTC leak. Если он показывает ваш публичный IP из первого шага — утечка есть.
- Повторите на другой сети. Особенно важно в кафе и аэропортах: об угрозах открытого Wi-Fi мы рассказывали в разборе про безопасность в публичных сетях.
Что делать и как помогает корректный туннель
Хороший клиент закрывает эти щели сам, не требуя от вас ручных настроек. На что обращать внимание:
- DNS внутри туннеля. Все DNS-запросы должны идти через тот же зашифрованный канал и к DNS-серверу VPN, а не к провайдерскому.
- Защита от обрыва (kill switch). Если соединение падает, трафик не должен утекать напрямую до восстановления канала.
- Контроль WebRTC. В браузере утечку закрывают расширением или настройкой, которая запрещает страницам запрашивать локальные адреса.
HamikVPN шифрует трафик целиком и заворачивает DNS-запросы в тот же защищённый канал, поэтому имена сайтов не утекают к посторонним DNS-серверам, а ваш настоящий IP остаётся скрыт от посещаемых ресурсов. Если же тесты стабильно показывают утечки даже при включённом клиенте — это тревожный сигнал; на что ещё смотреть, мы собрали в материале о признаках ненадёжного VPN.
