mDNS внутри VPN: почему имена .local не разрешаются

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

Проверьте, что разрешается сегодня, а что только выглядит разрешённым

Сначала разделите два вопроса: unicast-запрос для имени хоста спрашивает распознаватель, тогда как поиск _ipp._tcp спрашивает локальный канал. В Linux avahi-browse -a показывает, что может видеть multicast DNS, а resolvectl query name.local показывает, что стек распознавателя делает с этим именем. В macOS dns-sd -B _ipp._tcp перечисляет обнаруженные службы, не требуя сначала адреса.

Если адрес отвечает, а имя нет, маршрутизация работает, а обнаружение нет. Имя .local можно также разрешить на самом хосте через nss-mdns без установленного avahi-browse, поэтому успешный getent или ping к этому имени не доказывает, что обнаружение пересекло туннель; результат поиска и результат распознавателя — разные доказательства. Приложения кэшируют то, что обнаружили, поэтому сбой часто проявляется через часы после подключения, а не при подключении. Закройте и снова откройте приложение, затем проверьте, содержит ли кэшированная запись имя или адрес, поскольку адрес продолжает работать долго после того, как обнаружение остановилось.

Почему запрос никогда не пересекает туннель

Multicast DNS отправляет запросы на 224.0.0.251, внутри блока управления локальной сетью, на UDP-порт 5353. Маршрутизаторы не пересылают адреса из этого блока, поэтому запрос остаётся в канале, куда был отправлен. Отправители также устанавливают IP TTL, или предел переходов IPv6, в 255, чтобы получатель мог отклонить пакет, уже прошедший через маршрутизатор; так протокол обнаруживает подделку за пределами канала, а не так он остаётся локальным. Локальность исходит от адреса назначения, а не от TTL в один переход.

Тип туннеля тоже важен. Интерфейс в стиле tun передаёт IP-пакеты и ничего больше, поэтому ни одна multicast-группа через него не проходит. Мост в стиле tap расширяет сам домен широковещания, поэтому некоторые старые проекты мостили вместо маршрутизации и унаследовали все проблемы, которые приносит мост.

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

Выберите дизайн имён, который сможете поддерживать

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

Прокси обнаружения или mDNS-отражатель может закрыть этот разрыв, и это реальный проект со своим хостом, своей экспозицией и своими требованиями к клиентам. Он не появляется потому, что вы добавили маршрут. Никогда не пересылайте запросы .local публичному распознавателю: домен зарезервирован для локального multicast-использования по RFC 6762, и отправка его наружу даёт медленные сбои и ненужное раскрытие данных.

Проверяйте службу, а не имя

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

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