De ce căutările de nume eșuează printr-un tunel OpenVPN rutat

O gazdă răspunde la ping după adresă și eșuează la fiecare căutare după nume. Tunelul este activ și ruta există, așa că concluzia naturală este că VPN-ul este configurat greșit. O concluzie mai utilă este că acea căutare nu a fost niciodată rutabilă: un tunel rutat transportă unicast IP, în timp ce interogarea era o difuzie care căuta un segment ce nu există pe cealaltă parte. De îndată ce nepotrivirea de straturi devine vizibilă, remediile se ordonează singure după cost.

Mit: tunelul este stricat pentru că numele eșuează

Simptomul convinge pentru că tot ce se află deasupra stratului de nume funcționează. Adresele sunt rutate, interfața este activă, iar partenerul răspunde la ping. Ce a eșuat este un mecanism de descoperire care nu a avut niciodată o cale printr-o legătură punct la punct, iar aceasta este o afirmație diferită de un tunel stricat. Separarea celor două afirmații este cea mai mare parte a diagnosticului.

Tratarea ca defect de tunel duce la modificări de profil care nu pot ajuta. Adăugarea de opțiuni, schimbarea cifrării sau reinstalarea clientului lasă difuzia exact unde era.

Numiți mecanismul care a eșuat înainte de a numi remediul. O căutare care folosește difuzia are nevoie de un segment, în timp ce o căutare care folosește un resolver are nevoie de o adresă căreia să îi întrebe.

Ce transportă TUN și ce nu transportă

Un dispozitiv TUN este o interfață IP, și exact asta îl face rutabil. OpenVPN îi dă clientului o adresă și un set de rute, iar de acolo clientul trimite datagrame unui partener. Nimic din acel model nu creează o legătură partajată în care fiecare gazdă aude fiecare cadru.

Traficul de descoperire nu se potrivește deloc în acel model. Interogările vechi de nume din Windows, anunțurile SSDP și cererile mDNS sunt trimise tuturor dintr-un segment, nu unei singure destinații. O legătură rutată nu are niciun «toți» căruia să îi trimită. Fiecare dintre acele mecanisme presupune un mediu partajat.

Tunelul poate deci fi sănătos în timp ce descoperirea eșuează complet. Aceasta este propoziția de care trebuie să ne ținem când cineva raportează că VPN-ul este căzut.

Puntea funcționează eliminând granița

Un dispozitiv TAP transportă cadre, iar un pod îl leagă de un segment LAN real. Clientul are atunci o adresă în acel segment și aude traficul său de difuzie. De aceea podul pare să vindece problema numelor. Face, de asemenea, clientul dependent de acel segment pentru adresare.

Remediul este eliminarea graniței de rutare, nu o capacitate nouă de nume în interiorul tunelului. Tot ce difuzează segmentul traversează acum și legătura.

Pentru un laborator mic este un schimb corect. Într-o echipă dispersată, rareori.

Împingerea DNS și WINS este remediul mai îngust

Dați clientului un loc anume unde să întrebe. dhcp-option DNS și dhcp-option DOMAIN îndreaptă numele interne către un server care cunoaște zona, iar un client Windows care se bazează încă pe NetBIOS poate primi un server WINS în același fel. Tunelul rămâne rutat, iar segmentul rămâne unde îi este locul.

Două condiții decid dacă va funcționa. Serverul numit trebuie să răspundă pentru zonă, iar interogarea trebuie să fie permisă prin tunel.

Testați resolverul din client, nu din shell-ul serverului însuși. Un resolver care funcționează local nu spune nimic despre ce transportă tunelul.

Aflați care strat a eșuat

Faceți mai întâi ping la adresă, apoi rezolvați numele și citiți care server a răspuns. Un răspuns negativ de la un server care nu găzduiește zona arată altfel decât o interogare care nu a părăsit niciodată mașina. Un nume care se rezolvă dar refuză conexiuni este o a treia problemă, cu totul diferită.

Multicast stă în spatele aceluiași zid. Un grup precum 224.0.0.251 nu este redirecționat implicit printr-un tunel rutat, iar o rută pentru grup nu este suficientă fără o cale conștientă de multicast sau un reflector în LAN.