Содержание статьи

Почему IPv6-утечки ломают анонимность именно сейчас

Что такое IPv6-трафик и почему VPN иногда его не трогает

IPv6 давно не теория. К 2026 году глобальное внедрение перевалило за 44-48 процентов трафика, а в ряде стран мобильные сети уже работают по схеме IPv6-only с NAT64 и DNS64. Красиво на бумаге, но есть одно но: многие VPN-сценарии исторически заточены под IPv4 и просто игнорируют IPv6, если вы явно не включили поддержку. В итоге часть приложений продолжает общаться по IPv6 мимо туннеля, как будто VPN нет. Тихо, незаметно, без всплывающих ошибок. Вот это и есть утечка, в чистом виде.

Простой пример. Вы поднимаете VPN, видите новый адрес IPv4 от провайдера VPN, расслабляетесь и открываете браузер. Сайт запрашивает AAAA-запись и устанавливает соединение по IPv6 напрямую через вашего провайдера доступа. IP от провайдера торчит наружу, куки живут как ни в чем не бывало, а вы уверены, что защищены. В другой вкладке WebRTC отправляет STUN-запрос и светит ваш глобальный IPv6. На графиках все хорошо, а по факту приватности нет. Обидно, правда.

Где образуются дыры: dual-stack, Happy Eyeballs, QUIC и WebRTC

Источников утечек несколько. Сетевой стек в 2026 активно использует стратегию Happy Eyeballs: клиент параллельно пробует IPv4 и IPv6 и побеждает тот, кто ответил быстрее. Если ваш VPN защищает только IPv4, выигрывает прямой IPv6. Второй момент: современные приложения общаются поверх HTTP/3 на QUIC, который поверх UDP, и часть VPN-клиентов слабо фильтрует выходящий UDP-трафик с адресами назначения типа ::/0, если фильтры настроены кое-как. Ну и вишенка — WebRTC. Даже если вы не ведете видеозвонков, браузер может выполнить STUN-обмен и засветить реальный IPv6.

Есть нюанс с DNS. Когда система или браузер включают шифрованный DNS, например DoH или DoQ, они могут отправлять AAAA-запросы минуя настройки VPN или системный резолвер. DNS-ответ подсказывает браузеру IPv6-адрес, и соединение идет напрямую. Это не магия, а особенности приоритизации транспорта. Плюс UWP и PWA-приложения порой держат собственные сетевые стеки, которые не полностью следуют глобальным политикам VPN-клиента. В итоге вы думаете, что все туннелируется, а часть пакетов гуляет вокруг.

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

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

Наконец, есть структурная проблема с NAT. В IPv4 NAT скрывает вас за общим адресом, а вот IPv6 изначально проектировался без NAT. Многие домашние сети получают префикс /56 или /64, и каждая машина имеет глобально маршрутизируемый адрес. Да, есть временные адреса и приватность на уровне RFC, но если трафик идет мимо VPN, вы светите реальный глобальный идентификатор. Это не катастрофа уровня «все пропало», но это сквозняк, который надо прикрыть немедленно.

Блокировать или туннелировать IPv6: выбираем стратегию

Два пути: вырубить IPv6 или провести его через VPN

Существует две базовые стратегии борьбы с утечками. Первая, проще всего, полностью отключить IPv6 на интерфейсах или в ядре и разрешать только IPv4 через VPN. Работает надежно, быстро, повторяемо. Минусы очевидны: некоторые сайты и мобильные сети в 2026 ожидают IPv6 и иногда деградируют, а временами приложения настаивают на QUIC поверх IPv6. Вторая стратегия более элегантна: включить полноценную поддержку IPv6 в самом туннеле. Тогда у вас есть IPv6-адрес от VPN-провайдера, маршруты ::/0 внутри туннеля и строгие правила файрвола снаружи.

Какую выбрать? Если вы хотите просто исключить риск на десктопе и не теряете функциональность — временно отключите IPv6. Если нужна максимальная совместимость, разумнее заставить VPN переносить и IPv4, и IPv6. Это чуть сложнее, потребует поддержки со стороны VPN-провайдера, зато будущие сервисы и сети не заставят вас лихорадочно чинить маршрутизацию. Просто помните: половинчатые меры в духе «вроде заблокировал пару префиксов» дают ложное чувство безопасности.

Технические механики: firewall, policy routing и blackhole

