Что происходит в момент обрыва туннеля
Соединение падает в открытое состояние. VPN добавляет маршруты, которые заворачивают трафик в виртуальный сетевой интерфейс. Когда процесс туннеля умирает или отваливается по таймауту, эти маршруты исчезают, а маршрут по умолчанию через Wi-Fi или Ethernet остаётся — и система продолжает доставлять пакеты, теперь напрямую через провайдера. Приложения пересоздают сокеты за секунды и шлют трафик с вашего настоящего IP — без единого диалога с ошибкой.
Обрывы — рутина. Переход с Wi-Fi на мобильные данные, ноутбук, проснувшийся из сна, капризная гостиничная сеть, перезапуск VPN-сервера — всё это рвёт туннель на мгновение. Во что это мгновение обойдётся, зависит от того, разрешено ли чему-нибудь покидать устройство, пока туннель лежит.
Что на самом деле делает kill switch
Kill switch — это набор правил файрвола, а не магия. Строгая версия разрешает только два вида исходящего трафика: пакеты, входящие в интерфейс туннеля, и собственные зашифрованные пакеты VPN-клиента к серверу. Если туннель упал, трафику приложений просто некуда деваться, пока он не вернётся.
Это меняет режим отказа, а не предотвращает отказы. С kill switch обрыв превращается в паузу соединения, которую вы замечаете; без него — в трафик с вашего настоящего адреса, которого вы не замечаете. Сети несовершенны, и туннель всё равно будет рваться — «закрыто при сбое» делает эти моменты безвредными.
Системный kill switch против переключателя внутри приложения
Разница — в том, что происходит, когда умирает само приложение. Kill switch внутри приложения — это код VPN-клиента, который следит за туннелем и блокирует трафик при обрыве. Он работает, только пока клиент запущен: если клиент упал или его убил оптимизатор батареи, защита умирает вместе с ним — ровно в тот момент, когда исчезает туннель.
Kill switch системного уровня прописывает правила в файрвол самой операционной системы, который проверяет каждый исходящий пакет независимо от того, какие приложения запущены. В Android это встроено: постоянный VPN плюс блокировка соединений без VPN заставляют саму ОС отказывать трафику вне туннеля — даже до старта приложения после перезагрузки. Грубый способ отличить одно от другого: принудительно убейте VPN-приложение во время сёрфинга — если страницы всё ещё грузятся, переключатель живёт в приложении.
Утечки DNS: запросы в обход туннеля
Утечка DNS означает, что ваши запросы имён уходят на резолвер, выданный локальной сетью, — обычно провайдерский, — хотя сам трафик едет по туннелю. Сайты видят VPN-адрес, но резолвер получает имя каждого сайта, который вы открываете, а это, по сути, журнал сёрфинга. Классический виновник — Windows: с несколькими активными интерфейсами она может опрашивать все параллельно и брать тот ответ, что пришёл первым.
Лечение из двух частей, и хороший клиент делает обе: направить систему на резолвер внутри туннеля и заблокировать DNS на всех остальных интерфейсах, чтобы шальному запросу было некуда идти. Потом проверить: прогоните тест утечек и посмотрите на список резолверов — если хоть один принадлежит вашему провайдеру, запросы утекают.
Утечки WebRTC: браузер раздаёт адреса
WebRTC — браузерная технология видеозвонков, и вызвать её может любой сайт парой строк JavaScript. Чтобы устанавливать прямые соединения, она собирает все адреса, по которым можно дотянуться до вашей машины: локальные и, спросив STUN-сервер, публичный. Страница может прочитать этих кандидатов без вашего участия.
С туннелем на всё устройство STUN-запрос едет внутри туннеля и обнаруживает адрес VPN. Опасны частичные схемы: прокси только для браузера или split tunneling, оставивший браузер снаружи, — там UDP-пакеты WebRTC выходят напрямую и раскрывают ваш настоящий IP.
Проверяйте, а не рассуждайте: наш бесплатный тест на /webrtc-leak-test/ показывает, какие адреса ваш браузер раскрывает прямо сейчас. Если среди них настоящий — переходите на туннель для всего устройства или отключите WebRTC в настройках браузера.
Утечки IPv6: туннель покрывает только IPv4
Многие VPN-конфигурации возят только IPv4. Если провайдер выдаёт ещё и IPv6 — а большинство мобильных сетей выдаёт, — система сохраняет рабочий IPv6-маршрут вне туннеля, а современные системы предпочитают IPv6, когда сайт поддерживает оба. Результат — выборочная засветка: сайты без IPv6 видят адрес VPN, сайты с ним — ваш настоящий, а тест только по IPv4 рапортует, что всё в порядке.
Чистых решений два. Лучшее — VPN, который правильно обращается с IPv6: туннелирует его вместе с IPv4 или ставит блокирующий маршрут, чтобы IPv6-пакеты отбрасывались, а не шли напрямую. Грубый запасной вариант — отключить IPv6 на устройстве или роутере. В любом случае проверьте: тест утечек не должен показывать ни одного IPv6-адреса, который не принадлежит VPN.
Как правильно протестировать свою схему
Гоняйте проверки в тех условиях, где реально живёте, — домашний Wi-Fi, телефон на мобильных данных, сеть кафе, — потому что утечки зависят от настройки DNS и наличия IPv6 в каждой конкретной сети. Вся процедура занимает минут пять:
- Запишите настоящий IP при выключенном VPN, подключитесь и убедитесь, что видимые IPv4- и IPv6-адреса сменились оба — наш /data-leak-checker/ показывает IP, DNS-резолверы и WebRTC за один проход
- Проверьте список резолверов: каждый показанный DNS-сервер должен принадлежать VPN и ни один — вашему провайдеру
- Оборвите туннель нарочно — передёрните Wi-Fi или принудительно убейте приложение — и посмотрите, грузятся ли страницы до переподключения
- Повторяйте после обновлений ОС и VPN-приложения: оба умеют тихо сбрасывать сетевые настройки