Miks nimepäringud marsruuditud OpenVPN-tunnelis ebaõnnestuvad

Host vastab pingile aadressi järgi ja ebaõnnestub igal nimel põhineval otsingul. Tunnel on üleval ja marsruut on olemas, seega loomulik järeldus on, et VPN on valesti seadistatud. Kasulikum järeldus on, et otsing ei olnud kunagi marsruuditav: marsruuditud tunnel edastab unicast IP-d, samas kui päring oli broadcast, mis otsis segmenti, mida teisel pool ei ole. Niipea kui kihtide sobimatus nähtavaks saab, järjestuvad lahendused ise kulu järgi.

Müüt: tunnel on katki, sest nimed ei tööta

Sümptom on veenev, sest kõik nimekihist kõrgemal töötab. Aadressid marsruuditakse, liides on üleval ja partner vastab pingile. Ebaõnnestus avastusmehhanism, millel ei olnud kunagi teed üle punkt-punkti ühenduse, ja see on teine väide kui katkine tunnel. Nende kahe väite eraldamine on suurem osa diagnoosist.

Selle käsitlemine tunneleritena viib profiilimuudatusteni, mis ei saa aidata. Valikute lisamine, šifreerimise muutmine või kliendi uuesti paigaldamine jätab broadcasti täpselt sinna, kus see oli.

Nimetage mehhanism, mis ebaõnnestus, enne kui nimetate paranduse. Broadcasti kasutav otsing vajab segmenti, samas kui resolverit kasutav otsing vajab aadressi, millelt küsida.

Mida TUN edastab ja mida mitte

TUN-seade on IP-liides ja just see teeb selle marsruuditavaks. OpenVPN annab kliendile aadressi ja hulga marsruute ning sealt edasi saadab klient datagramme partnerile. Miski selles mudelis ei loo jagatud ühendust, kus iga host kuuleb iga kaadrit.

Avastusliiklus ei sobi sellesse mudelisse üldse. Vanemad Windowsi nimepäringud, SSDP-teated ja mDNS-päringud saadetakse kõigile segmendis, mitte ühele sihtkohale. Marsruuditud ühendusel ei ole „kõiki“, kellele saata. Kõik need mehhanismid eeldavad jagatud kandjat.

Tunnel võib seega olla terve, samal ajal kui avastamine täielikult ebaõnnestub. See lause on see, millest tuleb kinni hoida, kui keegi teatab, et VPN on maas.

Sildamine toimib piiri kaotamisega

TAP-seade edastab kaadreid ja sild ühendab selle tõelise LAN-segmendiga. Seejärel hoiab klient selles segmendis aadressi ja kuuleb selle broadcast-liiklust. Seetõttu näib sildamine nimeprobleemi ravivat. See teeb ka kliendi adresseerimisel sellest segmendist sõltuvaks.

Ravi on marsruudipiiri kaotamine, mitte mingi uus nimeoskus tunneli sees. Kõik, mida segment broadcastina saadab, ületab nüüd ka ühenduse.

Väikese labori jaoks on see aus vahetus. Hajutatud tööjõu puhul harva.

DNS-i ja WINS-i tõukamine on kitsam parandus

Andke kliendile konkreetne koht, kust küsida. dhcp-option DNS ja dhcp-option DOMAIN suunavad sisemised nimed serverile, mis tsooni tunneb, ja Windowsi klient, mis ikka NetBIOS-ile toetub, võib samamoodi saada WINS-serveri. Tunnel jääb marsruudituks ja segment jääb sinna, kuhu kuulub.

Kaks tingimust otsustavad, kas see töötab. Nimetatud server peab tsooni eest vastama ja päring peab olema tunnelist lubatud.

Testige resolverit kliendi poolelt, mitte serveri enda kestast. Lokaalselt töötav resolver ei ütle midagi selle kohta, mida tunnel edastab.

Tehke kindlaks, milline kiht ebaõnnestus

Pingige esmalt aadressi, seejärel lahendage nimi ja lugege, milline server vastas. Jaemine vastus serverilt, mis tsooni ei majuta, näeb teistsugune välja kui päring, mis ei lahkunud masinast kunagi. Nimi, mis laheneb, kuid keeldub ühendustest, on hoopis kolmas probleem.

Multicast on sama seina taga. Gruppi nagu 224.0.0.251 ei edastata marsruuditud tunnelist vaikimisi ja grupi marsruut ei ole piisav ilma multicast-teadliku teeta või reflektorita LAN-is.