Когда вы блокируете IPv6 локально, есть несколько надежных механизмов. Самый базовый — отключить стек на уровне системы. Второй — использовать файрвол и жестко дропать весь исходящий inet6 на физических интерфейсах, кроме VPN. Третий — прописать маршрут по умолчанию ::/0 в blackhole, чтобы любой пакет на IPv6 уходил в никуда, если нет активного туннеля. В ряде случаев применяют policy-based routing: помечают пакеты маркерами и направляют их исключительно через интерфейс VPN, отбрасывая все остальное.

Если вы туннелируете IPv6, правила зеркальные. Вы добавляете маршруты ::/0 в интерфейс туннеля, получаете IPv6-адрес от провайдера VPN, и файрволом запрещаете любой исходящий inet6 вне этого интерфейса. В WireGuard это решается AllowedIPs типа 0.0.0.0/0, ::/0 и правилом killswitch. В OpenVPN — параметрами tun-ipv6 и redirect-gateway ipv6. Важно не забывать про DNS: резолвер должен выдавать AAAA и отправлять DNS-запросы через туннель, иначе часть трафика снова уйдет в обход.

Производительность и накладные расходы

С точки зрения скорости, грамотная блокировка IPv6 почти ничего не стоит, особенно если вы делаете это на уровне ядра и таблиц маршрутизации. Туннелирование IPv6 добавляет столько же накладных расходов, сколько и IPv4, обычно это плюс 3-7 процентов CPU на шифрование и обработку, иногда больше на старых ARM-чипах. В 2026 WireGuard на десктопах и роутерах с offload работает очень быстро, так что разговор о «потерянной скорости» чаще эмоциональный, чем технический.

Есть нюанс с временем установления соединения. Если вы неправильно настроили Happy Eyeballs на клиенте, он может пытаться IPv6 вне туннеля и ждать таймаут, пока файрвол дропает пакет. Это добавляет «липкости», когда сайт открывается на пару секунд дольше. Лекарство простое: корректно маршрутизируйте ::/0 в туннель или ставьте blackhole, а не полагайтесь на одинокое правило блокировки где-то в недрах приложения. Тогда связь либо идет правильно, либо не идет вообще, без подвисаний.

Windows 10, 11 и 12: практическая защита от IPv6-утечек

Быстрое отключение IPv6: графика и PowerShell

На Windows отключить IPv6 можно двумя способами. Самый человекопонятный: Сеть и Интернет, Изменение параметров адаптера, свойства нужного интерфейса, снимите галочку с Internet Protocol Version 6. Работает, но не всегда охватывает туннельные интерфейсы и виртуальные адаптеры. Более надежный способ — системный флаг DisabledComponents в реестре, но в 2026 Microsoft рекомендует осторожность. Проще и чище использовать PowerShell и netsh, чтобы не оставлять «полумеры».

Быстрые команды. PowerShell от имени администратора: Disable-NetAdapterBinding -Name "Ethernet" -ComponentID ms_tcpip6. Повторите для Wi-Fi. Или системно: netsh interface ipv6 set teredo disabled, netsh interface ipv6 set privacy state=enabled, и, если нужно радикально, Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name DisabledComponents -Type DWord -Value 0xff. После перезагрузки IPv6 полностью выключен. Но не переусердствуйте: если вы используете VPN с полноценной поддержкой IPv6, лучше настраивать маршруты и файрвол.

Фильтрация через Windows Defender Firewall и WFP

Чтобы не зависеть от галочек, добавьте строгие правила в файрвол. Встроенный Windows Defender Firewall позволяет создать исходящие правила, которые блокируют весь протокол TCP и UDP для профиля Private и Public на адресные семейства IPv6, исключая интерфейс вашего VPN. В интерфейсе это неочевидно, но через netsh можно: netsh advfirewall firewall add rule name="Block IPv6 out" dir=out action=block protocol=any profile=any interfacetype=any remoteip=any localip=any edge=yes. Затем создайте разрешающее правило для интерфейса VPN с адресами ::/0. Примените порядок: сначала deny any, потом allow для конкретного интерфейса.

Если хотите совсем точно, используйте WFP-политики через специализированные клиенты или групповые политики. Они позволяют фильтровать на уровне callout-драйверов и блокировать IPv6 до того, как пакет покинет стек. Для WireGuard проверьте, что AllowedIPs включает ::/0 и что в приложении включена опция killswitch, блокирующая весь трафик вне туннеля. Для OpenVPN добавьте в конфиг block-ipv6 если провайдер не поддерживает IPv6, или tun-ipv6 и redirect-gateway ipv6 если поддерживает.

DNS и режимы Always-on VPN

