Ëffentlechen DNS funktionéiert, awer dat heescht net, datt Active Directory ze fanne ass

D’VPN verbënnt sech, de Browser mécht eng ëffentlech Säit op, an de Laptop kann sech nach ëmmer net am Domain umellen. Déi gewéinlech Conclusioun ass, datt den DNS an der Rei ass, well Nimm sech opléisen. Et ass net an der Rei, an de Grond ass, datt en Browser-Test just eng Ufro aus enger Kette test, déi en Domain-Client brauch. D’Domain-Entdeckung freet als éischt no Service-Records, duerno no den Adresse vun de Controllere vun dénen dës Records schwätzen, an duerno no enger Route zu de Ports op dénen dës Controllere lauschteren. Eng ëffentlech Äntwert erfëllt kee vun dëse Schrëtt.

De Mythos: Nimm léisen sech op, also ass den DNS fäerdeg

Datt eng ëffentlech Säit sech opléist, seet just, datt irgendeen Opléiser eng A- oder AAAA-Ufro fir en Numm an enger ëffentlecher Zone beäntwert huet. Den Active Directory benotzt de selwechte Protokoll fir eng aner Fro: wou sinn d’Servicer vum Domain, a wéi en Controller soll dëse Client benotzen. D’Fro gëtt als SRV-Records ënner enger Zone ausgedréckt, déi nom Domain genannt ass, an en rekursiven ëffentlechen Opléiser huet kee Grond, déi ze halen.

Wann de Record feelt, gëtt den Opléiser eng negativ Äntwert zeréck, wat eng gëlteg DNS-Äntwert ass an net en Ausfall. Den Client fällt dann op gespäichert Controller-Informatiounen zeréck, wann en der huet, an dat ass genee de Grond, firwat en Desktop Stonnen laang gutt ausgesi kann an no engem Neistart oder enger Passwuert-Ännerung feelt.

Wat en Domain-Client tatsächlech freet, an der Rei

Fir en Domain wéi corp.example ass déi allgemeng Lokator-Ufro _ldap._tcp.dc._msdcs.corp.example. D’SRV-Äntwerten nennen Kandidate fir Controllere mat hire Ports, an duerno brauch den Client Adressrecords fir dës Hostnimm, ier en eng Verbindung kann opmaachen. D’Entdeckung, déi de Site berücksichtegt, füügt Ufroe ënner dem Site-Subdomain derbäi, an d’Äntwerten entscheeden, wéi eng Controllere virgezunn ginn an net wéi en obligatoresch ass.

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

Verfollegt d’Kette an dëser Rei, aus dem Netz, wou de Problem geschitt. En Hostnumm, deen sech op eng onereechbar Adress opléist, ass e Routing-Fehler, keen DNS-Fehler. En erreechbare Controller, deem seng Lokatorrecords feelen, ass en DNS-Fehler, kee Routing-Fehler. Béid produzéiere ähnlech Benotzerbeschwären an ganz ënnerschiddlech Reparaturen.

Firwat e ëffentlechen Opléiser äntwert an d’Umeldung trotzdeem brécht

Wann den Adapter dem Client en ëffentlechen Opléiser gëtt, funktionéieren ëffentlech Nimm an den internen Nummraum net. En zweeten ëffentlechen Opléiser hëlleft net, well keen vun de béiden d’Zone huet. Och déi gewéinlech Lëscht „intern als éischt, ëffentlech duerno“ behëlft sech net wéi eng Regel pro Domain: eng negativ Äntwert vum éischte Server ass eng legitim Äntwert, an de Client probéiert den zweeten Server net nach eng Kéier just well d’Äntwert eidel war.

Béid intern Opléiser, wann Dir zwee bedreift, mussen den AD-Nummraum halen an aus dem aktuellen Netz vum Client erreechbar sinn. Genau dat brécht Split-Tunnel-Designs: d’VPN kann den Tunnel-Subnetz droen, während den internen Opléiser op engem Prefix sëtzt, deen den Tunnel net routet, sou datt d’Ufro bei en Opléiser geet, deen se net beäntwere kann.

Windows applizéiert och eng Numm-Opléisungspolitik, déi bestëmmt Nummraim op bestëmmt Serveren ëmleede kann, an d’DNS-Adressen, déi den Adapter weist, sinn net déi ganz Geschicht. D’Adapterlëscht z’änneren ouni déi Politik z’änneren kann déi effektiv Konfiguratioun onberéiert loossen, an dofir huet eng Reparatur, déi ugewannt ausgesäit, keen Effekt.

Halt den DNS vum Tunnel an seng Route matenee konform

En VPN-Profil, deen en Opléiser dréckt awer net de Prefix, deen en enthält, schaaft en Opléiser, deen de Client net erreeche kann; een, deen de Prefix dréckt ouni Opléiser, léisst de Client de lokale froen. Betraacht d’Puer als ee Konfiguratiounselement a kontrolléiert béid no all Profilännerung, well en ëmgeuerdnet Push oder eng nei Split-Tunnel-Politik se kann trennen.

Kontrolléiert och, wat de Client mat der gedréckter Astellung mécht. E puer Clienten applizéieren den DNS-Server just op der Tunnel-Schnittstell an loossen den Opléiser vum physeschen Adapter stoen, sou datt de Gewënner vun der Schnittstellmetrik an dem gefrote Numm ofhänkt. Wann déi intern Äntwert just kënnt, wann de physeschen Adapter ausgeschalt ass, ass dat de Mechanismus deen ze reparéieren ass, net d’Domainrecords.

Akzeptéiert mat engem Entdeckungsopruff an enger lieweger Operatioun

En nëtzlechen Akzeptanztest féiert d’Lokator-Ufro aus an duerno eng richteg authentifizéiert Operatioun, wéi eng Verdueblung op Basis vum Verzeechnis opzemaachen oder en Ticket ze froen. Maacht dat virum VPN-Iwwergang an nach eng Kéier duerno, op der selwechter Maschinn, ouni Neistart tëschent. Gespäichert Umeldungsinformatiounen a schonn opgemaachte Sessioune loossen eng futti Streck gär gesond ausgesinn, dofir ass eng erfollegräich Desktop-Umeldung net den Test.

D’Empfehlunge vum Microsoft fir den DNS-Client zéien déiselwecht Grenz tëschent dem Opléise vum internen Nummraum an dem Weidere vun ëffentlechen Ufroen no uewen, an dat ass d’Uerdnung, déi beim Aféiere vun enger VPN erhalen muss ginn.

Wann de Fehler just lues an net feelgeschlo ass, halt d’Verzögerung getrennt vun der Diagnos. En Timeout während der Entdeckung kann vun engem onereechbaren Controller, engem blockéierte Port oder engem Opléiser kommen, dee sech verspéit, an keen dovun ass just duerch d’Waarde bewisen. Halt d’tatsächlech Ufro, hir Äntwert an de Verbindungsversuch fest, ier Dir eng Opléiser-Astellung ännert.