DNS-утечки и kill switch на роутере: как закрыть каналы утечки трафика

Что такое DNS-утечка и почему она опасна

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

Причина утечки почти всегда одна: операционная система устройства использует DNS-сервер, полученный по DHCP от локального роутера или провайдера, вместо DNS-сервера, назначенного внутри туннеля. Это происходит, если конфигурация клиента AmneziaWG не задаёт явно DNS-сервер, либо если системные настройки более высокого приоритета переопределяют туннельный DNS.

Отдельная и более скрытая форма утечки связана с DNS over HTTPS и DNS over TLS. Современные браузеры по умолчанию могут использовать зашитый в них DoH-сервер, полностью игнорируя настройки DNS операционной системы и туннеля. В таком случае даже правильно настроенный DNS на уровне роутера не поможет, потому что браузер обращается к DNS-серверу напрямую по HTTPS, минуя стандартный 53 порт.

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

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

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

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

1. 1Откройте сервис проверки DNS-утечек при активном туннеле AmneziaWG
2. 2Сравните показанный DNS-сервер с сервером, указанным в конфигурации туннеля
3. 3Повторите проверку на нескольких устройствах в локальной сети
4. 4Проверьте результаты отдельно для IPv4 и IPv6

Настройка DNS внутри туннеля

Самый надёжный способ исключить утечку — явно задать DNS-сервер в конфигурации AmneziaWG и одновременно принудительно перенаправлять все DNS-запросы из локальной сети через этот сервер на уровне роутера. Так утечка исключается даже для устройств, которые пытаются использовать собственный DNS в обход системных настроек.

В конфигурационном файле клиента AmneziaWG параметр DNS задаёт адрес, который будет назначен интерфейсу после поднятия туннеля. Указывайте DNS-сервер, доступный именно через туннель — это может быть DNS сервера AmneziaWG, публичный DNS-резолвер или локальный DNS на VPS. После применения конфигурации на роутере проверьте, что этот адрес действительно используется системой для резолвинга.

Для полной защиты этого недостаточно, если в сети есть устройства с зашитыми в прошивку DNS-серверами — например, некоторые смарт-телевизоры и IoT-устройства игнорируют DHCP-настройки DNS. Для таких устройств нужен принудительный редирект трафика на 53 порту, который описан в следующем разделе.

# Пример блока конфигурации AmneziaWG с явным DNS
[Interface]
PrivateKey = <ваш_приватный_ключ>
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <публичный_ключ_сервера>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.com:51820

Принудительный редирект DNS-трафика на 53 порту

Чтобы исключить обход туннельного DNS устройствами с зашитыми в прошивку резолверами, на роутере настраивается правило файрвола, которое перенаправляет весь исходящий трафик на 53 порту, независимо от того, куда он изначально адресован, на нужный DNS-сервер внутри туннеля. Это называется DNS hijacking в защитных целях и является стандартной практикой для домашних VPN-шлюзов.

На OpenWrt такое правило настраивается через iptables или nftables в зависимости от версии прошивки, с использованием DNAT-цели для перенаправления пакетов, адресованных на порт 53, на внутренний DNS-сервер. Правило должно применяться ко всем клиентам LAN, кроме самого DNS-сервера, чтобы избежать зацикливания.

На MikroTik аналогичная задача решается через правило dst-nat в цепочке firewall nat с указанием протокола UDP и TCP на порту 53. На Keenetic из-за более закрытой прошивки такой редирект обычно делается либо через встроенные настройки DNS-серверов в интерфейсе, либо через установку дополнительного пакета, если устройство поддерживает Entware.

1. 1Определите DNS-сервер внутри туннеля, на который будет идти редирект
2. 2Настройте DNAT-правило для UDP и TCP трафика на порт 53 в сторону этого сервера
3. 3Исключите из правила сам DNS-сервер, чтобы избежать петли
4. 4Проверьте, что устройства с зашитым DNS теперь резолвят через туннельный сервер

# MikroTik: редирект DNS-запросов LAN на туннельный DNS-сервер
/ip firewall nat add chain=dstnat protocol=udp dst-port=53 \
  src-address=192.168.88.0/24 action=dst-nat to-addresses=10.8.0.1
/ip firewall nat add chain=dstnat protocol=tcp dst-port=53 \
  src-address=192.168.88.0/24 action=dst-nat to-addresses=10.8.0.1

Блокировка DoH и DoT в обход туннеля

DNS over HTTPS работает на стандартном 443 порту вместе с обычным HTTPS-трафиком, поэтому обычный редирект 53 порта его не перехватывает. Браузеры вроде Chrome и Firefox по умолчанию используют один из нескольких известных публичных DoH-серверов, список адресов которых можно заблокировать на уровне файрвола роутера.

