Iepenbiere DNS wurket, mar dat betsjut net dat Active Directory te finen is

De VPN ferbynt, de browser iepenet in iepenbiere side, en de laptop kin him noch altyd net by it domein oanmelde. De gewoane konklúzje is dat DNS goed is om’t nammen oplost wurde. Dat is it net, en de reden is dat in browserproef mar ien opfraach út in keatling testet dy’t in oan it domein ferbûne klant nedich hat. Domeinûntdekking freget earst om tsjinstrecords, dan om de adressen fan ’e kontrolleurs dy’t dy records neame, en dan om in rûte nei de poarten dêr’t dy kontrolleurs nei harkje. In iepenbier antwurd foldocht oan gjin fan dy stappen.

De myte: nammen wurde oplost, dus DNS is klear

Dat in iepenbiere side oplost, seit allinnich dat in oplosser ien A- of AAAA-opfraach foar in namme yn in iepenbiere sône beantwurde hat. Active Directory brûkt itselde protokol foar in oare fraach: wêr binne de tsjinsten fan it domein, en hokker kontrolleur moat dizze klant brûke. De fraach wurdt útdrukt as SRV-records ûnder in sône neamd nei it domein, en in rekursive iepenbiere oplosser hat gjin reden om se te hâlden.

As it record ûntbrekt, jout de oplosser in negatyf antwurd, wat in jildich DNS-antwurd is en gjin útfal. De klant falt dan werom op yn it cache bewarre kontrolleurynformaasje as er dy hat, en dat is krekt wêrom’t in buroblêd oerenlang goed lykje kin en nei in werstart of in wachtwurdferoaring mislearret.

Wat in domeinklient eins freget, yn folchoarder

Foar in domein lykas corp.example is de algemiene lokaatoropfraach _ldap._tcp.dc._msdcs.corp.example. De SRV-antwurden neame kandidaat-kontrolleurs en harren poarten, en dêrnei hat de klant adresrecords foar dy hostnammen nedich ear’t er in ferbining iepenje kin. Sônebewuste ûntdekking foeget opfragen ta ûnder it subsône fan ’e side, en de antwurden bepale hokker kontrolleurs foarkar krije en net hokker ferplichte is.

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

Folgje de keatling yn dy folchoarder, fan it netwurk dêr’t it probleem bart. In hostnamme dy’t nei in ûnberikber adres oplost, is in rûtfout, gjin DNS-fout. In berikbere kontrolleur waans lokaatorrecords ûntbrekke, is in DNS-fout, gjin rûtfout. De twa jouwe ferlykbere klachten fan brûkers en folslein ferskillende reparaasjes.

Wêrom in iepenbiere oplosser antwurdet en de oanmelding dochs brekt

As de adapter de klant in iepenbiere oplosser jout, wurkje iepenbiere nammen en wurket de ynterne nammromte net. In twadde iepenbiere oplosser tafoegje helpt net, om’t gjin fan beide de sône hat. Ek de gewoane list ‘earst yntern, dan iepenbier’ gedraacht him net as in regel per domein: in negatyf antwurd fan ’e earste tsjinner is in legitime antwurd, en de klant probearret de twadde tsjinner net opnij allinnich om’t it antwurd leech wie.

Beide ynterne oplossers, as jo twa draaie, moatte de AD-nammromte hawwe en berikber wêze fan it hjoeddeiske netwurk fan ’e klant. Dat is it part dat ûntwerpen mei in splitstunnel brekke: de VPN kin it tunnel-subnet drage wylst de ynterne oplosser op in prefiks sit dat de tunnel net rûtet, sadat de opfraach útgaat nei in oplosser dy’t him net beantwurdzje kin.

Windows past ek in belied foar namme-oplossing ta dat bepaalde nammromten nei bepaalde tsjinners stjoere kin, en de DNS-adressen dy’t de adapter sjen lit binne net it hiele ferhaal. It feroarjen fan ’e adapterlist sûnder dat belied te feroarjen kin de effektive konfiguraasje ûnoantaast litte, en dêrom hat in reparaasje dy’t tapast liket gjin effekt.

Hâld de DNS fan ’e tunnel en syn rûtes yn oerienstimming

In VPN-profyl dat in oplosser stjoert mar net it prefiks dat him befettet, makket in oplosser dy’t de klant net berikke kin; ien dat it prefiks stjoert sûnder oplosser lit de klant de lokale freegje. Behannelje it pear as ien konfiguraasje-ûnderdiel en kontrolearje beide nei elke profylferoaring, om’t in oardere stjoering of in nij belied foar splitstunnel se skiede kin.

Kontrolearje ek wat de klant mei de stjoerde ynstelling docht. Guon klanten lizze de DNS-tsjinner allinnich op ’e tunnelinterface en litte de oplosser fan ’e fysike adapter stean, sadat wa’t wint ôfhinget fan ’e interfacemetrik en de namme dy’t frege wurdt. As it ynterne antwurd allinnich komt as de fysike adapter útskeakele is, is dat it meganisme om te reparearjen, net de domeinrecords.

Akseptearje mei in ûntdekkingsoprop en ien libbene operaasje

In brûkbere akseptaasjetest rint de lokaatoropfraach en docht dan ien echte autentisearre operaasje, lykas in troch de gids stipe dieling iepenje of in ticket freegje. Doch dat foar de VPN-oergong en wer dêrnei, op deselde masine, sûnder werstart tuskentroch. Yn it cache bewarre oanmeldgegevens en al iepene sesjes meitsje in brutsen paad mar wat graach sûn, dus in slagge oanmelding op it buroblêd is de test net.

De oanbefellings fan Microsoft foar de DNS-klant lûke deselde grins tusken it oplossen fan ’e ynterne nammromte en it trochstjoeren fan iepenbiere opfragen nei boppe, en dat is de regeling om te behâlden as in VPN yntrodusearre wurdt.

As it mislearjen allinnich stadich is en net mislearre, hâld de fertraging los fan ’e diagnoaze. In tiidferrin by ûntdekking kin komme fan in ûnberikbere kontrolleur, in blokkearre poarte of in oplosser dy’t let antwurdet, en gjin fan dy wurdt troch it wachtsjen allinnich bewiisd. Fêstlizze de wiere opfraach, syn antwurd en de ferbiningspoging ear’t jo in oplosser-ynstelling feroarje.