Почему ответ DNS не проходит на пограничном межсетевом экране VPN без отслеживания состояний

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

Два обмена — не один и тот же обмен

Запишите кортежи, и ошибка становится очевидной. Порт назначения запроса становится исходным портом ответа, что противоположно тому, что большинство представляет, добавляя входящее правило для порта 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

Граница без состояний против межсетевого экрана хоста с отслеживанием состояний

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

Сравнение важно потому, что два устройства отказывают по-разному. Межсетевой экран с отслеживанием состояний, отклоняющий ответ, пишет в журнал сброс; граница без состояний отклоняет его молча, поэтому хост просто уходит в тайм-аут.

Стройте разрешение вокруг протокола, а не номера порта

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

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

Почему разрешение любого исходного порта 53 не является исправлением

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

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

Проверяйте на правильной границе, в правильном направлении

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

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