Частая мелочь, которая ломает всю картину, — DNS. В Windows 11 присутствует системный DoH, а некоторые сборки в 2025-2026 тестируют DoQ. Убедитесь, что зашифрованный DNS направлен через VPN. Проверьте параметр Encrypted DNS в настройках сети, укажите провайдера из списка или включите вариант «Автоматически через текущую сеть», если ваш VPN-клиент выставляет собственный резолвер. В противном случае AAAA-запросы улетят мимо туннеля, и вы снова получите прямое соединение по IPv6.

Еще одна важная практика — режим Always-on. В Windows это достигается как через параметры самого VPN-клиента, так и через политики MDM в корпоративной среде. Всегда включайте kill switch. Без него при переподключении или спящем режиме система мгновенно вернется к прямому IPv6, и пара запросов успеет уйти наружу. Это как забыть закрыть окно в мороз: вроде дом теплый, но тянет так, что чувствуешь кожей.

macOS и iOS: аккуратно с PF и профилями

Отключение IPv6 и выбор интерфейса

macOS традиционно аккуратна с сетями, но по умолчанию любит IPv6. Базовый шаг: networksetup -setv6off Wi-Fi и повторите для Ethernet. Это отключит IPv6 на конкретном сервисе, не ломая весь стек. Для обратного включения используйте -setv6automatic. На iOS прямой кнопки «выключить IPv6» нет, система решает сама. Поэтому если вы хотите железобетонную гарантию, идите в сторону туннелирования IPv6 внутри VPN-адаптера, а не пытайтесь «запретить все» на уровне мобильной платформы.

Если ваш провайдер VPN поддерживает IPv6, убедитесь, что у интерфейса utun появляется адрес из пула провайдера и маршрут ::/0. Многие клиенты WireGuard на macOS и iOS с 2025 года корректно добавляют AllowedIPs ::/0 и уважают опцию killswitch. Не забудьте проверить приоритет сервиса: networksetup -listnetworkserviceorder подскажет порядок. Поместите VPN выше Wi-Fi и Ethernet, чтобы система не пыталась умничать.

PF: простые правила drop inet6

Когда нужен строгий контроль, включите PF. В файле /etc/pf.conf добавьте строки типа block out on en0 inet6 all и block out on en1 inet6 all, оставив pass out on utun0 inet6 from any to any. Аккуратно загрузите правила: sudo pfctl -f /etc/pf.conf и включите PF: sudo pfctl -e. Это гарантирует, что IPv6 не уйдет наружу вне туннеля. На десктопе это практичный компромисс: вы не ломаете стек целиком, но создаете железную дверь там, где это важно.

Помните, что macOS любит сервисы Apple: iCloud Private Relay, Handoff, AirDrop. Private Relay может использовать собственные механики для шифрования трафика. Если вы хотите полный контроль, отключите его, иначе диагностика утечек усложнится. Не потому, что он плохой, а потому, что смешивает каналы. Сначала добейтесь стабильного поведения VPN, затем включайте дополнительные функции и снова тестируйте.

DNS и шифрование: DoH, DoQ и резолверы

В 2026 Safari и система поддерживают шифрованный DNS. На практике это значит, что ваш резолвер может работать по DoH или DoQ напрямую, если профиль конфигурации так указал. При использовании корпоративных или пользовательских профилей проверьте, какие резолверы применяются к конкретному сетевому сервису. Если DoH запущен на Wi-Fi, а VPN клиент не перехватывает его, вы снова получите AAAA вне туннеля.

Правило простое: резолвер должен жить внутри туннеля. Или вы явно дропаете любые соединения DNS вне интерфейса VPN, или настраиваете клиент так, чтобы он публиковал системный резолвер и Safari его использовал. Да, это кажется занудством, но как только вы один раз словите еле заметную утечку при спящем режиме, вы поймете, почему мы так упираем на DNS.

Linux: sysctl, nftables и умный WireGuard

Глобальное и выборочное отключение IPv6

На Linux самый прямой путь — sysctl. Запишите в /etc/sysctl.d/99-noipv6.conf параметры net.ipv6.conf.all.disable_ipv6=1 и net.ipv6.conf.default.disable_ipv6=1, затем sysctl -p. Это отключит IPv6 везде. Если нужна гранулярность, отключайте только на физических интерфейсах: net.ipv6.conf.eth0.disable_ipv6=1, оставив включенным на tun0 или wg0. Так вы получите работающий стек в туннеле и пустоту на выходе. Иногда используют параметр ядра ipv6.disable=1 в GRUB, но это кувалда: удобно для серверов, не всегда уместно на ноутбуках.

