VPN-værtsnavne fejler, IP-adresser virker: hvor du skal kigge
IP-adgang virker, mens navne fejler, hvilket peger på suffikser og udskubbede resolvere, ikke på ruter. Gå gennem adressen, FQDN’en, det korte navn og den gamle vej.
Du kan åbne delingen via adressen, og den samme deling via navnet fejler, hvilket betyder, at tunnelen bærer pakker, og navnelaget ikke gør. Den ene observation sparer en omvej gennem ændringer af firewall og ruter. Navne har brug for et suffiks, en resolver og en vej til forespørgslen, og en VPN-klient kan installere en rute uden at installere nogen af dem. Gå gennem de fire kontroller nedenfor i rækkefølge, og stop ved den første, der knækker.
Et navn stiller et spørgsmål, en adresse ikke stiller
En adresse er en destination, som stakken kan bruge med det samme. Et kort navn er et spørgsmål, der skal udvides med et suffiks, sendes til en resolver og besvares af noget, der kender zonen. En tunnel, der installerer ruter men ingen resolver, efterlader det første virkende og det andet brudt. Derfor ser symptomet så ensartet ud på tværs af meget forskellige VPN-produkter.
Arbejd udad fra adressen: først det fulde navn, derefter det nøgne værtsnavn, og noter hvilket af de tre der virker. Mønsteret fortæller dig, hvilket lag du skal undersøge, før du åbner en enkelt konfigurationsskærm. At gætte på ruter, når FQDN’en opløses, er spildt arbejde.
Læs den resolver, som tunnelen faktisk installerede
Spørg styresystemet hvilken resolver der håndterer forespørgsler for den interne zone, ikke hvilken VPN-klientens grænseflade annoncerer. En server, der skubber en offentlig resolver uden en intern zone, frembringer præcis denne fejl, og det er en konfigurationsfejl snarere end en rutningsfejl.
resolvectl status
nslookup fileserver.corp.example
nslookup fileserver
På en domænetilsluttet Windows-klient afgør navnerummets rutningspolitik, hvilke forespørgsler der går til hvilken resolver, og VPN-adapterens egne DNS-indstillinger vises i adapterdetaljerne. Læs den effektive politik frem for profilen, fordi en cachelagret politik kan overleve den forbindelse, der installerede den. Hvis resolveren svarer på det fulde navn og ikke på det korte navn, er problemet allerede flyttet til suffikslisten.
Get-DnsClientNrptPolicy
ipconfig /all
Stop, hvis den interne zone opløses gennem den rigtige server. Resolveren er ikke dit problem.
Suffikser forklarer korte navne, der fejler
Et navn med et enkelt label udvides med forbindelsens suffiksliste, før forespørgslen sendes. Hvis VPN’en ikke leverer det interne suffiks, bliver fileserver aldrig fileserver.corp.example, og forespørgslen går ud som et navn, som ingen offentlig resolver kender. At skubbe suffikset eller skrive det fulde navn tester hypotesen uden at ændre noget på serveren.
nslookup fileserver.corp.example
ping -a 192.168.50.20
På Linux binder resolvertjenesten en DNS-server til et link og et sæt rutningsdomæner, så en udskubbet server, der ikke er knyttet til tunnelens link, opfører sig, som om den ikke var der. Kontroller status per link frem for stub-filen, som måske kun peger på den lokale resolver. Den samme opdeling ses i den anden retning: et søgedomæne, der findes, men ikke anvendes på tunnelgrænsefladen, frembringer korte navnefejl, der ser tilfældige ud.
Hvis tilføjelsen af suffikset løser det, er det resterende arbejde at levere det suffiks gennem VPN-profilen i stedet for at bede hver bruger om at skrive det.
NetBIOS og WINS er en anden mekanisme
Gammel SMB kan stadig slå et nøgent navn op med NetBIOS-navnetjenesten, som svarer via broadcast eller gennem en WINS-server. Broadcast bliver inden for ét broadcast-domæne og stopper ved den første router, så det kan ikke nå tværs over en tunnel; WINS virker, fordi klienten har en unicast-adresse at registrere sig med og at spørge. Derfor kan en VPN, der kun bærer IP, stadig understøtte gamle navne, når WINS er konfigureret og tilgængelig.
nbtstat -n
nbtstat -R
Til moderne SMB: stol på DNS og det fulde navn, og pensioner den gamle vej. Hvis den virkelig er gammel, så lever WINS eller udskift applikationen; mellemvejen er en supportkø, der aldrig tømmes.
Gennemgangen slutter, når du kan sige, hvilket lag der fejlede: resolver, suffiks eller gammel opdagelse. Noter den resolver, der svarede, og den navneform, der virkede, fordi den næste person starter med det samme symptom.