Korte interne navne fejler på VPN: det suffiks, du aldrig ser
Et kort navn virker kun, fordi et søgesuffiks fuldender det. Sammenlign det fulde og det korte navn for at skelne et suffiksgab fra en resolverfejl.
Det korte navn virkede på kontoret og fejler på VPN, mens det fulde navn slås op uden problemer. Intet er i stykker. Et bart navn som intranet er ikke et fuldstændigt navn; klienten tilføjer et suffiks fra sin søgeliste og spørger efter resultatet. Hvis VPN-profilen ikke leverer det suffiks, holder den velkendte korte form op med at eksistere.
Det er hele myten. DNS gik ikke i stykker, søgepolitikken ændrede sig.
Et bart navn er ikke et navn
Når du skriver en enkelt etiket, skal resolveren beslutte, hvad den skal spørge om. Den prøver navnet som angivet og tilføjer derefter poster fra søgelisten én ad gangen, indtil noget svarer. På Linux styrer resolv.conf den rækkefølge med indstillingerne search og ndots. På Windows gør suffikslisten og navneopløsningspolitikken det samme. Fjern suffikset, og resolveren har intet at tilføje.
Et fungerende kort navn er derfor bevis på en politik, ikke bevis på en sund DNS-server.
Hvad suffikslisten og resolveradressen hver især gør
Disse to blandes konstant sammen. Resolveradressen siger, hvem man skal spørge; suffikslisten siger, hvilket navn man skal spørge om. En VPN kan give dig en privat resolver uden suffiks eller et suffiks med den forkerte resolver. Kun én af disse fejl ligner et DNS-nedbrud.
Tjek dem hver for sig, fordi reparation af den forkerte brænder et supportvindue.
| 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 forskellige ejere.
Test det fulde navn først
Spørg efter administratorens dokumenterede fuldt kvalificerede navn, ikke et gæt. Et fungerende FQDN beviser, at resolveren kan nås, og at posten findes, hvilket fjerner halvdelen af de mulige årsager med én forespørgsel. Brug et værktøj, der viser, hvilken server der svarede, så du ikke læser et cachelagret resultat.
Hold testen privat. At sende interne varianter til en offentlig resolver afslører navne og tester en politik, som ingen havde til hensigt.
Hvor rettelsen hører hjemme
Ret den ejende profil eller det styringssystem, der genererer den. En manuel ændring af den lokale resolverkonfiguration forsvinder normalt ved genopkobling, eller gælder for alle netværk, maskinen tilslutter sig, hvilket er værre.
På Windows skal du undersøge den effektive politik i stedet for det afkrydsningsfelt, du husker. Get-DnsClientNrptPolicy viser de navneopløsningsregler, der faktisk er i kraft.
På macOS udskriver scutil --dns resolverkonfigurationen for hvert scoped interface, inklusive de søgedomæner, VPN'en har skubbet ud.
På Linux skal du læse search-linjen i /etc/resolv.conf, men kontrollere, om en VPN-klient har genskrevet den. Hvis filen er styret, skal du redigere sandhedskilden i stedet for den renderede fil. En forældet search-linje tilbage fra et tidligere netværk er en almindelig årsag.
Hvad du skal gemme sammen med profilen
Gem det rettede fulde navn, suffikslisten og resolveradressen ved siden af klientprofilen. Den næste person, der rapporterer, at intranet-siden er nede, kan sammenligne tre kendte værdier i stedet for at starte fra en tom side.
Og hvis kun den korte form fejler, så sig det i sagen. Den sætning sparer resolverteamet en eftermiddag.