Для более тонкого контроля пригодится blackhole маршрут: ip -6 route add blackhole ::/0 metric 1000. Он отсекает любой исходящий IPv6, если только более приоритетный маршрут не прописан в туннеле. Это элегантнее, чем полагаться на одно правило файрвола, и отлично сочетается с policy routing. Если вы применяете NetworkManager, не забудьте сохранить метрики маршрутов и запретить автоматические IPv6-записи на физических интерфейсах.

nftables: стальные правила

nftables позволяет лаконично и жестко зажать утечки. Пример. table inet filter { chain output { type filter hook output priority 0; policy accept; oifname "wg0" accept; ip6 daddr ::/0 drop; } }. Логика простая: разрешаем все на интерфейсе wg0, а любой IPv6 наружу — дроп. Аналогично дропайте input, если не ждете входящих. Если вы туннелируете IPv6, меняйте политику: по умолчанию дропайте, а для wg0 разрешайте и IPv4, и IPv6, и добавляйте stateful-инспекцию conntrack, чтобы не резать обратные пакеты.

WireGuard в 2026 по-прежнему король скорости. В конфиге клиента укажите AllowedIPs = 0.0.0.0/0, ::/0 для полного туннеля. Добавьте Table = off и PolicyRouting, если хотите, чтобы управлять маршрутами самостоятельно. Обязательно включите PersistentKeepalive, особенно на мобильных сетях IPv6-only с NAT64, чтобы туннель не засыпал. И не забудьте oifname правила в nftables — это ваш kill switch. Если вы используете OpenVPN, проверьте параметры tun-ipv6, redirect-gateway ipv6, а также route-nopull и selective push, если провайдер отдает кастомные маршруты.

DNS: systemd-resolved, resolvconf и DoH-прокси

В современных дистрибутивах доминирует systemd-resolved. Проверьте, что интерфейс wg0 регистрирует свой DNS через resolvectl dns wg0 10.8.0.1 и что режим доменов корректный. Разумно выключить automagic для физических интерфейсов: укажите в NetworkManager ignore-auto-dns yes и настраивайте резолвер вручную. В противном случае AAAA-запросы могут убежать на DNS вашего провайдера и подсказать браузеру прямой IPv6.

Если вы хотите шифровать DNS, поднимайте локальный DoH или DoQ-прокси внутри туннеля: cloudflared, dnsproxy, dnscrypt-proxy. Важно, чтобы исходящие к апстримам шли через wg0, иначе опять мимо кассы. Простая проверка: curl -6 https://адрес-вашего-DNS-провайдера — должна идти через интерфейс wg0, а tcpdump -i eth0 не должен видеть ни одного пакета на 853 или 443 к DNS-хостам.

Android: IPv6-only сети и Always-on VPN

Всегда включенный VPN и полный туннель

Android уже несколько лет комфортно живет в IPv6-only у операторов. Это значит, что без правильного VPN ваш трафик будет выходить по IPv6 через NAT64, и вы точно не хотите утечек. Включайте Always-on VPN и опцию Блокировать соединения без VPN. Это встроенный kill switch, который обрывает весь трафик, если туннель падает. Клиент WireGuard на Android поддерживает AllowedIPs ::/0 и 0.0.0.0/0, так что сделайте его полным туннелем, а не сплитом.

Некоторые приложения любят собственные DNS или QUIC, поэтому проверьте, что у VPN-клиента есть функция блокировки локального LAN и фильтрации IPv6. На Android 13-15 приватный DNS включен повсеместно. Настройте его на адрес, доступный только через туннель, или оставьте Автоматически, если ваш VPN публикует резолвер. В противном случае вы получите AAAA-запросы к публичным резолверам напрямую через мобильную сеть, что уничтожит приватность в один клик.

ADB, OEM и дополнительные трюки

В стандартном интерфейсе Android отключить IPv6 нельзя. Теоретически можно использовать ADB и правки sysctl на рутованных устройствах, например, установить net.ipv6.conf.all.disable_ipv6=1. Но в 2026 это редкий путь: проще организовать корректный туннель с IPv6 и держать строгие правила в клиенте. Некоторые OEM-прошивки добавляют собственные оптимизации сети, которые могут задерживать трафик до установления VPN. Именно поэтому Always-on и блокировка без VPN — маст-хэв.

Проверяйте WebRTC в мобильных браузерах. В параметрах браузера отключите mDNS и прямые кандидаты, если есть такой переключатель, или используйте расширения там, где они поддерживаются. Это мелкие шаги, но они убирают ещё один источник светящегося IPv6-адреса. И конечно, тестируйте не только Wi-Fi, но и LTE или 5G. Много раз видели ситуацию: дома все чисто, вышел на улицу — тут же поймалась утечка через мобильную сеть.

