Почему собственный DNS роутера обходит туннель VPN?

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

К какому потоку на самом деле относится перехват пакетов

Один запрос включает два обмена. Клиент LAN отправляет запрос резолверу роутера, и тот приходит как перенаправленный трафик на интерфейсе LAN, поэтому правило политической маршрутизации или NAT, написанное для перенаправленных пакетов, может ему соответствовать. Затем роутер отвечает из кэша или, при промахе, открывает собственный запрос к вышестоящему серверу.

У этого второго запроса источник — сам роутер, и назначение тоже он сам, а платформа выбирает ему путь из другого блока конфигурации. Оба обмена несут одно и то же имя, и ни один не является копией другого. Поэтому перехват, взятый на стороне LAN, доказывает, куда ушёл пакет клиента, и ничего не говорит об исходящем пакете.

Практическая проверка — наблюдать обе стороны одновременно. На роутере перечислите сокет резолвера, опросите его локально и запишите интерфейс WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Если список сокетов показывает слушателя, привязанного к адресу loopback или LAN, роутер отвечает локально, а не перенаправляет другому хосту. Тогда запись покажет, выходит ли получившийся восходящий запрос через интерфейс туннеля или через WAN, и это тот ответ, которого правило политической маршрутизации никогда бы не дало.

Почему политическая маршрутизация никогда не видит второй запрос

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

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

Где резолвер pfSense определяет свой восходящий путь

pfSense делает это разделение видимым. Клиентский трафик можно направлять политической маршрутизацией через шлюз VPN, тогда как собственный трафик межсетевого экрана следует исходящей настройке резолвера, а не правилам LAN. В веб-интерфейсе эта настройка находится в Services > DNS Resolver > Outgoing Network Interfaces, и её значение — список интерфейсов, которые резолвер может использовать для восходящих запросов.

Указать там интерфейс туннеля, и только этот интерфейс, — это то, что заставляет собственные запросы роутера идти через туннель. Если оставить значение по умолчанию, резолвер выбирает выход из таблицы маршрутизации, который на хосте с двумя WAN или VPN часто оказывается WAN.

Другие прошивки показывают то же решение под другим названием: список вышестоящих серверов, привязанный к адресу источника, режим только пересылки или документированная политика маршрутов. Настройка, которую нужно искать, — всегда та, что выбирает выход или источник для локально созданных запросов. Справочник по конфигурации резолвера документирует эту опцию для pfSense, и её стоит прочитать перед изменением.

Выберите поведение при сбое раньше настройки

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

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

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

Проверьте оба пути и держите результаты отдельно

Тест DNS в браузере отвечает на узкий вопрос: какие резолверы использовал этот браузер в условиях этого теста. Он не инвентаризует устройства в сети и не видит запрос, который роутер создал для себя. Относитесь к его выводу как к одной точке данных, а не как к аудиту.

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

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Затем опустите туннель и повторите оба запроса. Отклонённые ответы означают, что резолвер закрывается при сбое; успешный ответ указывает на резервный резолвер и использованный им путь. Сравните это с заметкой, которую вы написали, и с записью на интерфейсе WAN, сделанной в ту же минуту.

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