Ваш домен VPN в dnsmasq — это не передача зоны

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

То, что принял клиент, — не то, что предложил шлюз

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

Это различие объясняет большинство сообщений о домене, который так и не пришёл. Его предложили, и его не применили.

Два вида записей домена

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

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

localhost в resolv.conf — не ошибка

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

Замена этой записи публичным резолвером — классическое ошибочное исправление. Оно восстанавливает публичное разрешение имён и в той же правке отбрасывает условную политику.

Не путайте бэкенды

Управляемый экземпляр dnsmasq и системный резолвер — это разные программы с разной конфигурацией и разными представлениями состояния. Команда состояния для одного не сообщает ничего полезного о другом.

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

Проверяйте пространство имён, а не только ответ

Запросите одно разрешённое частное имя и одно публичное контрольное имя обычным путём приложения. Прямой запрос к корпоративному серверу доказывает, что запись существует; он не доказывает, что клиент выбрал этот сервер. Второй запрос — тот, который проверяет политику.

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