Частные DNS и QUIC

Android любит скорость и включает QUIC там, где может, особенно в сервисах Google и мессенджерах. Если ваш файрвол или VPN-клиент не следит за UDP, утечки происходят исподтишка. Настройте в клиенте запрет на исходящий UDP вне туннеля, кроме локального DNS внутри VPN. Для Private DNS укажите доменное имя, которое резолвится только через туннель; так вы предотвратите попытки уйти наружу. Да, немножко танцев с бубном, но результат того стоит.

Маршрутизаторы: OpenWrt, MikroTik и Ubiquiti

OpenWrt: RA, DHCPv6 и политическая маршрутизация

На OpenWrt поток утечек чаще всего начинается с анонсов RA и DHCPv6. Если вы не хотите IPv6 наружу, отключите отправку RA на LAN, запретите префикс от провайдера и дропайте ip6 в firewall. Это просто. Но лучше — настроить VPN, который берет и IPv4, и IPv6, и раздает клиентам адреса через DHCPv6-PD из пула провайдера VPN. Тогда браузерам не придется гадать, куда идти, и Happy Eyeballs сработает в вашу пользу, а не против.

Для политики: установите policy-based routing пакеты, помечайте трафик из LAN и отправляйте его только через интерфейс VPN. Добавьте blackhole ::/0 в основной таблице, чтобы без VPN ничего не ушло. Для WireGuard на OpenWrt укажите AllowedIPs ::/0 и используйте option route_allowed_ips 1. В firewall-комментариях оставляйте заметки, чтобы через месяц вы понимали, почему так, а не иначе. Документация в конфиге — ваш лучший друг.

MikroTik RouterOS v7: тонкая настройка IPv6

В MikroTik у IPv6 есть собственный стек. Раньше многие просто удаляли пакет ipv6, но в v7 это уже избыточно. Настраивайте firewall: chain=forward family=ipv6 action=drop, исключая интерфейс WireGuard или IPsec, который вы используете. Для маршрутов задайте ::/0 через интерфейс VPN и повышенную метрику для любых внешних. В mangle пометьте исходящие пакеты из LAN и отправляйте их в policy routing таблицу, где единственный маршрут — через VPN.

Не забудьте про ND и RA. Отключите анонсы на LAN, если вы не раздаете адреса от VPN. Если раздаете — убедитесь, что префикс приходит от провайдера VPN и правильно анонсируется. Обычно этого достаточно, чтобы вообще забыть слово «утечка». Ну и включите fasttrack аккуратно: он иногда обходит часть правил, если вы не учли WireGuard интерфейс в исключениях.

Ubiquiti: EdgeRouter и UniFi

На EdgeRouter логика похожа: настройте firewall для семейства ipv6, запретите исходящий трафик на WAN, оставьте разрешения на туннель. В routing-table задайте маршрут ::/0 на интерфейс VPN. В UniFi UX интерфейсах добавьте правила на уровне сетей и клиентов. Проверьте, как контроллер распределяет DNS: он может отдавать клиентам внешние резолверы. Замените их на внутренние адреса VPN или запустите локальный резолвер, который сам ходит в апстримы по туннелю.

Критично протестируйте и Wi-Fi-гостевые сети. Там часто включены изоляция клиентов и собственные настройки DNS, которые с улыбкой обходят ваши глобальные политики. Одна забытая галочка — и телефоны гостей с радостью светят свой IPv6 мимо вашего прекрасного VPN. Не дайте случайности переиграть систему.

Тестирование: как убедиться, что утечек нет

Браузерные проверки: адреса, WebRTC и модули

Начинайте с простого. Выполните поисковый запрос на тему проверки IP, оцените, какие адреса видит сайт: IPv4 от VPN и отсутствует ли прямой IPv6. Затем включите инструменты разработчика в браузере и посмотрите сетевые логи. Если вы видите AAAA-запросы к резолверам вне туннеля — у вас проблема. Проверьте WebRTC через тестовые страницы, они покажут локальные кандидаты и глобальные адреса. Если среди кандидатов есть глобальный IPv6 вашего провайдера — настройка неполная.

Отключите в браузере автопереключение на DoH, если вы его не направили через VPN. В Chrome настройка Secure DNS должна указывать на резолвер, доступный через туннель. В Firefox используйте режим, где резолвер следует системным настройкам, или задайте свой. Да, это скучная рутина. Но вы один раз составите чек-лист и потом будете проходить его за пять минут, как по нотам.

CLI: curl, dig, ping6 и tcpdump