Практический подход — заблокировать известные IP-адреса и домены популярных DoH-провайдеров на файрволе, что вынудит браузер откатиться на системный DNS, который в свою очередь уже перенаправлен через туннель. Список таких адресов периодически обновляется, поэтому подход требует поддержки актуальности правил.

DNS over TLS работает на отдельном 853 порту, и его можно заблокировать значительно проще — простым правилом файрвола, запрещающим исходящий трафик на этот порт для всех устройств локальной сети, кроме доверенных. Так как большинство обычных пользовательских приложений не используют DoT напрямую, блокировка этого порта редко вызывает побочные эффекты.

1. 1Заблокируйте исходящий трафик на 853 порт (DoT) для всех клиентов LAN
2. 2Соберите и заблокируйте список IP-адресов популярных публичных DoH-серверов
3. 3Периодически обновляйте список заблокированных адресов DoH
4. 4Проверьте после блокировки, что браузеры используют системный DNS

Kill switch: блокировка трафика при падении туннеля

Kill switch — это набор правил файрвола, которые полностью блокируют исходящий трафик локальной сети в интернет, если интерфейс туннеля перестал быть активен. Без такого механизма при обрыве AmneziaWG роутер автоматически перенаправляет трафик через обычное подключение провайдера, и все преимущества шифрования на это время исчезают незаметно для пользователя.

На OpenWrt kill switch реализуется через маркировку трафика и запрет форвардинга через WAN-интерфейс напрямую, разрешая выход только через интерфейс туннеля. Ключевая идея — не давать пакетам маршрут по умолчанию через физический WAN, а только через awg-интерфейс, тогда при его падении пакеты просто не находят маршрут и отбрасываются, вместо того чтобы уйти в обход.

На MikroTik аналогичный эффект достигается через настройку таблицы маршрутизации с проверкой доступности шлюза внутри туннеля: если туннель падает, маршрут через него помечается недоступным и трафик не переключается на резервный маршрут через обычный WAN, если такой резервный маршрут явно не разрешён администратором. На Keenetic встроенного kill switch нет, поэтому потребуется либо использовать политики приложений с жёсткой привязкой к интерфейсу туннеля без резервного маршрута, либо переходить на Entware для более гибкой настройки файрвола.

1. 1Настройте маршрут по умолчанию только через интерфейс туннеля, без резервного маршрута через WAN
2. 2Добавьте правило файрвола, запрещающее форвардинг LAN-трафика напрямую через WAN-интерфейс
3. 3Проверьте поведение сети при принудительном отключении туннеля — интернет должен пропасть полностью
4. 4На Keenetic используйте политики приложений с привязкой к интерфейсу AmneziaWG без alternate route

# OpenWrt: запрет форвардинга LAN трафика напрямую через WAN
uci add firewall rule
uci set firewall.@rule[-1].name='Block-LAN-to-WAN-direct'
uci set firewall.@rule[-1].src='lan'
uci set firewall.@rule[-1].dest='wan'
uci set firewall.@rule[-1].target='REJECT'
uci commit firewall
/etc/init.d/firewall restart

IPv6-утечки: отдельная проблема

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

Решить проблему можно двумя способами: либо полностью отключить IPv6 на WAN-интерфейсе роутера, если провайдер не требует его для базовой связности, либо настроить полноценное туннелирование IPv6-трафика внутри AmneziaWG, что требует поддержки IPv6 на стороне сервера. Первый способ проще и надёжнее для большинства домашних сценариев, второй — более правильный, но сложнее в настройке.

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

1. 1Определите, использует ли провайдер IPv6 на вашем подключении
2. 2Если IPv6 не критичен — отключите его на WAN-интерфейсе роутера
3. 3Если IPv6 нужен — настройте туннелирование IPv6 внутри AmneziaWG на сервере и клиенте
4. 4Повторите проверку утечки отдельно для IPv6 после внесения изменений

Финальная проверка результата

После настройки всех перечисленных мер стоит провести комплексную проверку, объединяющую все каналы утечки одновременно: DNS через 53 порт, DoH, DoT, IPv6 и поведение сети при обрыве туннеля. Только такая совокупная проверка даёт уверенность, что защита работает целиком, а не только для одного из протоколов.

Рекомендуется повторять эту проверку не только сразу после настройки, но и через несколько недель, потому что обновления прошивки роутера или браузера на клиентских устройствах иногда сбрасывают настройки DNS или включают DoH заново без явного уведомления пользователя.

1. 1Проверьте DNS-утечку на нескольких сервисах и устройствах
2. 2Убедитесь, что DoH и DoT заблокированы или проходят через туннель
3. 3Проверьте IPv6-утечку отдельно от IPv4
4. 4Отключите туннель принудительно и убедитесь, что интернет пропадает (kill switch работает)
5. 5Повторяйте проверку периодически после обновлений прошивки