Două VPN-uri, un singur resolver: câștigă cine a scris ultimul

Doi clienți VPN sunt conectați, unul pentru muncă și unul pentru o rețea de laborator, iar numele interne se rezolvă doar pentru clientul care s-a conectat ultimul. Acest tipar pare o eroare într-unul dintre clienți. De obicei este rezultatul previzibil al două programe care scriu aceeași configurație de resolver fără o înțelegere despre cine deține ce nume.

Mitul: cel mai nou VPN deține DNS

Nu există o regulă generală că cea mai recentă conexiune câștigă. Ce se întâmplă depinde de mecanismul platformei și de modul în care fiecare client îl scrie. Un client care înlocuiește un fișier de resolver produce un rezultat; un client care adaugă un domeniu per legătură produce altul; un client care nu face nimic lasă starea anterioară intactă.

Comportamentul observat este deci o proprietate a celor două implementări, nu o prioritate documentată. Raționamentul bazat doar pe ordinea de pornire va fi uneori corect și uneori greșit în moduri greu de reprodus. Scrieți în schimb maparea. Un design care trăiește în doi clienți nu este un design.

Asociați spațiile de nume cu resolverele

Enumerați sufixele private și resolverul cerut de fiecare rețea, apoi decideți unde trebuie să ajungă numele publice. Acea listă este designul. Fără ea, clienții iau decizia din întâmplare.

O platformă care acceptă DNS per legătură sau domenii de rutare poate exprima separarea în mod deliberat: un domeniu merge la o legătură, alt domeniu la cealaltă, iar tot restul urmează o valoare implicită explicită. Două scripturi plate care suprascriu același fișier nu pot păstra acel design, pentru că fiecare crede că deține întreaga configurație.

În Windows, tabelul de politică pentru rezolvarea numelor poate direcționa sufixele către servere anume, iar un client VPN poate instala reguli acolo. Verificați politica, nu lista adaptoarelor, pentru că nu lista adaptoarelor este cea care rezolvă numele.

Păstrați o cale de bootstrap

Fiecare client trebuie să-și găsească propriul punct final înainte de a putea folosi serviciul oferit de acel punct. Dacă numele de gazdă al punctului final poate fi rezolvat doar prin tunel, iar tunelul are nevoie de numele de gazdă rezolvat, aveți o dependență circulară care apare ca un timeout de conexiune. Păstrați o cale de bootstrap în afara ambelor tuneluri. Nu costă nimic până în ziua în care salvează conexiunea.

Uitați-vă la calea către fiecare resolver, nu doar la numele configurat pentru el. Un resolver accesibil doar prin celălalt tunel se comportă ca unul lipsă, iar simptomul este un timeout, nu o eroare de rutare.

Adresele suprapuse nu sunt o problemă de DNS

Două rețele private care folosesc același interval de adrese nu se repară prin ordinea DNS. Dacă ambele tuneluri revendică 10.0.0.0/8, un nume rezolvat corect indică totuși o adresă către care gazda nu poate ruta tunelul corect. Este nevoie de o soluție la nivel de adresă, cum ar fi intervale distincte, un spațiu de nume sau traducere, nu o altă setare de resolver. Decidarea devreme evită un ocol lung prin configurația DNS care nu ar fi funcționat niciodată.

Comparați alocările de adrese ale celor două tuneluri înainte de a învinui rezolvarea numelor. Când ambele părți împing același prefix, gazda păstrează o singură rută pentru el, iar un nume rezolvat prin al doilea tunel ajunge totuși pe o adresă deținută de primul tunel. Intervale distincte, un spațiu de nume pentru fiecare rețea sau traducere sunt corecțiile; după conectarea fiecărui client, confirmați că tabelul de rutare arată calea dorită.

Demonstrați cu aplicații reale

Alegeți două gazde care există doar în propriul spațiu de nume și un nume public, apoi rezolvați fiecare prin clientul care ar trebui să îl dețină. Un răspuns corect de la resolverul așteptat nu demonstrează că aplicația ajunge la gazdă, pentru că ruta către acea adresă poate eșua în continuare. Însoțiți fiecare interogare cu un test de conexiune din programul pe care utilizatorul îl va rula efectiv.

Un client cu propria opțiune de DNS criptat poate ocoli politica pe care tocmai ați verificat-o, așa că verificați acea setare ca parte a revizuirii. Apoi reconectați ambii clienți în ordinea acceptată de furnizor și repetați interogările; dacă răspunsurile se inversează când ordinea se schimbă, un scriitor concurent deține încă o parte a configurației. Aflați ce componentă instalează regula - clientul, profilul sistemului de operare sau un agent de management - înainte de a edita ceva. Notați ordinea și proprietarii pentru ca următoarea persoană să nu trebuiască să le redescopere.