Имя хоста в LAN не работает через VPN: суффикс, mDNS или зона?

Рядом с устройством принтер отвечает на короткое имя, а файловый сервер — на прозвище. Через туннель оба имени истекают по тайм-ауту, хотя их адреса по-прежнему работают. Маршрут делает своё дело; путь имён, который делал эти короткие имена рабочими, так и не прошёл через туннель. Такое поведение создают три механизма, и каждый требует своей правки.

Начните с определения, от какого механизма зависит имя.

Три типа имён, которые ведут себя по-разному

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

Имя, оканчивающееся на .local, обычно разрешается через multicast DNS на локальном канале, как описывает RFC 6762. Multicast не проходит через маршрутизируемый туннель, если что-то намеренно не мостит или не проксирует его, поэтому имя перестаёт разрешаться в тот момент, когда вы покидаете сегмент.

Полностью определённое имя компании принадлежит внутренней зоне, которую обслуживают резолверы организации. Оно работает удалённо, когда VPN проталкивает эти резолверы и клиент настроен их использовать. А localhost согласно RFC 6761 имеет особое назначение: оно указывает на машину перед вами, но никогда на удалённую службу.

Прочитайте резолвер, прежде чем менять маршрут

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

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

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

Донесите правильное имя до клиента

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

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

Сохраните целостность идентичности сертификата

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

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