Zakaj iskanje imen odpove skozi usmerjen tunel OpenVPN

Gostitelj odgovori na ping po naslovu in odpove pri vsakem iskanju po imenu. Tunel je vzpostavljen in pot obstaja, zato je naravna ugotovitev, da je VPN napačno nastavljen. Bolj uporabna ugotovitev je, da iskanje ni bilo nikoli usmerljivo: usmerjen tunel prenaša unicast IP, medtem ko je bila poizvedba broadcast, ki je iskal segment, ki ga na drugi strani ni. Ko je neskladje plasti vidno, se popravki sami razvrstijo po ceni.

Mit: tunel je pokvarjen, ker imena odpovedo

Simptom je prepričljiv, ker vse nad plastjo imen deluje. Naslovi se usmerjajo, vmesnik je vzpostavljen in partner odgovori na ping. Odpovedal je mehanizem odkrivanja, ki ni imel nikoli poti čez povezavo od točke do točke, in to je druga trditev kot pokvarjen tunel. Ločevanje teh dveh trditev je večina diagnoze.

Če to obravnavamo kot okvaro tunela, pridemo do sprememb profila, ki ne morejo pomagati. Dodajanje možnosti, menjava šifriranja ali ponovna namestitev odjemalca pusti broadcast točno tam, kjer je bil.

Poimenujte mehanizem, ki je odpovedal, preden poimenujete popravek. Iskanje z broadcastom potrebuje segment, medtem ko iskanje z razreševalnikom potrebuje naslov, na katerega se obrne.

Kaj TUN prenaša in česa ne

Naprava TUN je vmesnik IP in prav to jo naredi usmerljivo. OpenVPN odjemalcu dodeli naslov in nabor poti, od takrat pa odjemalec pošilja datagrame partnerju. Nič v tem modelu ne ustvari skupne povezave, kjer vsak gostitelj sliši vsak okvir.

Promet odkrivanja se v ta model sploh ne vklopi. Starejše poizvedbe imen v Windows, obvestila SSDP in zahteve mDNS se pošiljajo vsem v segmentu namesto enemu cilju. Usmerjena povezava nima nobenih »vsi«, kamor bi pošiljala. Vsak od teh mehanizmov predpostavlja skupno medij.

Zato je tunel lahko zdrav, medtem ko odkrivanje popolnoma odpove. Prav za ta stavek se je treba držati, ko nekdo poroča, da je VPN dol.

Premostitev deluje z odstranitvijo meje

Naprava TAP prenaša okvire in most jo poveže z resničnim segmentom LAN. Odjemalec ima nato naslov v tem segmentu in sliši njegov broadcastni promet. Zato se zdi, da premostitev pozdravi težavo z imeni. Odjemalca tudi naredi odvisnega od tega segmenta pri naslavljanju.

Zdravilo je odstranitev usmerjevalne meje, ne kakšna nova zmožnost imen znotraj tunela. Vse, kar segment oddaja, zdaj prečka tudi povezavo.

Za majhen laboratorij je to poštena menjava. Za razpršeno ekipo le redko.

Potiskanje DNS in WINS je ožja rešitev

Odjemalcu dajte konkretno mesto za vprašanja. dhcp-option DNS in dhcp-option DOMAIN usmerita notranja imena na strežnik, ki pozna območje, in odjemalec Windows, ki se še opira na NetBIOS, lahko na enak način prejme strežnik WINS. Tunel ostane usmerjen in segment ostane tam, kamor spada.

Dva pogoja odločata, ali bo to delovalo. Navedeni strežnik mora odgovarjati za območje in poizvedba mora biti dovoljena skozi tunel.

Razreševalnik preizkusite z odjemalca, ne iz lastne lupine strežnika. Razreševalnik, ki deluje lokalno, ne pove ničesar o tem, kaj prenaša tunel.

Ugotovite, katera plast je odpovedala

Najprej pingajte naslov, nato razrešite ime in preberite, kateri strežnik je odgovoril. Negativen odgovor strežnika, ki ne gosti območja, izgleda drugače kot poizvedba, ki stroja ni nikoli zapustila. Ime, ki se razreši, a zavrača povezave, je povsem tretja težava.

Multicast stoji za isto steno. Skupina, kakršna je 224.0.0.251, se privzeto ne posreduje skozi usmerjen tunel, in pot za skupino ne zadošča brez poti, ki razume multicast, ali odsevnika v omrežju LAN.