Offentlig DNS virker, men det betyder ikke, at Active Directory kan findes

VPN forbinder, browseren åbner et offentligt websted, og laptop’en kan stadig ikke logge på domænet. Den sædvanlige konklusion er, at DNS er i orden, fordi navne opløses. Det er det ikke, og grunden er, at en browsertest kun prøver ét opslag ud af en kæde, som en domænetilsluttet klient har brug for. Domæneopdagelse spørger først efter serviceposter, derefter efter adresserne på de controllere, som posterne navngiver, og derefter efter en rute til de porte, som de controllere lytter på. Et offentligt svar opfylder ingen af disse trin.

Myten: navne opløses, så DNS er klaret

At et offentligt websted opløses, fortæller kun, at en eller anden resolver har svaret på ét A- eller AAAA-opslag for et navn i en offentlig zone. Active Directory bruger samme protokol til et andet spørgsmål: hvor er domænets tjenester, og hvilken controller skal denne klient bruge. Spørgsmålet udtrykkes som SRV-poster under en zone opkaldt efter domænet, og en rekursiv offentlig resolver har ingen grund til at have dem.

Når posten mangler, returnerer resolveren et negativt svar, som er et gyldigt DNS-svar og ikke et udfald. Klienten falder derefter tilbage på cachelagrede controlleroplysninger, hvis den har nogen, og det er netop derfor, en stationær computer kan se fin ud i timer og fejle efter en genstart eller en adgangskodeændring.

Hvad en domæneklient faktisk spørger om, i rækkefølge

For et domæne som corp.example er det generiske lokatoropslag _ldap._tcp.dc._msdcs.corp.example. SRV-svarene navngiver mulige controllere og deres porte, og derefter har klienten brug for adresseposter til de værtsnavne, før den kan åbne en forbindelse. Opdagelse, der tager hensyn til webstedet, tilføjer opslag under webstedets underdomæne, og svarene afgør, hvilke controllere der foretrækkes, ikke hvilken der er obligatorisk.

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

Følg kæden i den rækkefølge, fra det netværk hvor problemet opstår. Et værtsnavn, der opløses til en utilgængelig adresse, er en routingfejl, ikke en DNS-fejl. En tilgængelig controller, hvis lokatorposter mangler, er en DNS-fejl, ikke en routingfejl. De to giver lignende brugerklager og helt forskellige reparationer.

Hvorfor en offentlig resolver svarer og stadig ødelægger login

Hvis adapteren giver klienten en offentlig resolver, virker offentlige navne, og det interne navnerum gør ikke. At tilføje en anden offentlig resolver hjælper ikke, fordi ingen af dem har zonen. Den almindelige liste »intern først, offentlig derefter« opfører sig heller ikke som en regel per domæne: et negativt svar fra den første server er et legitimit svar, og klienten prøver ikke den anden server igen, blot fordi svaret var tomt.

Begge interne resolvere, hvis du kører to, skal have AD-navnerummet og være tilgængelige fra klientens aktuelle netværk. Det er den del, som split-tunnel-design ødelægger: VPN’en kan bære tunnelens undernet, mens den interne resolver sidder på et præfiks, som tunnelen ikke router, så forespørgslen går ud til en resolver, der ikke kan svare på den.

Windows anvender også en navneopløsningspolitik, der kan sende bestemte navnerum til bestemte servere, og de DNS-adresser, adapteren viser, er ikke hele historien. Ændring af adapterlisten uden at ændre denne politik kan lade den effektive konfiguration være urørt, og det er derfor en rettelse, der ser ud til at være anvendt, ikke har nogen virkning.

Hold tunnelens DNS og dens ruter i overensstemmelse

En VPN-profil, der sender en resolver, men ikke det præfiks, der indeholder den, skaber en resolver, som klienten ikke kan nå; en profil, der sender præfikset uden en resolver, efterlader klienten med at spørge den lokale. Behandl parret som ét konfigurationselement, og kontrollér begge efter hver profilændring, fordi et omarrangeret push eller en ny split-tunnel-politik kan skille dem.

Kontrollér også, hvad klienten gør med den pushede indstilling. Nogle klienter anvender kun DNS-serveren på tunnelgrænsefladen og lader den fysiske adapters resolver blive, så hvilken der vinder afhænger af grænseflademetrikken og det navn, der spørges til. Hvis det interne svar kun kommer, når den fysiske adapter er deaktiveret, er det mekanismen, der skal rettes, ikke domæneposterne.

Accepter med et opdagelseskald og én levende handling

En brugbar accepttest kører lokatoropslaget og udfører derefter én rigtig autentificeret handling, for eksempel at åbne en mappeunderstøttet deling eller anmode om en billet. Gør det før VPN-overgangen og igen efter, på samme maskine, uden genstart imellem. Cachelagrede legitimationsoplysninger og allerede åbne sessioner vil med glæde få en brudt vej til at se sund ud, så et vellykket skrivebordslogin er ikke testen.

Microsofts anbefalinger til DNS-klienten drager samme grænse mellem at opløse det interne navnerum og videresende offentlige forespørgsler opad, og det er den ordning, der skal bevares, når der indføres en VPN.

Hvis fejlen kun er langsom og ikke mislykket, så hold forsinkelsen adskilt fra diagnosen. En timeout under opdagelsen kan komme fra en utilgængelig controller, en blokeret port eller en resolver, der svarer sent, og ingen af dem bevises af ventetiden alene. Optag den faktiske forespørgsel, dens svar og forbindelsesforsøget, før du ændrer en resolverindstilling.