Korte interne navn feiler på VPN: suffikset du aldri ser
Et kort navn virker bare fordi et søkesuffiks fullfører det. Sammenlign det fulle og det korte navnet for å skille et suffiksgap fra en resolverfeil.
Det korte navnet virket på kontoret og feiler på VPN, mens det fulle navnet slås opp uten problemer. Ingenting er ødelagt. Et bart navn som intranet er ikke et fullstendig navn; klienten legger til et suffiks fra søkelisten sin og spør etter resultatet. Hvis VPN-profilen ikke leverer det suffikset, slutter den kjente korte formen å eksistere.
Det er hele myten. DNS gikk ikke i stykker, søkepolicyen ble endret.
Et bart navn er ikke et navn
Når du skriver en enkelt etikett, må resolveren bestemme hva den skal spørre om. Den prøver navnet som oppgitt, og legger deretter til oppføringer fra søkelisten én om gangen til noe svarer. På Linux styrer resolv.conf den rekkefølgen med innstillingene search og ndots. På Windows gjør suffikslisten og navneoppløsningspolicyen det samme. Fjern suffikset, og resolveren har ingenting å legge til.
Et fungerende kort navn er derfor bevis på en policy, ikke bevis på en sunn DNS-server.
Hva suffikslisten og resolveradressen hver for seg gjør
Disse to blandes stadig sammen. Resolveradressen sier hvem man skal spørre; suffikslisten sier hvilket navn man skal spørre om. En VPN kan gi deg en privat resolver uten suffiks, eller et suffiks med feil resolver. Bare én av disse feilene ser ut som et DNS-avbrudd.
Sjekk dem hver for seg, fordi reparasjon av den feil ene brenner et støttevindu.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Tre symptomer, tre forskjellige eiere.
Test det fulle navnet først
Spør etter administratorens dokumenterte fullt kvalifiserte navn, ikke en gjetning. Et fungerende FQDN beviser at resolveren er tilgjengelig og at oppføringen finnes, noe som fjerner halvparten av de mulige årsakene med én forespørsel. Bruk et verktøy som viser hvilken server som svarte, slik at du ikke leser et bufret resultat.
Hold testen privat. Å sende interne varianter til en offentlig resolver avslører navn og tester en policy ingen hadde til hensikt.
Hvor rettelsen hører hjemme
Rett den eierprofilen eller administrasjonssystemet som genererer den. En manuell endring i den lokale resolverkonfigurasjonen forsvinner vanligvis ved tilkobling på nytt, eller gjelder for alle nettverk maskinen kobler til, noe som er verre.
På Windows undersøker du den effektive policyen i stedet for avkrysningsboksen du husker. Get-DnsClientNrptPolicy viser navneoppløsningsreglene som faktisk gjelder.
På macOS skriver scutil --dns ut resolverkonfigurasjonen per avgrenset grensesnitt, inkludert søkedomenene VPN-en sendte.
På Linux leser du search-linjen i /etc/resolv.conf, men sjekk om en VPN-klient har skrevet den om. Hvis filen administreres, rediger sannhetskilden i stedet for den gjengitte filen. En utdatert search-linje fra et tidligere nettverk er en vanlig årsak.
Hva du bør oppbevare sammen med profilen
Oppbevar det rettede fulle navnet, suffikslisten og resolveradressen ved siden av klientprofilen. Den neste personen som melder at intranet-siden er nede, kan sammenligne tre kjente verdier i stedet for å begynne på en tom side.
Og hvis bare den korte formen feiler, si det i saken. Den setningen sparer resolverteamet en ettermiddag.