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

Получить ответ и решить его вернуть — два разных шага.

Сравните одно и то же имя на обоих резолверах

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

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

Читайте отказ, а не симптом

Параметр stop-dns-rebind в dnsmasq отклоняет подходящие ответы с приватным адресом, пришедшие сверху, и при этом записывает их в журнал. Эта защита существует по уважительной причине: публичное имя, которое внезапно указывает на приватный адрес, — классическая rebinding-атака. Она также пересекается с намеренно приватной службой, и это ваш случай.

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

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

Ограничьте исключение одним доменом

Для проверенного домена руководство dnsmasq предлагает исключение, ограниченное доменом, а не глобальный переключатель.

rebind-domain-ok=corp.example

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

Исключение из обнаружения rebinding делает ровно одно: пропускает ответы этого домена.

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

Проверьте, не убирая границу

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

Храните причину исключения рядом с конфигурацией, с датой и ответственным.

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

Похожие статьи