De ce resolv.conf arată DNS-ul VPN-ului tău, dar căutările îl ignoră

În jurnale nimic nu pare greșit: interfața este activă, rezolvatorul raportează serverul DNS al VPN-ului, iar fișierul de pe disc îl enumeră. Totuși, un nume de gazdă intern este încă rezolvat prin routerul local. Cele trei afirmații nu se contrazic, pentru că fișierul, starea fiecărei legături și calea căutării sunt obiecte diferite care împart din întâmplare același nume. În continuare este calea pe care o interogare o parcurge efectiv pe un host cu systemd-resolved.

Trei obiecte numite resolv.conf

Pe un host cu resolved, /etc/resolv.conf este de obicei o legătură simbolică către /run/systemd/resolve/stub-resolv.conf. Acea țintă conține adresa unui ascultător stub local, 127.0.0.53, plus domeniile de căutare calculate de resolved. Este o vedere a stării, nu starea în sine.

Starea trăiește în configurația resolved pe fiecare legătură, de aceea resolvectl status poate contrazice fișierul și totuși să aibă dreptate. Fiecare legătură poartă propriile servere și propriile domenii de rutare, iar stub-ul consultă aceste date când sosește o interogare. Manualul systemd-resolved descrie fișierele generate și modelul pe fiecare legătură; separarea dintre vedere și stare este partea care merită reținută. Modificarea țintei legăturii simbolice schimbă ce citesc clienții tradiționali, nu ce știe rezolvatorul.

Un al treilea obiect, /run/systemd/resolve/resolv.conf, aplatizează fiecare legătură într-o singură listă de servere. Un program îndreptat spre acel fișier trimite interogările direct la serverele enumerate și ocolește stub-ul, așa că politica pe fiecare legătură nu i se mai aplică. De aceea două programe de pe aceeași mașină pot răspunde diferit la același nume, și niciunul nu este defect.

Urmărește o căutare prin NSS

glibc citește /etc/nsswitch.conf pentru a decide cine răspunde la un nume. O linie hosts care conține resolve direcționează întrebarea spre nss-resolve, care întreabă resolved prin D-Bus și primește răspunsul pe legătură. O linie doar cu files dns trimite interogarea la adresa pe care o deține /etc/resolv.conf.

Acea singură linie explică majoritatea neînțelegerilor dintre un browser și dig. dig citește resolv.conf direct și nu atinge niciodată NSS, așa că testează stub-ul sau un server superior în locul căii folosite de aplicație. getent hosts internal.example trece prin NSS, iar compararea răspunsului său cu cel al dig este prima măsurătoare utilă.

Aplicațiile care își aduc propriul rezolvator, sau vorbesc DNS prin HTTPS cu un punct final fix, ocolesc ambele căi. Nimic din resolv.conf sau din starea resolved nu le restricționează.

Verifică cine deține fișierul și încotro indică

Citește lanțul de legături înainte de a schimba ceva, pentru că proprietatea decide care fișier este autoritar. Fiecare comandă de mai jos doar citește starea.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Prima linie tipărește legătura și ținta ei împreună, iar un fișier obișnuit deținut de un script VPN înseamnă că rezolvatorul nu tratează niciodată acea scriere ca intrare. Ieșirea stării enumeră serverele pe fiecare legătură plus domeniile de rutare care decid unde merge fiecare interogare. Linia nsswitch spune dacă stub-ul este consultat măcar, așa că o adresă stub în fișier fără resolve acolo înseamnă că interogările ajung la ascultătorul local în timp ce nimic nu gestionează divizarea. Și acea ultimă listă contează, pentru că un host fără stub-resolv.conf nu rulează aranjamentul descris aici.

Dacă lanțul se termină într-un fișier administrat de alt pachet, clientul VPN și acel pachet sunt cei doi proprietari de împăcat. Înlocuirea legăturii aruncă munca unui proprietar și o lasă pe a celuilalt la loc.

Repară la proprietarul legăturii

O conexiune VPN ar trebui să-și înregistreze serverele și domeniile pe propria legătură, apoi să le retragă la deconectare. Integrarea resolved a NetworkManager și ajutorul propriu al clientului funcționează ambele așa; un script care doar rescrie resolv.conf nu.

Pe o legătură care există deja, setările de rulare arată mecanismul. resolvectl dns tun0 10.40.0.53 atașează un server, iar resolvectl domain tun0 '~corp.example' atașează un domeniu de rutare. Tilda este caracterul portant: limitează interogările pentru acel sufix la această legătură și lasă restul în pace, în timp ce aceeași valoare fără ea devine un domeniu de căutare și divizarea se evaporă. Acele adrese sunt exemple de laborator, nu o configurație permanentă. Confirmă cu resolvectl query host.corp.example și citește care legătură a răspuns.

Un server înregistrat are totuși nevoie de o rută. Când interogarea ajunge pe legătura corectă și expiră, defectul este în accesibilitatea prin tunel, nu în proprietatea rezolvatorului.

Cum arată o stare funcțională

Un rezultat sănătos este consecvent în toate cele trei vederi: serverele pe fiecare legătură corespund cu ce a distribuit VPN-ul, domeniile de rutare acoperă doar sufixe interne, iar aplicația care contează rezolvă un nume intern în timp ce un nume public urmează în continuare calea locală. O singură interogare reușită dovedește mai puțin decât acea concordanță.

Apoi deconectează și repetă ambele interogări. Un client care își lasă domeniile înregistrate după demontare produce o mașină care eșuează căutările interne ore mai târziu, fără tunel deschis și fără o cauză evidentă.