В терминале все честно. Выполните curl -4 https://example.test и curl -6 https://example.test. Первый должен идти через VPN, второй — либо через VPN, либо падать, если вы блокируете IPv6. dig AAAA домен и посмотрите, какой резолвер отвечает. traceroute -6 адрес покажет, не рвется ли маршрут наружу. tcpdump -i интерфейс ip6 позволит увидеть любой IPv6-трафик. Если вы видите пакеты на eth0 снаружи туннеля — найдена утечка. Исправляйте правила и повторяйте.

На Windows используйте Test-NetConnection -ComputerName домен -TraceRoute -InformationLevel Detailed и netsh trace start capture=yes report=no. На macOS смотрите nettop -m tcp и packet filter лог. На Android без рута сложнее, но полезно сравнить скриншоты адресов в нескольких приложениях проверки и сетевую статистику в клиенте VPN. Не ищите серебряную пулю. Ищите последовательность. Тогда результат предсказуем.

Автоматизация и алерты

Если безопасность критична, автоматизируйте. На Linux скрипт раз в пять минут запускает curl -6 к вашему контрольному хосту через туннель и железно проверяет, что ответ приходит и интерфейс правильный. Второй скрипт слушает tcpdump на физическом интерфейсе и отправляет алерт в мессенджер, если увидел ip6. На Windows PowerShell-скрипт проверяет маршрут ::/0 и наличие правил файрвола. Это не космическая наука, а простой контроль «лампочек на панели». И да, он спасает, когда кто-то случайно обновил драйвер и сбросил настройки.

В компаниях наладьте регулярные аудиты. Раз в квартал прогоняйте тесты на контрольных ноутбуках, телефонах и роутерах. Обновления систем и клиентов VPN коварны: одна новая фича DoQ — и вы снова ловите AAAA мимо туннеля. Рутинный чек-лист дешевле инцидента. Простая экономика.

Кейсы 2024-2026: из практики и без воды

Корпоративный ноутбук и сплит-туннель

Компания разрешила только бизнес-приложения через VPN, все остальное напрямую. На бумаге логично, на практике Teams и Zoom начали использовать QUIC поверх IPv6, и часть медиа ушла мимо туннеля. Внешние IP-адреса мелькали в логах партнеров. Решение: перевести профиль VPN на полный туннель, включить поддержку IPv6, добавить в Windows Firewall правило блокировки IPv6 вне интерфейса VPN, а в клиентах видеосвязи отключить принудительный QUIC. Итог: скорость на месте, утечки исчезли, пользователи ничего не заметили.

Урок простой. Сплит-туннель в 2026 требует очень точной каталогизации доменов, протоколов и транспортов. Если ваша команда не готова поддерживать этот зоопарк, лучше держать полный туннель и правильно маршрутизировать. Это скучно, но работает. И нервы целее.

Домашний роутер провайдера и Wi-Fi телефоны

Схема знакомая: провайдер выдал роутер с включенными RA и DHCPv6, пользователь поставил VPN-клиент на ноутбук, но телефоны по Wi-Fi продолжили ходить по IPv6 через обычный интернет. Итог — расхождение в поведении устройств и неожиданная реклама по гео. Решение: на роутере отключить RA в LAN, настроить OpenWrt с WireGuard и раздачей IPv6 из туннеля, для гостевой сети запретить ip6 целиком, а для основной — пропускать только через VPN. После этого на всех устройствах единая политика, а утечки ушли в прошлое.

Важный момент: телефоны не всегда уважают системный резолвер, если вы включили Private DNS. Поэтому настройте Private DNS на имя, доступное только через VPN, и проверяйте AAAA оттуда. Тогда не придется гадать, кто и куда уходит ночью.

Мобильная сеть IPv6-only и NAT64

Оператор перевел абонентов на IPv6-only с NAT64. Пользователь включил VPN без поддержки IPv6 и удивился: половина приложений не работает, а часть трафика уходит мимо. Решение: включить в VPN поддержку IPv6, разрешить ::/0 в WireGuard, проверить, что резолвер отдает адреса и для A, и для AAAA, а если нужно, использовать DNS64 внутри туннеля. Бонусом — активировать PersistentKeepalive, чтобы туннель не засыпал. Результат: все сервисы работают, утечек нет, задержки стабильные.

Вывод: эпоха «вырубим IPv6 и забудем» у мобильных операторов заканчивается. Придется дружить с IPv6, но на своих условиях. То есть через VPN и с четкими правилами.

Чек-листы и лучшие практики 2026

Переход от запрета к управляемому IPv6

