De ce intrarea ta din /etc/hosts nu ajunge la DNS-ul VPN-ului

Ai adăugat un nume în /etc/hosts, te-ai conectat la VPN și te așteptai ca înregistrarea să apară pentru toată lumea. Nu se întâmplă, iar surpriza vine de obicei cu un al doilea simptom: numele se rezolvă pe mașina ta și eșuează la un coleg, ceea ce arată ca un serviciu DNS al VPN-ului stricat și în realitate este fișierul hosts făcând exact ceea ce a fost proiectat să facă. Un fișier hosts este configurație locală de rezolvare a numelor, nu o actualizare de zonă, și nimic dintr-o conexiune VPN normală nu îl încarcă.

Hosts este o suprascriere locală, nu o actualizare de zonă

Fișierul este o listă de mapări pe care bibliotecile de serviciu de nume le consultă înainte de, sau în locul, interogării unui server DNS. O linie precum 10.40.0.20 build.corp.example schimbă ceea ce concluzionează aplicațiile de pe acea singură mașină. Nu creează o înregistrare, nu călătorește prin tunel, iar serverul DNS către care indică tunelul nu are nicio idee că ea există.

De aceea eșecul este asimetric. Clientul tău primește un răspuns din fișier. Un alt client întreabă serverul DNS al VPN-ului, care nu returnează nimic, iar aplicația raportează că numele nu există. Ambele mașini se comportă corect; doar una are o suprascriere pe care cealaltă nu a văzut-o niciodată.

Două comenzi, două componente diferite

Cea mai rapidă cale de a opri dezbaterea este să faci diferența vizibilă în două comenzi, ambele rulate pe clientul care are intrarea hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Prima întreabă calea de căutare proprie a sistemului, care pe un sistem glibc tipic citește fișiere locale înainte de DNS. A doua trimite o interogare DNS direct la serverul de la acea adresă și nu consultă deloc fișiere locale. Când prima returnează intrarea ta și a doua returnează NXDOMAIN, ai demonstrat că înregistrarea nu există în DNS și că mașina ta răspunde dintr-o suprascriere locală.

Ordinea este configurabilă și merită verificată înainte de a trage orice concluzie despre o anumită distribuție. Uită-te la linia hosts: din /etc/nsswitch.conf; hosts: files dns consultă mai întâi fișierele. Nu copia acel exemplu peste o configurație funcțională doar pentru a schimba ordinea, pentru că sistemele reale listează adesea surse suplimentare și intrări de serviciu condiționale pe care exemplul nu le conține.

systemd-resolved estompează testul

Pe un sistem care folosește systemd-resolved, stub-ul local servește și nume din baza de date hosts. De aceea interogarea lui 127.0.0.53 nu este un test independent al serverului de la distanță, chiar dacă arată ca o interogare DNS și se comportă ca atare. Poți confirma ce știe resolver-ul și ce servere ar întreba cu:

resolvectl query build.corp.example
resolvectl status

Ieșirea comenzii status numește serverele DNS pentru fiecare legătură, și astfel afli dacă legătura VPN a primit măcar un resolver. Această întrebare este separată de intrarea hosts și este cea care merită pusă atunci când un nume privat eșuează pentru toți utilizatorii, nu pentru unul singur.

Aplicațiile pot adăuga încă un strat. Un browser cu propria setare DNS-over-HTTPS, un container cu propria configurație de resolver sau un mediu de execuție care memorează căutările pe toată durata de viață a procesului pot răspunde fiecare altfel decât sistemul. Testează aplicația care contează pentru tine în loc să presupui că o singură comandă descrie fiecare program de pe mașină.

Ce împărtășește cu adevărat un nume prin VPN

Dacă un nume privat trebuie să funcționeze pentru toți, are nevoie de un proprietar la care resolver-ul fiecăruia poate ajunge. Răspunsul curat este să publici înregistrarea într-o zonă administrată și să faci acea zonă rezolvabilă prin calea DNS prevăzută a VPN-ului. Atunci înregistrarea are o singură sursă de adevăr, o urmă de audit și un ciclu de viață, iar nimeni nu trebuie să-și amintească ce laptop poartă o suprascriere locală.

Distribuirea fișierelor hosts este o alternativă legitimă și este administrarea punctelor finale, nu un serviciu de nume. Dacă o alegi, fișierul trebuie implementat, versionat și eliminat de ceea ce administrează flota, și așa trebuie descris în proiect. „VPN-ul se ocupă de asta” nu este o descriere a acelui proces.

Înregistrarea DNS dinamică este un al treilea mecanism, cu propriile permisiuni, autentificare a actualizărilor și durată de viață a înregistrării. Ea nu decurge dintr-o intrare hosts și nu decurge nici din simpla conectare a unui client, decât dacă serverul și clientul au fost ambele configurate pentru asta. O înregistrare care apare de la sine este un semnal că cineva a activat actualizările securizate și un client care se înregistrează singur, iar acea configurație aparține înregistrării de proiect, nu unui fir de depanare. Dacă nimeni nu poate spune cine deține acea setare, tratează înregistrarea automată ca neverificată și păstrează zona administrată ca sursă de adevăr.

Un nume rezolvat nu este o rută

Rezolvarea numelor și accesibilitatea sunt lucruri separate, iar o mapare locală învechită este modul clasic de a le confunda. O intrare hosts care indică o adresă care s-a mutat va continua să selecteze gazda învechită mult după ce DNS-ul a fost corectat, iar simptomul arată ca o defecțiune de rutare la un nume care se rezolvă bine.

Așadar, când raportul este „numele se rezolvă, dar serviciul nu este accesibil”, compară căutarea sistemului cu o interogare explicită către serverul DNS al VPN-ului, apoi verifică adresa obținută față de cea pe care serviciul o folosește de fapt. Referința systemd-resolved documentează sursele locale pe care le consultă, iar aceea este harta de care ai nevoie pentru acea comparație.

Apoi corectează suprascrierea prin proprietarul ei. Eliminarea unei linii din propriul fișier hosts nu face nimic pentru cele douăsprezece laptopuri care au primit aceeași linie dintr-un script de implementare, și aceasta este versiunea acestei probleme pe care oamenii o au de fapt.