VPN-vertsnavn feiler, IP-adresser virker: hvor du bør se
IP-tilgang virker mens navn feiler, noe som peker på suffikser og påtvungne resolvere, ikke ruter. Gå gjennom adressen, FQDN-en, kortnavnet og den gamle veien.
Du kan åpne delingen via adressen og den samme delingen via navnet feiler, noe som betyr at tunnelen bærer pakker og navnelaget ikke. Den ene observasjonen sparer en omvei gjennom endringer i brannmur og ruter. Navn trenger et suffiks, en resolver og en vei for spørringen, og en VPN-klient kan installere en rute uten å installere noen av dem. Gå gjennom de fire kontrollene nedenfor i rekkefølge og stopp ved den første som knekker.
Et navn stiller et spørsmål en adresse ikke stiller
En adresse er en destinasjon som stakken kan bruke med en gang. Et kortnavn er et spørsmål som må utvides med et suffiks, sendes til en resolver og besvares av noe som kjenner sonen. En tunnel som installerer ruter men ingen resolver, lar det første virke og det andre være ødelagt. Derfor ser symptomet så konsistent ut på tvers av svært ulike VPN-produkter.
Arbeid utover fra adressen: først det fulle navnet, så det nakne vertsnavnet, og noter hvilken av de tre som virker. Mønsteret forteller deg hvilket lag du skal undersøke før du åpner en eneste konfigurasjonsskjerm. Å gjette på ruter når FQDN-en løses opp, er bortkastet arbeid.
Les resolveren tunnelen faktisk installerte
Spør operativsystemet hvilken resolver som håndterer spørringer for den interne sonen, ikke hvilken VPN-klientens grensesnitt annonserer. En server som skyver en offentlig resolver uten en intern sone, produserer nøyaktig denne feilen, og det er en konfigurasjonsfeil og ikke en rutingsfeil.
resolvectl status
nslookup fileserver.corp.example
nslookup fileserver
På en domenetilknyttet Windows-klient avgjør rutingspolicyen for navnerommet hvilke spørringer som går til hvilken resolver, og VPN-adapterens egne DNS-innstillinger vises i adapterdetaljene. Les den effektive policyen fremfor profilen, fordi en bufret policy kan overleve tilkoblingen som installerte den. Hvis resolveren svarer på det fulle navnet og ikke på kortnavnet, har problemet allerede flyttet seg til suffikslisten.
Get-DnsClientNrptPolicy
ipconfig /all
Stopp hvis den interne sonen løses opp gjennom riktig server. Resolveren er ikke problemet ditt.
Suffikser forklarer kortnavn som feiler
Et navn med én etikett utvides med tilkoblingens suffiksliste før spørringen sendes. Hvis VPN-en ikke leverer det interne suffikset, blir fileserver aldri fileserver.corp.example, og spørringen går ut som et navn ingen offentlig resolver kjenner. Å skyve suffikset, eller å skrive det fulle navnet, tester hypotesen uten å endre noe på serveren.
nslookup fileserver.corp.example
ping -a 192.168.50.20
På Linux binder resolvertjenesten en DNS-server til en lenke og et sett med rutingsdomener, så en påskjøvet server som ikke er knyttet til tunnelens lenke, oppfører seg som om den ikke var der. Kontroller status per lenke i stedet for stub-filen, som kanskje bare peker på den lokale resolveren. Den samme splittelsen vises i den andre retningen: et søkedomene som finnes men ikke brukes på tunnelgrensesnittet, gir kortnavnfeil som ser tilfeldige ut.
Hvis tilføyelsen av suffikset retter det, er det resterende arbeidet å levere det suffikset gjennom VPN-profilen i stedet for å be hver bruker skrive det.
NetBIOS og WINS er en annen mekanisme
Gammel SMB kan fortsatt slå opp et nakent navn med NetBIOS-navnetjenesten, som svarer over kringkasting eller gjennom en WINS-server. Kringkasting holder seg innenfor ett kringkastingsdomene og stopper ved den første ruteren, så den kan ikke nå tvers over en tunnel; WINS virker fordi klienten har en unicast-adresse å registrere seg på og spørre. Derfor kan en VPN som bare bærer IP fortsatt støtte gamle navn når WINS er konfigurert og tilgjengelig.
nbtstat -n
nbtstat -R
For moderne SMB, stol på DNS og det fulle navnet, og pensjoner den gamle veien. Hvis den virkelig er gammel, lever WINS eller bytt ut applikasjonen; midtveien er en støttekø som aldri tømmes.
Gjennomgangen slutter når du kan si hvilket lag som feilet: resolver, suffiks eller gammel oppdagelse. Noter resolveren som svarte og navneformen som virket, fordi den neste personen starter fra samme symptom.