Miért hiúsulnak meg a névkeresések egy irányított OpenVPN-alagúton

A gazdagép pingre címmel válaszol, és minden név szerinti keresésnél elbukik. Az alagút fent van és az útvonal létezik, így a kézenfekvő következtetés az, hogy a VPN rosszul van beállítva. Hasznosabb következtetés, hogy a keresés soha nem volt irányítható: az irányított alagút unicast IP-t szállít, miközben a szóban forgó lekérdezés broadcast volt, amely a túloldalon nem létező szegmenst keresett. Amint a rétegek közti eltérés láthatóvá válik, a megoldások maguktól költség szerint rendeződnek.

Tévhit: az alagút hibás, mert a nevek elbuknak

A tünet meggyőző, mert a névréteg felett minden működik. A címek irányítódnak, az interfész fent van, és a partner válaszol a pingre. Ami elbukott, az egy felderítési mechanizmus, amelynek soha nem volt útja pont-pont kapcsolaton át, és ez más állítás, mint a hibás alagút. E két állítás szétválasztása a diagnózis nagy része.

Alagúthibaként kezelve olyan profilmódosításokhoz vezet, amelyek nem segíthetnek. A beállítások hozzáadása, a titkosítás cseréje vagy a kliens újratelepítése pontosan ott hagyja a broadcastot, ahol volt.

Nevezze meg az elbukott mechanizmust, mielőtt megnevezi a megoldást. A broadcastot használó keresésnek szegmensre van szüksége, míg a feloldót használó keresésnek egy címre, amelyet kérdezhet.

Mit szállít a TUN és mit nem

A TUN-eszköz IP-interfész, és éppen ez teszi irányíthatóvá. OpenVPN címet és útvonalak halmazát adja a kliensnek, és onnantól a kliens datagramokat küld a partnernek. Ebben a modellben semmi nem hoz létre megosztott kapcsolatot, ahol minden gazdagép minden keretet hall.

A felderítési forgalom egyáltalán nem illik ebbe a modellbe. A régebbi Windows névlekérdezések, az SSDP-hirdetések és az mDNS-kérések a szegmens mindenkijének mennek egyetlen cél helyett. Az irányított kapcsolatnak nincs „mindenki”, akinek küldhetne. E mechanizmusok mindegyike megosztott közeget feltételez.

Az alagút tehát egészséges lehet, miközben a felderítés teljesen elbukik. Ehhez a mondathoz kell ragaszkodni, amikor valaki azt jelenti, hogy a VPN leállt.

A hidalás a határ megszüntetésével működik

A TAP-eszköz kereteket szállít, és egy híd valódi LAN-szegmenshez csatolja. A kliens ekkor címmel rendelkezik azon a szegmensen, és hallja annak broadcast-forgalmát. Ezért tűnik úgy, hogy a hidalás meggyógyítja a névproblémát. Azt is eléri, hogy a kliens a címzés szempontjából függjön ettől a szegmenstől.

A gyógyír az irányítási határ megszüntetése, nem valamilyen új névadási képesség az alagúton belül. Minden, amit a szegmens broadcastol, most a kapcsolaton is átkel.

Egy kis laboratórium számára ez tisztességes csere. Szétszórt munkaerő esetén ritkán az.

A DNS és a WINS kényszerítése a szűkebb javítás

Adjon a kliensnek konkrét helyet, ahol kérdezhet. A dhcp-option DNS és a dhcp-option DOMAIN a belső neveket olyan kiszolgálóra irányítja, amely ismeri a zónát, és a NetBIOS-ra még támaszkodó Windows-kliens ugyanígy WINS-kiszolgálót kaphat. Az alagút irányított marad, a szegmens pedig a helyén marad.

Két feltétel dönti el, hogy működik-e. A megnevezett kiszolgálónak a zónáért kell válaszolnia, és a lekérdezést át kell engedni az alagúton.

A feloldót a kliens felől tesztelje, ne a kiszolgáló saját héjából. A helyben működő feloldó semmit nem mond arról, mit szállít az alagút.

Derítse ki, melyik réteg bukott el

Először pingelje a címet, aztán oldja fel a nevet, és olvassa el, melyik kiszolgáló válaszolt. Egy olyan kiszolgáló negatív válasza, amely nem hosztolja a zónát, másként néz ki, mint egy lekérdezés, amely soha nem hagyta el a gépet. A feloldódó, de kapcsolatokat elutasító név egészen harmadik probléma.

A multicast ugyanazon fal mögött van. Egy 224.0.0.251 típusú csoportot alapértelmezés szerint nem továbbítanak irányított alagúton, és a csoport útvonala nem elég multicastot értő útvonal vagy LAN-beli reflektor nélkül.