DNS divizat și VPN: regulile de domeniu nu sunt rute IP

Laptopul tău rezolvă intranet.corp prin tunel, în timp ce gitlab.com continuă să meargă la resolverul furnizorului, și aceasta este aranjamentul care funcționează conform proiectării. Două decizii separate l-au produs: o regulă de potrivire a numelui a ales resolverul, iar o rută a adus răspunsul înapoi. Strică oricare dintre ele și browserul arată o defecțiune care, din exterior, pare aceeași. Majoritatea rapoartelor despre DNS divizat descriu a doua defecțiune citând în același timp dovezi despre prima.

Cele două jumătăți trăiesc în locuri diferite și sunt de obicei editate de oameni diferiți. Una este politica DNS atașată profilului VPN, cealaltă este o rută pe care tunelul o instalează sau o reține. Depanarea se blochează când nimeni nu stabilește care jumătate s-a mișcat de fapt.

Două decizii ascunse într-o singură cerere

Jumătatea numelui este un obiect de politică, nu o rută. În Windows este o politică de rezolvare a numelor pe profilul VPN; pe platformele Apple un set de domenii de potrivire pe un obiect de setări DNS; în Linux un domeniu de rutare, o linie de resolver divizat sau ordinea comutatorului de servicii de nume. Jumătatea căii este rutare obișnuită, instalată de tunel sau manual, și nu are nicio idee ce este un nume de gazdă. Un profil care admite un sufix decide doar cine răspunde; nu face niciodată răspunsul accesibil.

Un test rapid de simptome le separă: înlocuiește numele cu o adresă. Dacă adresa funcționează, calea este în regulă și regula greșită. Dacă adresa eșuează și ea, regula poate fi corectă și calea lipsi.

Cum exprimă fiecare platformă aceeași regulă de nume

Intenția este identică, iar numele câmpurilor nu. Un exemplu copiat de la un client la altul este analizat curat și nu se potrivește niciodată. Cele trei forme arată astfel:

Un domeniu de potrivire sau de rutare este un test de sufix, deci intranet.corp acoperă git.intranet.corp și nu acoperă corp.intranet, iar inversarea acestui lucru este cea mai frecventă greșeală din întreaga configurație. Windows poartă maparea ca politică de rezolvare a numelor atașată profilului, cu propria ordine de prioritate față de orice listă de sufixe pe care interfața o avea deja. Platformele Apple atașează domeniile de potrivire la obiectul de setări DNS al extensiei de rețea, iar sistemul le aplică pentru fiecare resolver delimitat. Niciuna dintre aceste forme nu este o rută și niciuna nu poate face o adresă inaccesibilă accesibilă. Referința politica de rezolvare a numelor din Windows enumeră numele câmpurilor și regulile de prioritate pentru acea platformă, iar ele nu sunt cele folosite de documentele Apple sau systemd.

Un răspuns corect are totuși nevoie de o cale

Răspunsul unui resolver este doar o adresă, iar aplicația trebuie încă să ajungă acolo. Un design de tunel divizat împinge adesea 10.20.0.0/16 și reține ruta implicită, așa că numele intern se rezolvă, iar conexiunea se blochează apoi. Cazul opus este la fel de frecvent: ruta există, un resolver public răspunde numelui privat cu NXDOMAIN, iar defecțiunea este înregistrată ca problemă de rutare. Testarea căii mai întâi te lasă să te holbezi la rute pentru un nume care nu s-ar fi rezolvat niciodată.

Există și o a treia poartă pe care niciuna dintre jumătăți nu o acoperă. Un ACL pe gateway, o regulă de firewall sau o politică pe partea clientului pot arunca conexiunea după ce ambele decizii au fost corecte. Când numele se rezolvă, ruta există și conexiunea tot expiră, oprește testarea DNS.

Testarea numelor și a căilor într-o ordine fixă

Alege o ordine și ține-te de ea, altfel vei urmări pasul care a eșuat ultima dată. Rezolvă numele intern complet documentat, confirmă că răspunsul este o adresă pe care tabelul de rutare o poate duce, apoi repetă cu un nume public pentru a dovedi că tunelul nu a capturat totul. Pe un host systemd interogarea și domeniul de rutare al resolverului sunt la o comandă distanță:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Un client Windows pune aceleași două întrebări cu alte cmdleturi. Al doilea raportează interfața pe care sistemul ar folosi-o de fapt:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Dacă căutarea returnează o adresă și verificarea căii numește interfața fizică, regula numelui a funcționat, iar ruta nu. Dacă numele scurt eșuează în timp ce numele complet se rezolvă, lista de sufixe este greșită, nu resolverul.

Unde merge de obicei greșit comparația

Prima greșeală este să întrebi un resolver public nelegat despre un nume privat și să citești refuzul ca dovadă despre VPN. A doua este să presupui că o căutare publică funcțională dovedește calea resolverului tunelului. A treia este să tratezi tunelul divizat și DNS-ul divizat ca o singură decizie de proiectare, când o implementare poate fi corectă într-unul și stricată în celălalt. Fiecare greșeală produce concluzii încrezătoare dintr-un test care nu a exersat niciodată partea acuzată.

Un browser cu propriul DNS securizat poate ocoli și el regula sistemului, de aceea faptul că un browser eșuează în timp ce altul reușește nu este o contradicție. Compară resolverul care a răspuns, nu browserul care s-a plâns.

Odată ce ambele jumătăți sunt vizibile, întrebarea rămasă este de politică și nu tehnică: ce spații de nume aparțin organizației, cine deține fiecare răspuns și care dintre ele ar trebui să părăsească mașina. Scrie asta lângă profil, pentru că următoarea persoană care atinge regula va avea nevoie de ea.