Почему поиск имён не работает через маршрутизируемый туннель OpenVPN

Хост отвечает на ping по адресу и терпит неудачу при каждом поиске по имени. Туннель поднят и маршрут существует, поэтому естественный вывод — VPN настроен неверно. Более полезный вывод: поиск никогда не был маршрутизируемым, ведь маршрутизируемый туннель передаёт unicast IP, а запрос был широковещательным и искал сегмент, которого нет на другой стороне. Как только несоответствие уровней становится видимым, исправления сами выстраиваются по стоимости.

Миф: туннель сломан, потому что имена не работают

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

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

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

Что TUN передаёт, а что нет

Устройство TUN — это IP-интерфейс, и именно это делает его маршрутизируемым. OpenVPN выдаёт клиенту адрес и набор маршрутов, и с этого момента клиент отправляет дейтаграммы пиру. Ничто в этой модели не создаёт общего канала, где каждый хост слышит каждый кадр.

Трафик обнаружения совершенно не вписывается в эту модель. Старые запросы имён Windows, объявления SSDP и запросы mDNS отправляются всем в сегменте, а не одному адресату. У маршрутизируемого канала нет никаких «всех», кому можно отправить. Каждый из этих механизмов предполагает общую среду.

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

Мост работает, убирая границу

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

Лечение — это удаление границы маршрутизации, а не новая способность имён внутри туннеля. Всё, что сегмент передаёт широковещательно, теперь пересекает и канал.

Для небольшой лаборатории это честный обмен. Для распределённой команды — редко.

Проталкивание DNS и WINS — более узкое исправление

Дайте клиенту конкретное место для вопросов. dhcp-option DNS и dhcp-option DOMAIN направляют внутренние имена на сервер, который знает зону, а клиент Windows, всё ещё полагающийся на NetBIOS, может таким же образом получить сервер WINS. Туннель остаётся маршрутизируемым, а сегмент остаётся на своём месте.

Два условия решают, будет ли это работать. Названный сервер должен отвечать за зону, и запрос должен быть разрешён через туннель.

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

Выясните, какой уровень отказал

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

Multicast стоит за той же стеной. Группа вроде 224.0.0.251 по умолчанию не передаётся через маршрутизируемый туннель, и маршрута для группы недостаточно без пути, понимающего multicast, или отражателя в LAN.