Openbare DNS werk, maar Active Directory is steeds nie vindbaar nie

Die VPN koppel, die blaaier open ’n openbare webwerf, en die skootrekenaar kan steeds nie by die domein aanmeld nie. Die gewone gevolgtrekking is dat DNS reg is omdat name opgelos word. Dit is nie reg nie, en die rede is dat ’n blaaiertoets net een opsoek uit ’n ketting toets wat ’n domeingekoppelde kliënt nodig het. Domeinontdekking vra eers diensrekords, dan die adresse van die kontroleerders wat daardie rekords noem, en dan ’n roete na die poorte waarop daardie kontroleerders luister. ’n Openbare antwoord bevredig nie een van daardie stappe nie.

Die mite: name los op, dus is DNS klaar

As ’n openbare webwerf oplos, sê dit net dat een of ander oplosser een A- of AAAA-navraag vir ’n naam in ’n openbare sone beantwoord het. Active Directory gebruik dieselfde protokol vir ’n ander vraag: waar is die domein se dienste, en watter kontroleerder moet hierdie kliënt gebruik. Die vraag word uitgedruk as SRV-rekords onder ’n sone wat na die domein vernoem is, en ’n rekursiewe openbare oplosser het geen rede om hulle te hou nie.

Wanneer die rekord ontbreek, gee die oplosser ’n negatiewe antwoord, wat ’n geldige DNS-antwoord is eerder as ’n onderbreking. Die kliënt val dan terug op gekaste kontroleerderinligting as hy dit het, en dit is presies waarom ’n rekenaar vir ure goed kan lyk en ná ’n herlaai of ’n wagwoordverandering kan faal.

Wat ’n domeinkliënt werklik vra, in volgorde

Vir ’n domein soos corp.example is die generiese lokatornavraag _ldap._tcp.dc._msdcs.corp.example. Die SRV-antwoorde noem kandidaatkontroleerders en hulle poorte, en die kliënt het dan adresrekords vir daardie gasheername nodig voordat hy ’n verbinding kan oopmaak. Werfbewuste ontdekking voeg navrae onder die werf-subdomein by, en die antwoorde bepaal watter kontroleerders verkies word eerder as watter een verpligtend is.

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

Volg die ketting in daardie volgorde, vanaf die netwerk waar die probleem gebeur. ’n Gasheernaam wat na ’n onbereikbare adres oplos, is ’n roetefout, nie ’n DNS-fout nie. ’n Bereikbare kontroleerder wie se lokatorrekords ontbreek, is ’n DNS-fout, nie ’n roetefout nie. Die twee lewer soortgelyke gebruikersklagtes en heeltemal verskillende herstellings.

Waarom ’n openbare oplosser antwoord en aanmelding steeds breek

As die adapter ’n openbare oplosser aan die kliënt gee, werk openbare name en werk die interne naamruimte nie. Om ’n tweede openbare oplosser by te voeg, help nie, want nie een van hulle hou die sone nie. Die algemene lys “intern eerste, openbaar tweede” gedra hom ook nie soos ’n reël per domein nie: ’n negatiewe antwoord van die eerste bediener is ’n geldige antwoord, en die kliënt probeer nie die tweede bediener weer net omdat die antwoord leeg was nie.

Albei interne oplossers, as jy twee het, moet die AD-naamruimte hou en bereikbaar wees vanaf die kliënt se huidige netwerk. Dit is die deel wat split-tunnel-ontwerpe breek: die VPN kan die tonnelsubnet dra terwyl die interne oplosser op ’n voorvoegsel sit wat die tonnel nie routeer nie, so die navraag gaan uit na ’n oplosser wat dit nie kan beantwoord nie.

Windows pas ook ’n naamoplossingsbeleid toe wat spesifieke naamruimtes na spesifieke bedieners kan stuur, en die DNS-adresse wat die adapter wys, is nie die hele storie nie. Om die adapterlys te verander sonder om daardie beleid te verander, kan die effektiewe konfigurasie onaangeraak laat, en dit is waarom ’n regstelling wat toegepas lyk, geen effek het nie.

Hou die tonnel se DNS en sy roetes in ooreenstemming

’n VPN-profiel wat ’n oplosser stoot maar nie die voorvoegsel wat dit bevat nie, skep ’n oplosser wat die kliënt nie kan bereik nie; een wat die voorvoegsel stoot maar geen oplosser nie, laat die kliënt die plaaslike een vra. Behandel die paar as een konfigurasie-item en kontroleer albei ná elke profielverandering, want ’n herrangskikte stoot of ’n nuwe split-tunnel-beleid kan hulle skei.

Kontroleer ook wat die kliënt met die gestuurde instelling doen. Sommige kliënte pas die DNS-bediener net op die tonnelkoppelvlak toe en laat die fisiese adapter se oplosser in plek, so watter een wen hang af van die koppelvlakmetriek en die naam wat gevra word. As die interne antwoord net opdaag wanneer die fisiese adapter gedeaktiveer is, is dit die meganisme om reg te maak, nie die domeinrekords nie.

Aanvaar met ’n ontdekkingsoproep en een lewendige bewerking

’n Nuttige aanvaardingstoets voer die lokatornavraag uit en doen dan een werklike geauthentiseerde bewerking, soos om ’n gids-gesteunde deel te open of ’n kaartjie aan te vra. Doen dit voor die VPN-oorgang en weer daarna, op dieselfde masjien, sonder ’n herlaai tussenin. Gekaste geloofsbriewe en reeds oop sessies sal ’n gebreekte pad met graagte gesond laat lyk, so ’n suksesvolle lessenaar-aanmelding is nie die toets nie.

Microsoft se aanbevelings vir die DNS-kliënt trek dieselfde lyn tussen die oplos van die interne naamruimte en die aanstuur van openbare navrae stroomop, en dit is die reëling om te bewaar wanneer ’n VPN ingebring word.

As die faling net stadig is eerder as misluk, hou die vertraging apart van die diagnose. ’n Tydverstreke tydperk tydens ontdekking kan van ’n onbereikbare kontroleerder, ’n geblokkeerde poort of ’n oplosser kom wat laat antwoord, en nie een daarvan word deur die wag alleen bewys nie. Vang die werklike navraag, sy antwoord en die verbindingspoging vas voordat jy ’n oplosserinstelling verander.