De ce eșuează numele DNS private pe clienții VPN și unde trebuie verificat

Deschizi un laptop într-o cameră de hotel, pornești clientul, tastezi numele serverului de fișiere intern și nu primești nimic. Tunelul raportează conectat, iar un ping către o adresă din aceeași subrețea încă răspunde, deci transportul în sine este în regulă. Doar numele eșuează, iar acel gol reduce problema la două locuri: ce resolver a întrebat clientul și dacă răspunsul primit poate reveni prin tunel. Rezolvă una și omite-o pe cealaltă, iar defecțiunea pur și simplu se mută.

Înainte de a edita vreun profil, confirmă ce face clientul cu numele. Pe Linux, resolvectl query files.corp.example arată ce legătură și ce resolver au produs răspunsul. Pe Windows, Resolve-DnsName files.corp.example arată serverul care a răspuns și adresa pe care a returnat-o.

Citește răspunsul înainte de a schimba ceva

Dacă numele revine ca NXDOMAIN în câteva milisecunde, interogarea nu a ajuns niciodată în zona ta și a răspuns un resolver public sau al hotelului. Dacă revine după o pauză lungă, ceva aruncă portul UDP 53 pe drum și clientul a ajuns în cele din urmă să recurgă la altul. Dacă răspunde cu adresa corectă dar conexiunea tot se blochează, rezolvarea e în regulă și problema ta este rutarea sau serviciul în sine.

Acea împărțire în trei economisește o oră de presupuneri. Îți spune și dacă trebuie să atingi deloc VPN-ul: un nume care se rezolvă la adresa privată corectă a dovedit deja calea resolverului, deci munca rămasă este pe calea datelor.

Distribuie resolverul din interiorul tunelului

Clienții se împart în două grupuri. Unuia i se poate indica un resolver de către server în timpul stabilirii conexiunii; celălalt ține setarea într-un fișier local pe care nicio poartă nu îl poate schimba de la distanță.

OpenVPN este în primul grup. Pe server, push "dhcp-option DNS 10.8.0.53" și push "dhcp-option DOMAIN corp.example" coboară pe canalul de control, dar numai dacă în configurația clientului pull este încă activat. Un client editat manual care poartă pull-filter ignore "dhcp-option" nu le va vedea niciodată, iar acea singură linie explică un număr surprinzător de cazuri de „serverul îl împinge, dar laptopul meu nu este de acord”.

WireGuard este în al doilea grup, pentru că protocolul nu are deloc negociere de opțiuni. Resolverul și domeniul de căutare intră în blocul [Interface] al clientului ca DNS = 10.8.0.53, corp.example. wg-quick aplică asta prin resolvconf sau systemd-resolved, iar pe Windows clientul oficial instalează reguli NRPT care există doar cât timp tunelul este ridicat: Get-DnsClientNrptPolicy le listează, ceea ce îl face o modalitate rapidă de a vedea dacă clientul ți-a aplicat vreodată fișierul.

IPsec/IKEv2 stă la mijloc. Pluginul attr al strongSwan poate returna un server DNS luat dintr-un pool, iar un client Windows îl acceptă de obicei, dar un profil care își fixează propriul server de nume câștigă în fața a orice oferă poarta. Pe un client Linux, pasul manual echivalent este resolvectl dns wg0 10.8.0.53 urmat de resolvectl domain wg0 '~corp.example'; ambele dispar odată cu interfața, exact ce vrei pentru o setare delimitată la tunel.

Delimitează sufixul în loc să înghiți fiecare interogare

Să îndrepți toată lista de resolvere a clientului spre serverul tău intern este ușor și de obicei greșit. Atunci fiecare nume public se rezolvă prin ieșirea centrului tău de date, CDN-urile returnează adrese îndepărtate, iar o cădere a resolverului duce cu ea navigarea utilizatorului.

Trimite spre interior doar sufixul privat. În systemd-resolved, un domeniu care începe cu ~ este doar pentru rutare, deci ~corp.example înseamnă că interogările sub acel sufix merg la serverele acelei legături, în timp ce tot restul continuă să folosească rețeaua fizică. Windows face același lucru cu reguli NRPT delimitate la un spațiu de nume, iar macOS cu un fișier de resolver suplimentar sub /etc/resolver/.

Numele multicast merită un răspuns propriu. Numele .local sunt link-local prin construcție (RFC 6762), iar o interfață tun punct-la-punct nu transportă acel grup multicast, deci adăugarea unui resolver public nu le publică, iar întrebarea unui resolver intern unicast despre ele returnează NXDOMAIN. Un reflector precum avahi în modul reflector poate lega două segmente, dar aceea este o decizie pe partea serverului pe care niciun client nu o poate cere. Dacă o imprimantă sau un NAS trebuie să fie accesibil după nume, dă-i în schimb o înregistrare A în zona ta.

Dovedește că răspunsul poate reveni

Un răspuns corect care indică o adresă inaccesibilă arată exact ca o problemă de resolver până verifici ruta. Întreabă nucleul încotro ar merge răspunsul: ip route get 10.20.5.20 numește interfața și, mai util, adresa sursă pe care ar folosi-o.

Urmărește adresa resolverului însăși. Un client cu DNS = 10.8.0.53 lângă AllowedIPs = 10.20.0.0/16 își trimite interogările prin NIC-ul fizic, unde mor în liniște, pentru că resolverul nu se află în niciun prefix pe care tunelul îl revendică. Acea nepotrivire este cea mai frecventă cauză unică din toată această zonă și rămâne invizibilă dacă nu compari setarea DNS cu prefixele permise linie cu linie.

Intervalele suprapuse provoacă defecțiunea opusă. Răspunsul este corect, ruta există și indică gazda greșită, pentru că 192.168.0.0/24 acasă este mai specifică decât ruta tunelului către același interval. Renumerotează o parte sau împinge o rută mai îngustă, apoi confirmă firewallul și calea de întoarcere a gazdei serviciului; notele strongSwan despre redirecționare acoperă partea sysctl a acelei căi.

Certificatele sunt o verificare de identitate separată pe care oamenii o pun pe seama DNS-ului. Dacă browserul raportează o nepotrivire de nume în loc de o eroare de rezolvare, căutarea a funcționat deja și ceea ce trebuie reparat este SAN-ul din certificat. Testează HTTPS pe nume, niciodată pe IP-ul gol.

Retestează de la client, nu de la poartă

Testează în aplicația de care se plânge utilizatorul, pentru că o căutare din linia de comandă nu dovedește că browserul urmează aceeași cale. DNS-ul securizat al Chrome și network.trr.mode din Firefox pot ocoli complet resolverul sistemului, iar când o fac, un nume privat eșuează sau se scurge către un resolver public. Compararea resolvectl query cu un dig @10.8.0.53 files.corp.example rulat manual îți spune care dintre cele două s-a întâmplat.

Apoi deconectează și reconectează înainte de a declară problema rezolvată. Setările aplicate manual unei interfețe dispar odată cu interfața, iar un profil care părea corect doar din cauza unei modificări locale rămase va eșua la următoarea pornire.

O listă scurtă pentru următorul calculator: numele se rezolvă prin resolverul tunelului, sufixul este delimitat în loc să fie global, adresa resolverului se află în interiorul prefixelor permise, gazda din răspuns răspunde pe portul serviciului, iar certificatul acoperă numele tastat de utilizator.