Numele interne eșuează în VPN, iar site-urile publice se rezolvă

Un utilizator raportează că numele de gazdă din intranet nu se rezolvă prin VPN. Un al doilea raport, de pe același laptop, spune că un test de scurgere arată în continuare interogări răspunse de resolverul local. Par o singură problemă și sunt două, cu dovezi diferite, iar reparația obișnuită a primeia o agravează pe a doua. Separați-le înainte de a atinge vreo setare.

Două simptome care nu sunt o singură defecțiune

Eșecul de a rezolva un nume intern înseamnă că întrebarea a ajuns undeva unde nu există răspuns pentru ea. Interogările care părăsesc tunelul înseamnă că întrebarea a mers în locul greșit chiar și atunci când răspunsul era disponibil. Sunt defecțiuni opuse: una este un răspuns lipsă, cealaltă este o destinație în plus.

Capcana este că adăugarea resolverului de birou peste tot o repară pe prima și o garantează pe a doua. Adăugarea unui resolver public peste tot face invers.

Notați ambele observații cu marcaj de timp, apoi parcurgeți cele patru verificări de mai jos în ordine.

Resolverul cărui adaptor primește întrebarea

Pe Windows, clientul DNS alege serverele după ordinea de legare a adaptoarelor, iar adaptorul tunelului nu este automat primul. Deschideți setările avansate ale adaptorului și mutați conexiunea de acces la distanță deasupra adaptorului fizic, apoi reconectați ca schimbarea să se aplice unei sesiuni noi.

Ordinea de legare este doar prima jumătate. Clientul trebuie să știe și ce nume aparțin acelui adaptor, iar aceasta este o chestiune de sufix, nu de ordonare.

Puneți ipconfig /all al mașinii care funcționează lângă cel al laptopului, ambele luate cu tunelul activ. Mașina care funcționează va arăta un sufix DNS specific conexiunii pe adaptorul de birou, iar laptopul poate să nu arate niciunul pe tunel. Această diferență explică o întreagă clasă de rapoarte în care serverul este chiar acolo și numele tot eșuează, pentru că fără sufix numele scurt nu este niciodată completat în zona pe care o deservește resolverul de birou.

Un nume scurt are nevoie de sufix înainte de a avea nevoie de rută

Tastarea unui nume de gazdă necalificat cere resolverului să ghicească un domeniu. Ghidul vine din lista de sufixe atașată conexiunii, iar dacă acea listă este goală, interogarea pleacă drept o singură etichetă pe care nicio zonă privată nu o va potrivi.

Copiați sufixul mașinii care funcționează în proprietățile IPv4 ale adaptorului VPN, în fila DNS, apoi reconectați. Pe Linux echivalentul este domeniul de căutare de pe legătura tunelului, pe care systemd-resolved îl expune per legătură, nu global.

Țineți cele două setări separate în notițe. Un sufix schimbă ce se întreabă; adresa resolverului schimbă pe cine se întreabă. Repararea uneia cât cealaltă este greșită produce un rezultat care pare aleatoriu.

Întrebați direct resolverul, apoi numele

O interogare directă către resolverul de birou separă o problemă de nume de una de cale, pentru că ocolește complet selecția de resolver a clientului.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Prima comandă întreabă un server anume pentru un nume complet calificat. Dacă răspunde, resolverul și ruta către el sunt bune, iar defecțiunea este în selecție sau în sufix. Dacă expiră, adresa este greșită sau inaccesibilă, iar problema este de rutare, nu de DNS. A doua comandă arată ce se întâmplă cu numele scurt, iar a treia afișează configurația resolverului pe legătură pe un host systemd.

Atenție la răspunsurile wildcard, pe care unele rețele le returnează pentru nume necunoscute. Un răspuns plauzibil nu dovedește că serverul dorit a răspuns, așa că comparați adresa returnată cu cea pe care serviciul intern o folosește de fapt. Dacă adresa aparține unei pagini de parcare sau unui proxy, resolverul a răspuns, dar răspunsul nu a fost niciodată al dumneavoastră. Această distincție economisește o oră de urmărire a unui tunel care funcționa tot timpul.

Pe Linux, un client VPN care rescrie /etc/resolv.conf înlocuiește complet resolverele locale. vpnc expune DNSUpdate no pentru a opri asta, iar systemd-resolved poate direcționa doar domeniile listate către legătura tunelului. Ambele abordări păstrează numele publice la resolverul local trimițând totodată numele interne la birou.

Scurgerile sunt o regulă, nu o bifă

Rezolvarea numelor este un schimb UDP către portul 53, deci un tunel care transportă trafic web dar nu UDP lasă interogarea pe calea fizică. Dovediți-o capturând pe placa fizică în timp ce se rezolvă un nume public. O interogare vizibilă pe acea interfață în formă lizibilă înseamnă că tunelul nu o transportă.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Dacă interogarea apare pe acea interfață în formă lizibilă, tunelul nu o transportă. Reparația este o regulă care permite portul 53 doar către resolverul trimis de VPN și elimină alte destinații, plus o configurație de client care nu aruncă în silențiu opțiunea trimisă.

Ultima parte contează mai mult decât pare. Porniți OpenVPN cu route-nopull și opțiunea DNS trimisă dispare împreună cu rutele, dacă filtrul de pull nu este lărgit ca să o păstreze. Și un client care ignoră dhcp-option DNS va continua să folosească ce avea înainte. Orice schimbare pe partea de server are nevoie de o sesiune nouă ca să se aplice, fiindcă lista de resolvere este livrată când tunelul urcă, iar o sesiune veche continuă să arate starea veche.

Notați care defecțiune ați observat de fapt înainte de a închide tichetul. Un răspuns intern lipsă și o interogare care scapă din tunel cer reparații diferite, iar o schimbare de sufix care o repară pe prima poate înrăutăți în tăcere a doua. Următorul care preia tichetul se va baza pe etichetă, deci faceți eticheta exactă.