Proč selhávají překlady jmen přes směrovaný tunel OpenVPN

Host odpovídá na ping podle adresy a každé hledání podle jména selže. Tunel je nahoře a trasa existuje, takže přirozený závěr je, že VPN je špatně nastavená. Užitečnější závěr je, že hledání nikdy nebylo směrovatelné: směrovaný tunel přenáší unicast IP, kdežto dotaz byl broadcast a hledal segment, který na druhé straně neexistuje. Jakmile je nesoulad vrstev vidět, opravy se samy seřadí podle ceny.

Mýtus: tunel je rozbitý, protože jména nefungují

Příznak je přesvědčivý, protože vše nad vrstvou jmen funguje. Adresy se směrují, rozhraní je nahoře a protějšek odpovídá na ping. Selhal mechanismus objevování, který nikdy neměl cestu přes spojení bod-bod, a to je jiné tvrzení než rozbitý tunel. Oddělení těchto dvou tvrzení je většina diagnózy.

Bere-li se to jako porucha tunelu, vede to k úpravám profilu, které nemohou pomoci. Přidání voleb, změna šifry nebo přeinstalace klienta nechá broadcast přesně tam, kde byl.

Pojmenujte mechanismus, který selhal, dřív než pojmenujete opravu. Hledání přes broadcast potřebuje segment, kdežto hledání přes resolver potřebuje adresu, na kterou se obrátit.

Co TUN přenáší a co ne

Zařízení TUN je IP rozhraní, a právě to ho činí směrovatelným. OpenVPN předá klientovi adresu a sadu tras a od té chvíle klient posílá datagramy protějšku. Nic v tomto modelu nevytváří sdílené spojení, kde každý host slyší každý rámec.

Provoz objevování se do toho modelu vůbec nevejde. Starší dotazy na jména ve Windows, oznámení SSDP a požadavky mDNS se posílají všem na segmentu, nikoli jedinému cíli. Směrované spojení nemá žádné „všechny“, kam posílat. Každý z těch mechanismů předpokládá sdílené médium.

Tunel tedy může být zdravý, zatímco objevování úplně selhává. Té věty je třeba se držet, když někdo hlásí, že VPN je dole.

Přemostění funguje tím, že odstraní hranici

Zařízení TAP přenáší rámce a most ho připojí ke skutečnému segmentu LAN. Klient pak má adresu v tom segmentu a slyší jeho broadcastový provoz. Proto se zdá, že přemostění problém se jmény léčí. Také ale činí klienta závislým na tom segmentu kvůli adresování.

Lékem je odstranění směrovací hranice, ne nějaká nová schopnost jmen uvnitř tunelu. Vše, co segment vysílá, nyní přechází i přes spojení.

Pro malou laboratoř je to férová výměna. Pro rozptýlený tým málokdy.

Protlačit DNS a WINS je užší oprava

Dejte klientovi konkrétní místo, kde se ptát. dhcp-option DNS a dhcp-option DOMAIN nasměrují interní jména na server, který zná zónu, a klient Windows, který se stále spoléhá na NetBIOS, může stejně dostat server WINS. Tunel zůstane směrovaný a segment zůstane tam, kam patří.

O tom, zda to bude fungovat, rozhodují dvě podmínky. Uvedený server musí odpovídat za zónu a dotaz musí být povolen skrz tunel.

Testujte resolver z klienta, ne z vlastního shellu serveru. Resolver, který funguje lokálně, nic neříká o tom, co tunel přenáší.

Zjistěte, která vrstva selhala

Nejdřív pingněte adresu, potom přeložte jméno a přečtěte, který server odpověděl. Záporná odpověď od serveru, který zónu nehostuje, vypadá jinak než dotaz, který stroj nikdy neopustil. Jméno, které se přeloží, ale odmítá spojení, je úplně třetí problém.

Multicast stojí za stejnou zdí. Skupina jako 224.0.0.251 se přes směrovaný tunel ve výchozím nastavení nepředává a trasa pro skupinu nestačí bez cesty, která multicast chápe, nebo bez reflektoru v LAN.