Prečo vyhľadávanie mien zlyháva cez smerovaný tunel OpenVPN

Host odpovedá na ping podľa adresy a každé hľadanie podľa mena zlyhá. Tunel je hore a trasa existuje, takže prirodzený záver je, že VPN je zle nastavené. Užitočnejší záver je, že hľadanie nikdy nebolo smerovateľné: smerovaný tunel prenáša unicast IP, kým dopyt bol broadcast a hľadal segment, ktorý na druhej strane neexistuje. Keď je nesúlad vrstiev viditeľný, opravy sa samé zoradia podľa ceny.

Mýtus: tunel je pokazený, pretože mená zlyhávajú

Príznak je presvedčivý, pretože všetko nad vrstvou mien funguje. Adresy sa smerujú, rozhranie je hore a partner odpovedá na ping. Zlyhal mechanizmus objavovania, ktorý nikdy nemal cestu cez spojenie bod-bod, a to je iné tvrdenie než pokazený tunel. Oddelenie týchto dvoch tvrdení je väčšina diagnózy.

Ak sa to berie ako porucha tunela, vedie to k úpravám profilu, ktoré nemôžu pomôcť. Pridanie volieb, zmena šifrovania alebo preinštalovanie klienta nechá broadcast presne tam, kde bol.

Pomenujte mechanizmus, ktorý zlyhal, skôr než pomenujete opravu. Hľadanie cez broadcast potrebuje segment, kým hľadanie cez resolver potrebuje adresu, na ktorú sa obrátiť.

Čo TUN prenáša a čo nie

Zariadenie TUN je IP rozhranie a práve to ho robí smerovateľným. OpenVPN dáva klientovi adresu a sadu trás a odvtedy klient posiela datagramy partnerovi. Nič v tomto modeli nevytvára zdieľané spojenie, kde každý host počuje každý rámec.

Prevádzka objavovania sa do tohto modelu vôbec nehodí. Staršie dopyty na mená vo Windows, oznámenia SSDP a požiadavky mDNS sa posielajú všetkým v segmente, nie jedinému cieľu. Smerované spojenie nemá žiadne „všetci“, kam posielať. Každý z tých mechanizmov predpokladá zdieľané médium.

Tunel teda môže byť zdravý, kým objavovanie úplne zlyháva. Práve tej vety sa treba držať, keď niekto hlási, že VPN je dole.

Mostovanie funguje odstránením hranice

Zariadenie TAP prenáša rámce a most ho pripojí k skutočnému segmentu LAN. Klient potom má adresu v tom segmente a počuje jeho broadcastovú prevádzku. Preto sa zdá, že mostovanie lieči problém s menami. Robí tiež klienta závislým od toho segmentu pri adresovaní.

Liekom je odstránenie smerovacej hranice, nie nejaká nová schopnosť mien vnútri tunela. Všetko, čo segment vysiela, teraz prechádza aj spojením.

Pre malé laboratórium je to férová výmena. Pre rozptýlený tím málokedy.

Pretlačenie DNS a WINS je užšia oprava

Dajte klientovi konkrétne miesto, kde sa pýtať. dhcp-option DNS a dhcp-option DOMAIN nasmerujú interné mená na server, ktorý pozná zónu, a klient Windows, ktorý sa stále spolieha na NetBIOS, môže rovnakým spôsobom dostať server WINS. Tunel zostane smerovaný a segment zostane tam, kam patrí.

O tom, či to bude fungovať, rozhodujú dve podmienky. Uvedený server musí odpovedať za zónu a dopyt musí byť povolený cez tunel.

Testujte resolver z klienta, nie z vlastného shellu servera. Resolver, ktorý funguje lokálne, nič nehovorí o tom, čo tunel prenáša.

Zistite, ktorá vrstva zlyhala

Najprv pingnite adresu, potom preložte meno a prečítajte, ktorý server odpovedal. Negatívna odpoveď od servera, ktorý zónu nehostuje, vyzerá inak než dopyt, ktorý stroj nikdy neopustil. Meno, ktoré sa preloží, ale odmieta spojenia, je úplne tretí problém.

Multicast stojí za tou istou stenou. Skupina ako 224.0.0.251 sa cez smerovaný tunel štandardne nepreposiela a trasa pre skupinu nestačí bez cesty, ktorá rozumie multicastu, alebo bez reflektora v LAN.