Защо търсенето на имена се проваля през маршрутизиран тунел 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.