Разрешить DNS только через ваш VPN-резолвер: пошаговый разбор

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

Шаг 1: назовите резолвер и путь

Запишите три вещи прежде, чем трогать межсетевой экран: адрес резолвера, протокол и порт, которые вы ожидаете, и интерфейс, через который запрос должен выйти. Без этого списка правило — догадка о трафике, а не исполнение решения. VPN может нести данные приложений, пока DNS следует отдельному порядку, и само по себе это не ошибка. Так бывает, когда никто не сказал клиенту ничего другого.

Явно назвать путь — это разница между проектом и случайностью. Это также даёт материал для последующей проверки, потому что каждое наблюдение можно сравнить с письменным ожиданием. Держите этот список в заявке на изменение, а не в чьей-то голове.

Шаг 2: задайте политику там, где она действительно живёт

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

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

Шаг 3: примените путь узко

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

Блокировать DoH и DoT законно; предполагать, что правило для порта 53 уже их заблокировало, — нет. Браузер с DoH разрешает имена путём, который ваше правило никогда не описывало, и приложение со своим резолвером делает то же самое. Запишите каждый путь, который вы собираетесь разрешить, и каждый, который собираетесь отклонить. Правило, не называющее путь, ничего о нём не решило.

Шаг 4: следите за частными и публичными именами

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

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

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

Шаг 5: оставьте путь назад

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

После переподключения или обновления политики браузера снова проверьте фактическое состояние, потому что и то и другое может сменить резолвер, не меняя вашего правила. Требование — известный получатель и защищённый путь для запросов, а не успокаивающая надпись о резолвере на одном снимке экрана. Спецификация RFC 8484 для DNS over HTTPS — это ориентир для зашифрованного пути, которого ваше правило порта не видит.