Какое соединение отвечает: домены маршрутизации для DNS VPN с раздельным туннелем

Оставьте обычный просмотр на локальном соединении, а имена компании разрешайте через DNS-сервер, который предоставляет туннель. Отключение маршрута по умолчанию у VPN даёт первую половину и оставляет вторую несобранной. Далее — недостающая настройка, знак препинания, меняющий её смысл, и единственная команда, показывающая, какое соединение действительно ответило. Везде предполагаются NetworkManager и systemd-resolved, потому что именно эта пара обычно становится началом путаницы.

Шаг первый: отделите маршрут от резолвера

ipv4.never-default отвечает на вопрос маршрутизации и не даёт NetworkManager установить это соединение как путь для всего трафика IPv4. Домен маршрутизации DNS отвечает на другой вопрос: какие серверы имён какого соединения получают запрос для подходящего суффикса. Ни одно не подразумевает другое, и профиль может годами нести одно, не имея другого. Только маршрут означает, что туннель несёт подсети компании и его резолвер отвечает на имена компании, а всё остальное остаётся нетронутым.

Задайте только свойство маршрута — внутренние имена перестанут разрешаться, обычно с тайм-аутом, который звучит как сломанный туннель. Задайте только домен — вы тихо добавили суффикс поиска к каждому короткому имени на машине. Обе ошибки отправляют заявку на сервер VPN, который редко оказывается неверной частью.

Шаг второй: добавьте в профиль домен только для маршрутизации

Предположим, соединение называется corp-vpn, суффикс компании — internal.example, а резолвер туннеля уже доступен. Сначала прочитайте текущие значения, потому что команды ниже меняют свойства, в которых уже могут быть записи.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

Ведущая тильда обозначает домен только для маршрутизации, поэтому подходящие запросы идут на серверы этого соединения, а суффикс не добавляется к коротким именам. Уберите тильду — та же строка станет ещё и суффиксом поиска, что является другим результатом, который люди редко имеют в виду. Обе настройки выше — IPv4, поэтому профилю с двумя стеками нужны ipv6.never-default и тот же домен маршрутизации в ipv6.dns-search, иначе сторона IPv6 продолжает использовать маршрут по умолчанию, и внутренние имена там не разрешаются.

Шаг третий: спросите resolvectl, какое соединение ответило

Выполните resolvectl status и прочитайте DNS-серверы и домены каждого соединения, затем выполните resolvectl query host.internal.example для реального внутреннего имени, которое вам разрешено запрашивать. Вторая команда — единственное прямое доказательство того, что домен маршрутизации выполняет свою работу, потому что она называет соединение, которое ответило. Один список состояния доказывает конфигурацию; запрос доказывает разрешение.

systemd-resolved выбирает наиболее подходящий домен маршрутизации, поэтому более конкретный домен на другом соединении всё ещё может выиграть гонку. Если запрос вернулся с неожиданного соединения, прочитайте списки доменов, прежде чем трогать DNS-сервер VPN. Корневой домен ~. совпадает со всем, и если он уже есть, ваш конкретный домен всё равно выигрывает для своих имён, пока соединение отвечает на гораздо большее, чем вы просили. Удалите или сузьте эту корневую запись, когда целью были только имена компании.

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

Шаг четвёртый: когда имя разрешается, а служба нет

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

Изменение в Samba, которое ходит рядом с этим вопросом, касается уровня доступа, а не выбора DNS. Применять его к сбою разрешения имён — это способ, которым маленькая проблема приобретает вторую.

Шаг пятый: не заменяйте резолвер, чтобы исправить отсутствующий домен

Совет, который перезаписывает файл резолвера или устанавливает другой менеджер резолвера, решает другую проблему. Это изменения системной интеграции со своими режимами отказа, и ни одно из них не добавляет домен маршрутизации, который никогда не настраивался. Определите, какой компонент владеет разрешением имён на машине, прежде чем его заменять, потому что на рабочем столе NetworkManager с systemd-resolved это владение уже определено. Борьба с ним — это способ, которым работающая конфигурация превращается в то, что никто не может воспроизвести.

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