Offentleg DNS som verkar tyder ikkje at Active Directory kan finnast

VPN koplar til, nettlesaren opnar eit offentleg nettstad, og laptoppen kan framleis ikkje logge på domenet. Den vanlege konklusjonen er at DNS er i orden fordi namn vert løyste opp. Det er det ikkje, og grunnen er at ein nettlesartest berre prøver eitt oppslag av ei kjede som ein domenetilknytt klient treng. Domeneoppdaging spør først etter tenestepostar, deretter etter adressene til kontrollerane som postane namngjev, og til slutt etter ei rute til portane som desse kontrollerane lyttar på. Eit offentleg svar oppfyller ingen av desse trinna.

Myten: namn vert løyste opp, så DNS er ferdig

At eit offentleg nettstad vert løyst opp, seier berre at ein eller annan resolver svara på éi A- eller AAAA-spørjing for eit namn i ei offentleg sone. Active Directory brukar same protokoll for eit anna spørsmål: kvar er tenestene til domenet, og kva kontroller skal denne klienten bruke. Spørsmålet vert uttrykt som SRV-postar under ei sone kalla opp etter domenet, og ein rekursiv offentleg resolver har ingen grunn til å halde dei.

Når posten manglar, returnerer resolveren eit negativt svar, som er eit gyldig DNS-svar og ikkje eit utfall. Klienten fell då tilbake på bufra kontrollerinformasjon om han har noko, og det er nettopp derfor ein stasjonær PC kan sjå fin ut i timar og feile etter ein omstart eller ei passordendring.

Kva ein domeneklient faktisk spør om, i rekkjefølgje

For eit domene som corp.example er den generiske lokatorspørjinga _ldap._tcp.dc._msdcs.corp.example. SRV-svara namngjev moglege kontrollerar og portane deira, og deretter treng klienten adressepostar for desse vertsnamna før han kan opne ei samband. Nettstadsmedviten oppdaging legg til spørjingar under underdomenet til nettstaden, og svara avgjer kva kontrollerar som vert føretrekte, ikkje kva ein som er obligatorisk.

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

Fylg kjedja i den rekkjefølgja, frå nettverket der problemet oppstår. Eit vertsnamn som vert løyst til ei utilgjengeleg adresse, er ein rutingsfeil, ikkje ein DNS-feil. Ein tilgjengeleg kontroller som manglar lokatorpostane sine, er ein DNS-feil, ikkje ein rutingsfeil. Dei to gjev liknande brukarklager og heilt ulike reparasjonar.

Kvifor ein offentleg resolver svarar og likevel øydelegg innlogginga

Viss adapteret gjev klienten ein offentleg resolver, verkar offentlege namn og det interne namnerommet ikkje. Å leggje til ein andre offentleg resolver hjelper ikkje, fordi ingen av dei held sona. Den vanlege lista «intern først, offentleg deretter» oppfører seg heller ikkje som ei regel per domene: eit negativt svar frå den første tenaren er eit legitimt svar, og klienten prøver ikkje den andre tenaren på nytt berre fordi svaret var tomt.

Båe dei interne resolverane, viss du køyrer to, må halde AD-namnerommet og vere tilgjengelege frå det noverande nettverket til klienten. Det er dette split-tunnel-design øydelegg: VPN-en kan bere subnettet til tunnelen medan den interne resolveren sit på eit prefiks som tunnelen ikkje rutar, slik at spørjinga går ut til ein resolver som ikkje kan svare på henne.

Windows brukar òg ein namneoppløysingspolitikk som kan sende bestemte namnerom til bestemte tenarar, og DNS-adressene adapteret viser er ikkje heile historia. Å endre adapterlista utan å endre denne politikken kan la den effektive konfigurasjonen vere urørt, og det er derfor ei retting som ser brukt ut ikkje har nokon verknad.

Hald DNS-en til tunnelen og rutene hans i samsvar

Ein VPN-profil som dyttar ein resolver, men ikkje prefikset som inneheld han, skaper ein resolver klienten ikkje når; ein som dyttar prefikset utan resolver, lèt klienten spørje den lokale. Handsame paret som eitt konfigurasjonselement og kontroller båe etter kvar profilendring, fordi ein omordna dytt eller ein ny split-tunnel-politikk kan skilje dei.

Kontroller òg kva klienten gjer med innstillinga som vert dytta. Nokre klientar brukar DNS-tenaren berre på tunnelgrensesnittet og lèt resolveren til den fysiske adapteren stå, så kven som vinn avheng av grensesnittmetrikken og namnet som vert spurt om. Viss det interne svaret berre kjem når den fysiske adapteren er slått av, er det mekanismen som må reparerast, ikkje domenepostane.

Godta med eit oppdagingskall og éin levande operasjon

Ein nyttig godtakingstest køyrer lokatorspørjinga og utfører deretter éin ekte autentisert operasjon, til dømes å opne ei katalogbasert deling eller be om ein billett. Gjer det før VPN-overgangen og igjen etter, på same maskin, utan omstart imellom. Bufra påloggingsdata og allereie opne sesjonar vil gjerne få ein broten veg til å sjå sunn ut, så ei vellukka skrivebordsinnlogging er ikkje testen.

Microsoft sine tilrådingar for DNS-klienten dreg same grensa mellom å løyse opp det interne namnerommet og å videresende offentlege spørjingar oppover, og det er ordninga som må haldast når ein VPN vert innført.

Viss feilen berre er treg og ikkje mislukka, hald forseinkinga skild frå diagnosen. Eit tidsavbrot under oppdaginga kan kome frå ein utilgjengeleg kontroller, ein blokkert port eller ein resolver som svarar seint, og ingen av dei vert prova av ventinga åleine. Tak opp den faktiske spørjinga, svaret og tilkoplingsforsøket før du endrar ei resolverinnstilling.