Шаг 1. Если вы в панике, временно отключите IPv6 на физических интерфейсах. Шаг 2. Настройте VPN-провайдера с поддержкой IPv6 и полным туннелем. Шаг 3. Переключите стратегию: включите IPv6 в туннеле, заблокируйте вне. Шаг 4. Приведите DNS в порядок: резолвер только через VPN, шифрование опционально, но желательно. Шаг 5. Проведите тесты: браузер, CLI, tcpdump. И, наконец, задокументируйте все, чтобы завтра не изобретать велосипед снова.

Эта лестница простая и надежная. Вы начинаете с грубого выключателя, а заканчиваете управляемой сетью, которая дружит с будущим. Да, тратится день-другой. Зато потом вы спите спокойно и не бегаете за фантомными «дропами скорости» и «рандомными подвисаниями».

Выбор VPN-провайдера и клиента

В 2026 минимальные требования выглядят так: поддержка IPv6 в туннеле, WireGuard с killswitch, корректная публикация DNS, возможность принудительно направлять DoH и DoQ через VPN, продвинутые правила блокировки на уровне интерфейсов. Наличие аудитов и прозрачных политик — огромный плюс. Если провайдер говорит «IPv6 скоро» уже третий год, ищите замену. Мир ушел вперед, и IPv6 теперь не роскошь, а средство передвижения.

Клиент должен уметь: запрещать трафик вне туннеля, задавать маршруты ::/0, управлять приоритетами, показывать интерфейсы и логи, где видно, что и куда ушло. Простой чек: отключите интернет и посмотрите, как ведет себя клиент. Если система вдруг оживает и посылает пару пакетов в мир — такой клиент нам не нужен.

Мониторинг и регулярные аудиты

Лучшая практика — превратить проверку утечек в процедуру. Скрипты, отчеты, тревоги. Раз в квартал — полный прогон. После крупных обновлений — ускоренный тест. На роутерах — периодические снимки маршрутов и правил. В браузерах — контроль профилей. Да, звучит занудно. Но это как ремень безопасности: сначала мешает, потом спасает. И это не преувеличение.

Не забывайте обучать пользователей. Пара слайдов о том, как выглядит нормальный IP в тестах, как проверить WebRTC и куда писать, если что-то не так. Объясните, что приватный DNS без VPN — не приватность. Люди умные, просто им нужно дать правильные инструменты.

Частые ошибки и как их избежать

Отключили IPv6 «в целом», а сломали сервисы

Жесткое отключение IPv6 на уровне ядра иногда ломает корпоративные порталы, новые CDN и мобильные приложения. Не удивляйтесь. Если можете, двигайтесь к модели «IPv6 только внутри VPN». Так вы сохраните совместимость и уберете утечки. Если уж отключаете глобально, сохраняйте бэкапы конфигов и план отката. Лучше не геройствовать ночью, а подготовиться днем.

Еще ошибка — забыть про маршрутизатор. Вы выключили IPv6 на ноутбуке, а телевизор и телефон весело светят свой глобальный адрес через Wi-Fi. В итоге трекинг все равно работает. Проведите единую политику на уровне дома или офиса. Это дисциплина, но она окупается.

DNS-утечки из-за DoH и DoQ

Браузер включает DoH к публичному резолверу, и весь ваш план идет прахом. Проверьте настройки: Secure DNS должен быть под контролем. На Windows и Android задайте провайдера в системе или выключите автоматическое принуждение, если оно не проходит через туннель. На macOS убедитесь, что профиль конфигурации указывает резолверы внутри VPN. Если нет возможности — поднимите локальный DoH-прокси в туннеле.

Еще нюанс — параллельные резолверы. Система может хранить несколько адресов, и приложения дергают разные. Решение: единая точка — локальный резолвер в системе, который сам ходит наружу по VPN. Так вы не ловите хаос из разнородных настроек.

Проблемы с маршрутами ::/0 в WireGuard

Иногда вы прописали AllowedIPs ::/0, но трафик все равно утекает. Проверьте, не выставил ли клиент Table = off без последующей настройки policy routing. Если так, то маршруты не применились. Второе: приоритеты метрик. Если физический интерфейс имеет меньшую метрику, система уходит туда. Поднимите метрику на физическом, или опустите на wg0. И, конечно, включите правила nftables, которые дропают ip6 вне wg0. Это ваш последний рубеж.

Наблюдали еще такой казус: blackhole ::/0 добавили в неправильную таблицу. Команда прошла, а эффекта ноль. Научитесь читать ip -6 rule и ip -6 route show table all. Один взгляд — и все понятно. Это как смотреть на приборную панель: скорость есть, обороты есть, бензин есть — можно ехать.

