Darbojošs publiskais DNS nenozīmē, ka Active Directory ir atrodama

VPN pieslēdzas, pārlūks atver publisku vietni, un klēpjdators joprojām nevar pieteikties domēnā. Ierastais secinājums ir, ka DNS ir kārtībā, jo vārdi tiek atrisināti. Tas nav kārtībā, un iemesls ir tāds, ka pārlūka tests pārbauda tikai vienu vaicājumu no ķēdes, kas nepieciešama domēnam piesaistītam klientam. Domēna atklāšana vispirms prasa pakalpojumu ierakstus, pēc tam to kontrolieru adreses, kurus nosauc šie ieraksti, un visbeidzot maršrutu uz portiem, kuros šie kontrolieri klausās. Publiska atbilde neapmierina nevienu no šiem soļiem.

Mīts: vārdi tiek atrisināti, tātad DNS ir pabeigts

Tas, ka publiska vietne tiek atrisināta, tikai pasaka, ka kāds atrisinātājs atbildēja uz vienu A vai AAAA vaicājumu par vārdu publiskā zonā. Active Directory izmanto to pašu protokolu citam jautājumam: kur ir domēna pakalpojumi un kuru kontrolieri šim klientam vajadzētu izmantot. Jautājums tiek izteikts kā SRV ieraksti zonā, kas nosaukta domēna vārdā, un rekursīvam publiskam atrisinātājam nav iemesla tos turēt.

Kad ieraksta trūkst, atrisinātājs atgriež negatīvu atbildi, kas ir derīga DNS atbilde, nevis pārtraukums. Tad klients atgriežas pie kešatmiņā saglabātās kontrolieru informācijas, ja tāda ir, un tieši tāpēc galddators var stundām izskatīties labi un pēc restartēšanas vai paroles maiņas neizdoties.

Ko domēna klients patiešām prasa, secībā

Domēnam, piemēram, corp.example, vispārējais lokatora vaicājums ir _ldap._tcp.dc._msdcs.corp.example. SRV atbildes nosauc kandidātus kontrolierus un to portus, un pēc tam klientam vajag adrešu ierakstus šiem resursdatora nosaukumiem, pirms tas var atvērt savienojumu. Vietnes apzinātā atklāšana pievieno vaicājumus zem vietnes apakšdomēna, un atbildes nosaka, kuri kontrolieri ir vēlami, nevis kurš ir obligāts.

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

Sekojiet ķēdei šajā secībā, no tīkla, kurā problēma rodas. Resursdatora nosaukums, kas tiek atrisināts uz nesasniedzamu adresi, ir maršrutēšanas kļūda, nevis DNS kļūda. Sasniedzams kontrolieris, kuram trūkst lokatora ierakstu, ir DNS kļūda, nevis maršrutēšanas kļūda. Abi rada līdzīgas lietotāju sūdzības un pilnīgi atšķirīgus labojumus.

Kāpēc publisks atrisinātājs atbild un pieteikšanās tomēr lūzt

Ja adapteris klientam dod publisku atrisinātāju, publiskie vārdi strādā, bet iekšējā nosaukumu telpa ne. Otra publiska atrisinātāja pievienošana nepalīdz, jo neviens no tiem netur zonu. Arī ierastais saraksts “vispirms iekšējais, pēc tam publiskais” neuzvedas kā noteikums katram domēnam: pirmā servera negatīva atbilde ir likumīga atbilde, un klients nemēģina otro serveri vēlreiz tikai tāpēc, ka atbilde bija tukša.

Abiem iekšējiem atrisinātājiem, ja jūs darbinat divus, ir jātur AD nosaukumu telpa un jābūt sasniedzamiem no klienta pašreizējā tīkla. Tieši to lauž sadalītā tuneļa risinājumi: VPN var pārvadāt tuneļa apakštīklu, kamēr iekšējais atrisinātājs atrodas prefiksā, kuru tunelis nemaršrutē, tāpēc vaicājums aiziet pie atrisinātāja, kas uz to nevar atbildēt.

Windows arī piemēro nosaukumu atrisināšanas politiku, kas var novirzīt konkrētas nosaukumu telpas uz konkrētiem serveriem, un adaptera rādītās DNS adreses nav viss stāsts. Ja maina adaptera sarakstu, nemainot šo politiku, efektīvā konfigurācija var palikt neskarta, un tāpēc labojumam, kas izskatās piemērots, nav nekādas ietekmes.

Turiet tuneļa DNS un tā maršrutus saskaņā

VPN profils, kas aizstūma atrisinātāju, bet ne to saturošo prefiksu, rada atrisinātāju, kuru klients nevar sasniegt; profils, kas aizstūma prefiksu bez atrisinātāja, atstāj klientu vaicāt vietējo. Uztveriet pāri kā vienu konfigurācijas vienumu un pārbaudiet abus pēc katras profila izmaiņas, jo pārkārtota aizstūmēšana vai jauna sadalītā tuneļa politika var tos šķirt.

Pārbaudiet arī, ko klients dara ar aizstūmēto iestatījumu. Daži klienti DNS serveri piemēro tikai tuneļa saskarnej un atstāj fiziskā adaptera atrisinātāju savā vietā, tāpēc tas, kurš uzvar, ir atkarīgs no saskarnes metrikas un vaicātā nosaukuma. Ja iekšējā atbilde nāk tikai tad, kad fiziskais adapters ir atspējots, tas ir labojamais mehānisms, nevis domēna ieraksti.

Pieņemiet ar atklāšanas izsaukumu un vienu dzīvu darbību

Noderīgs pieņemšanas tests izpilda lokatora vaicājumu un pēc tam veic vienu īstu autentificētu darbību, piemēram, atver katalogā balstītu koplietojumu vai pieprasa biļeti. Dariet to pirms VPN pārejas un vēlreiz pēc tās, tajā pašā mašīnā, bez restartēšanas starpā. Kešatmiņā saglabātie akreditācijas dati un jau atvērtās sesijas labprāt liks salauztam ceļam izskatīties veselam, tāpēc veiksmīga galddatora pieteikšanās nav tests.

Microsoft DNS klienta ieteikumi novelk to pašu robežu starp iekšējās nosaukumu telpas atrisināšanu un publisko vaicājumu pārsūtīšanu augšup, un tas ir izkārtojums, kas jāsaglabā, ieviešot VPN.

Ja kļūme ir tikai lēna, nevis neizdevusies, turiet aizturi atsevišķi no diagnozes. Taimauts atklāšanas laikā var nākt no nesasniedzama kontroliera, bloķēta porta vai atrisinātāja, kas atbild vēlu, un neviens no tiem nav pierādīts tikai ar gaidīšanu. Fiksējiet faktisko vaicājumu, tā atbildi un savienojuma mēģinājumu, pirms maināt atrisinātāja iestatījumu.