Offentlig DNS som virker betyr ikke at Active Directory kan finnes

VPN kobler til, nettleseren åpner et offentlig nettsted, og laptopen kan fortsatt ikke logge på domenet. Den vanlige konklusjonen er at DNS er i orden fordi navn løses opp. Det er det ikke, og grunnen er at en nettlesertest bare prøver ett oppslag av en kjede som en domenetilknyttet klient trenger. Domeneoppdaging spør først etter tjenesteposter, deretter etter adressene til kontrollerne som postene navngir, og til slutt etter en rute til portene som disse kontrollerne lytter på. Et offentlig svar oppfyller ingen av disse trinnene.

Myten: navn løses opp, så DNS er ferdig

At et offentlig nettsted løses opp, sier bare at en eller annen resolver svarte på én A- eller AAAA-spørring for et navn i en offentlig sone. Active Directory bruker samme protokoll for et annet spørsmål: hvor er domenets tjenester, og hvilken kontroller skal denne klienten bruke. Spørsmålet uttrykkes som SRV-poster under en sone oppkalt etter domenet, og en rekursiv offentlig resolver har ingen grunn til å holde dem.

Når posten mangler, returnerer resolveren et negativt svar, som er et gyldig DNS-svar og ikke et utfall. Klienten faller da tilbake på bufret kontrollerinformasjon hvis den har noe, og det er nettopp derfor en stasjonær PC kan se fin ut i timer og feile etter en omstart eller en passordendring.

Hva en domeneklient faktisk spør om, i rekkefølge

For et domene som corp.example er den generiske lokatorspørringen _ldap._tcp.dc._msdcs.corp.example. SRV-svarene navngir mulige kontrollere og portene deres, og deretter trenger klienten adresseposter for disse vertsnavnene før den kan åpne en forbindelse. Nettstedsbevisst oppdaging legger til spørringer under nettstedets underdomene, og svarene avgjør hvilke kontrollere som foretrekkes, ikke hvilken som er obligatorisk.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Følg kjeden i den rekkefølgen, fra nettverket der problemet oppstår. Et vertsnavn som løses til en utilgjengelig adresse, er en rutingsfeil, ikke en DNS-feil. En tilgjengelig kontroller som mangler lokatorpostene sine, er en DNS-feil, ikke en rutingsfeil. De to gir lignende brukerklager og helt forskjellige reparasjoner.

Hvorfor en offentlig resolver svarer og likevel ødelegger innloggingen

Hvis adapteret gir klienten en offentlig resolver, virker offentlige navn og det interne navnerommet ikke. Å legge til en andre offentlig resolver hjelper ikke, fordi ingen av dem holder sonen. Den vanlige listen «intern først, offentlig deretter» oppfører seg heller ikke som en regel per domene: et negativt svar fra den første serveren er et legitimt svar, og klienten prøver ikke den andre serveren på nytt bare fordi svaret var tomt.

Begge de interne resolverne, hvis du kjører to, må holde AD-navnerommet og være tilgjengelige fra klientens nåværende nettverk. Det er dette split-tunnel-design ødelegger: VPN-en kan bære tunnelens subnett mens den interne resolveren sitter på et prefiks som tunnelen ikke ruter, slik at spørringen går ut til en resolver som ikke kan svare på den.

Windows bruker også en navneoppløsningspolicy som kan sende bestemte navnerom til bestemte servere, og DNS-adressene adapteret viser er ikke hele historien. Å endre adapterlisten uten å endre denne policyen kan la den effektive konfigurasjonen være urørt, og det er derfor en rettelse som ser anvendt ut ikke har noen virkning.

Hold tunnelens DNS og rutene dens i samsvar

En VPN-profil som dytter en resolver, men ikke prefikset som inneholder den, skaper en resolver klienten ikke når; en som dytter prefikset uten resolver, lar klienten spørre den lokale. Behandle paret som ett konfigurasjonselement og kontroller begge etter hver profilendring, fordi en omordnet dytting eller en ny split-tunnel-policy kan skille dem.

Kontroller også hva klienten gjør med innstillingen som dyttes. Noen klienter bruker DNS-serveren bare på tunnelgrensesnittet og lar den fysiske adapterens resolver bli stående, så hvilken som vinner avhenger av grensesnittmetrikken og navnet som spørres om. Hvis det interne svaret bare kommer når den fysiske adapteren er deaktivert, er det mekanismen som må repareres, ikke domenepostene.

Godta med et oppdagelseskall og én levende operasjon

En nyttig godtakelsestest kjører lokatorspørringen og utfører deretter én ekte autentisert operasjon, for eksempel å åpne en katalogbasert deling eller be om en billett. Gjør det før VPN-overgangen og igjen etter, på samme maskin, uten omstart imellom. Bufrede påloggingsdata og allerede åpne sesjoner vil gjerne få en brutt vei til å se sunn ut, så en vellykket skrivebordsinnlogging er ikke testen.

Microsofts anbefalinger for DNS-klienten trekker samme grense mellom å løse opp det interne navnerommet og å videresende offentlige spørringer oppover, og det er ordningen som må bevares når en VPN innføres.

Hvis feilen bare er treg og ikke mislykket, hold forsinkelsen atskilt fra diagnosen. En tidsavbrudd under oppdagingen kan komme fra en utilgjengelig kontroller, en blokkert port eller en resolver som svarer sent, og ingen av dem bevises av ventingen alene. Ta opp den faktiske spørringen, svaret og tilkoblingsforsøket før du endrer en resolverinnstilling.