FAQ: коротко и по делу

Нужно ли полностью отключать IPv6, чтобы не было утечек

Не обязательно. Самый надежный и современный подход — туннелировать IPv6 внутри VPN и запрещать его вне туннеля. Полное отключение уместно как временная мера, если вы спешите закрыть дыру или ваш провайдер VPN не поддерживает IPv6. Но в 2026 все больше сервисов хотят IPv6, так что лучше дружить, а не воевать.

Если боитесь сложности, начните с простого: отключите IPv6 на физических интерфейсах, протестируйте, потом включите его внутри туннеля. Когда почувствуете уверенность, постепенно переходите к управляемой модели. Это эволюция, а не прыжок в неизвестность.

Как проверить, утекает ли мой IPv6 сейчас

Сделайте два шага. В браузере посмотрите, видит ли сайт ваш IPv6 и совпадает ли он с адресом VPN. Затем в терминале выполните curl -6 к известному ресурсу и проверьте маршрут, например ip -6 route get адрес. Если пакет уходит через физический интерфейс, утечка есть. Дополнительно запустите tcpdump на физическом интерфейсе и дождитесь любого ip6 — это железный индикатор.

Не забывайте про WebRTC. Проверьте кандидаты в тестовых страницах или настройках браузера. Если там светится глобальный IPv6 провайдера, вопрос закрыт: настройка неполная. Исправляйте файрвол и DNS.

Мой провайдер VPN не поддерживает IPv6. Что делать

Есть три варианта. Временно полностью отключите IPv6 на устройствах. Настройте строгие правила файрвола, которые дропают ip6 вне туннеля. И подумайте о смене провайдера на того, кто выдает IPv6 в туннеле. В 2026 это уже не экзотика, а базовая гигиена. Жить без IPv6 все сложнее, особенно в мобильных сетях и новых сервисах медиа.

Если смена провайдера не вариант, держите чек-лист и автоматику. Скрипты, которые ловят ip6 на физическом интерфейсе, и алерты. Пусть система кричит, если что-то пошло не так. Это небольшой, но реальный компромисс.

Влияет ли блокировка IPv6 на скорость

Если вы просто грамотно дропаете IPv6 вне туннеля или направляете его в blackhole, влияние минимально. Проблемы начинаются, когда вы создаете таймауты: клиент пытается по IPv6, пакет дропается, и он ждет, прежде чем перейти на IPv4. Это лечится корректной маршрутизацией ::/0 через туннель или blackhole с правильной метрикой.

Туннелирование IPv6 стоит столько же, сколько IPv4, особенно на WireGuard. На современных CPU разница в скорости чаще статистическая погрешность. Куда важнее стабильность маршрутов и отсутствие «мерцаний».

Нужно ли отключать DoH и DoQ ради безопасности

Не нужно отключать шифрованный DNS, если вы можете направить его через VPN. Собственно, лучше шифровать, чем нет. Проблема не в DoH или DoQ, а в том, что они иногда идут в обход. Решение: резолвер должен жить внутри туннеля, а любые попытки резолва вне — блокироваться. Это правило не оспаривается.

Если нет возможности все настроить сейчас, временно выключите DoH в браузере до тех пор, пока не убедитесь, что он ходит только по VPN. Потом вернете обратно, и будет вам и приватность, и порядок.

Как быть с WebRTC, если видеосвязь нужна ежедневно

Отключать WebRTC целиком не вариант, если вы звоните каждый день. Решение: заставьте WebRTC выдавать кандидаты только внутри туннеля. Когда IPv6 есть в VPN, он будет использовать адрес из туннеля, а не ваш глобальный. Дополнительно запретите прямые локальные кандидаты, если это не ломает функционал.

В корпоративной среде настройте TURN-серверы, доступные только через VPN, и следите за тем, чтобы клиенты не умели пробиваться по UDP снаружи. Да, это более строгая политика, но она избавляет от утечек и сюрпризов.

Чем плох «сплит-туннель» в 2026

Он не плох сам по себе. Он просто требует дисциплины и наблюдения. Когда половина интернета уходит напрямую, а половина через VPN, у вас в руках пазл из доменов, протоколов и портов. Добавьте к этому IPv6, QUIC и DoH, и вы получаете систему, где утечка — не баг, а статистическая неизбежность.

Если у вас нет команды, которая готова постоянно обновлять правила и мониторить, лучше держите полный туннель и исключения по списку. Это скучно, но надежно. В финале важен результат, а не романтика правил.