Numele de gazdă VPN eșuează, adresele IP funcționează: unde să te uiți

Poți deschide partajarea după adresă, iar aceeași partajare după nume eșuează, ceea ce înseamnă că tunelul transportă pachete, iar stratul de nume nu. Acea singură observație economisește un ocol prin modificări de firewall și de rute. Numele au nevoie de un sufix, de un resolver și de o cale pentru interogare, iar un client VPN poate instala o rută fără a instala niciuna dintre ele. Parcurge cele patru verificări de mai jos în ordine și oprește-te la prima care se rupe.

Un nume pune o întrebare pe care o adresă nu o pune

O adresă este o destinație pe care stiva o poate folosi imediat. Un nume scurt este o întrebare care trebuie extinsă cu un sufix, trimisă unui resolver și la care trebuie să răspundă ceva ce cunoaște zona. Un tunel care instalează rute dar niciun resolver lasă primul funcțional și al doilea rupt. De aceea simptomul pare atât de consecvent la produse VPN foarte diferite.

Lucrează de la adresă spre exterior: mai întâi numele complet, apoi numele de gazdă gol, și notează care dintre cele trei funcționează. Modelul îți spune ce strat să inspectezi înainte de a deschide un singur ecran de configurare. Să ghicești rute când FQDN-ul se rezolvă este efort irosit.

Citește resolverul pe care tunelul l-a instalat de fapt

Întreabă sistemul de operare care resolver tratează interogările pentru zona internă, nu care este anunțat de interfața clientului VPN. Un server care impune un resolver public fără zonă internă produce exact această defecțiune, iar aceasta este o eroare de configurare și nu o defecțiune de rutare.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Pe un client Windows unit la domeniu, politica de rutare a spațiului de nume decide ce interogări merg la ce resolver, iar setările DNS proprii ale adaptorului VPN apar în detaliile adaptorului. Citește politica efectivă, nu profilul, pentru că o politică din cache poate supraviețui conexiunii care a instalat-o. Dacă resolverul răspunde la numele complet și nu la numele scurt, problema s-a mutat deja în lista de sufixe.

Get-DnsClientNrptPolicy
ipconfig /all

Oprește-te dacă zona internă se rezolvă prin serverul corect. Resolverul nu este problema ta.

Sufixele explică numele scurte care eșuează

Un nume cu o singură etichetă este extins cu lista de sufixe a conexiunii înainte de trimiterea interogării. Dacă VPN-ul nu livrează sufixul intern, fileserver nu devine niciodată fileserver.corp.example, iar interogarea iese ca un nume pe care niciun resolver public nu îl cunoaște. Impunerea sufixului, sau tastarea numelui complet, testează ipoteza fără a schimba nimic pe server.

nslookup fileserver.corp.example
ping -a 192.168.50.20

În Linux serviciul de resolver leagă un server DNS de o legătură și de un set de domenii de rutare, așa că un server impus care nu este asociat legăturii tunelului se comportă ca și cum nu ar fi acolo. Verifică starea pe fiecare legătură, nu fișierul stub, care poate indica doar resolverul local. Aceeași scindare apare în cealaltă direcție: un domeniu de căutare prezent dar neaplicat interfeței tunelului produce eșecuri de nume scurt care par aleatorii.

Dacă adăugarea sufixului rezolvă problema, munca rămasă este să livrezi acel sufix prin profilul VPN în loc să ceri fiecărui utilizator să îl tasteze.

NetBIOS și WINS sunt un alt mecanism

SMB-ul vechi poate încă să caute un nume gol cu serviciul de nume NetBIOS, care răspunde prin difuzare sau printr-un server WINS. Difuzarea rămâne într-un singur domeniu de difuzare și se oprește la primul router, deci nu poate trece printr-un tunel; WINS funcționează pentru că clientul are o adresă unicast la care să se înregistreze și pe care să întrebe. De aceea un VPN care transportă doar IP poate încă susține nume vechi când WINS este configurat și accesibil.

nbtstat -n
nbtstat -R

Pentru SMB modern, bazează-te pe DNS și pe numele complet, și retrage calea veche. Dacă este cu adevărat veche, oferă WINS sau înlocuiește aplicația; calea de mijloc este o coadă de suport care nu se golește niciodată.

Parcursul se termină când poți spune ce strat a eșuat: resolver, sufix sau descoperire veche. Notează resolverul care a răspuns și forma de nume care a funcționat, pentru că următoarea persoană va porni de la același simptom.