Чому пошук імен не працює через маршрутизований тунель 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.