Javni DNS radi, ali to ne znači da se Active Directory može pronaći

VPN se poveže, preglednik otvori javnu stranicu, a laptop se ipak ne može prijaviti u domenu. Uobičajen zaključak je da je DNS ispravan jer se imena razrješavaju. Nije ispravan, a razlog je da test u pregledniku provjerava samo jedan upit iz lanca koji klijent pridružen domeni treba. Otkrivanje domene najprije traži zapise usluga, zatim adrese kontrolera koje ti zapisi imenuju, a zatim rutu do portova na kojima ti kontroleri slušaju. Javni odgovor ne zadovoljava nijedan od tih koraka.

Mit: imena se razrješavaju, pa je DNS završen

Javna stranica koja se razrješava govori samo to da je neki razrješivač odgovorio na jedan A ili AAAA upit za ime u javnoj zoni. Active Directory koristi isti protokol za drugo pitanje: gdje su usluge domene i koji kontroler treba koristiti ovaj klijent. Pitanje se izražava SRV zapisima u zoni nazvanoj po domeni, a rekurzivni javni razrješivač nema razloga držati ih.

Kada zapis nedostaje, razrješivač vraća negativan odgovor, što je valjan DNS odgovor, a ne prekid rada. Klijent se zatim vraća na keširane podatke o kontrolerima ako ih ima, i upravo zato stolno računalo može satima izgledati dobro, a pasti nakon ponovnog pokretanja ili promjene lozinke.

Šta klijent domene zapravo traži, po redu

Za domenu kao što je corp.example, opći upit lokatora je _ldap._tcp.dc._msdcs.corp.example. SRV odgovori imenuju kandidate za kontrolere i njihove portove, a klijent zatim treba zapise adresa za ta imena hostova prije nego što otvori vezu. Otkrivanje svjesno lokacije dodaje upite ispod poddomene lokacije, a odgovori određuju koji su kontroleri poželjni, a ne koji je obavezan.

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

Slijedite lanac tim redom, iz mreže u kojoj se problem javlja. Ime hosta koje se razrješava na nedostupnu adresu jest greška usmjeravanja, a ne DNS greška. Dostupan kontroler kojemu nedostaju zapisi lokatora jest DNS greška, a ne greška usmjeravanja. Obje daju slične pritužbe korisnika i posve različite popravke.

Zašto javni razrješivač odgovara, a prijava se ipak kvari

Ako adapter klijentu dodijeli javni razrješivač, javna imena rade, a unutrašnji prostor imena ne. Dodavanje drugog javnog razrješivača ne pomaže, jer nijedan ne drži zonu. Niti uobičajen popis „prvo unutrašnji, zatim javni“ ne ponaša se kao pravilo po domeni: negativan odgovor prvog poslužitelja valjan je odgovor, i klijent ne pokušava drugi poslužitelj samo zato što je odgovor bio prazan.

Oba unutrašnja razrješivača, ako ih imate dva, moraju držati AD prostor imena i biti dostupni iz klijentove trenutačne mreže. Upravo to kvare dizajni razdvojenog tunela: VPN može nositi podmrežu tunela dok unutrašnji razrješivač stoji na prefiksu koji tunel ne usmjerava, pa upit odlazi razrješivaču koji ga ne može odgovoriti.

Windows primjenjuje i pravilo razrješavanja imena koje može usmjeriti određene prostore imena na određene poslužitelje, a DNS adrese koje adapter prikazuje nisu cijela priča. Promjena popisa adaptera bez promjene tog pravila može ostaviti stvarnu konfiguraciju netaknutom, i zato popravak koji izgleda primijenjen nema učinka.

Držite DNS tunela i njegove rute usklađenima

VPN profil koji gura razrješivač, ali ne i prefiks koji ga sadrži, stvara razrješivač koji klijent ne može dosegnuti; onaj koji gura prefiks bez razrješivača ostavlja klijenta da pita lokalni. Tretirajte par kao jednu konfiguracijsku stavku i provjerite oboje nakon svake promjene profila, jer preuređeno guranje ili novo pravilo razdvojenog tunela može ih razdvojiti.

Provjerite i što klijent čini s gurnutom postavkom. Neki klijenti primjenjuju DNS poslužitelj samo na sučelje tunela i ostavljaju razrješivač fizičkog adaptera na mjestu, pa o tome koji pobjeđuje odlučuju metrika sučelja i ime koje se pita. Ako unutrašnji odgovor dolazi samo kad je fizički adapter onemogućen, to je mehanizam koji treba popraviti, a ne zapisi domene.

Prihvatite uz poziv otkrivanja i jednu živu radnju

Koristan prihvatni test pokreće upit lokatora i zatim izvodi jednu stvarnu autentificiranu radnju, poput otvaranja mrežnog resursa podržanog imenikom ili zahtjeva za kartu. Učinite to prije prijelaza na VPN i ponovno poslije, na istom računalu, bez ponovnog pokretanja između. Keširani podaci za prijavu i već otvorene sesije rado će pokvaren put prikazati zdravim, pa uspješna prijava na radnu površinu nije test.

Microsoftove preporuke za DNS klijenta povlače istu granicu između razrješavanja unutrašnjeg prostora imena i prosljeđivanja javnih upita prema gore, i to je raspored koji treba sačuvati kad se uvodi VPN.

Ako je kvar samo spor, a ne potpun, držite odgodu odvojeno od dijagnoze. Istek vremena tijekom otkrivanja može doći od nedostupnog kontrolera, blokiranog porta ili razrješivača koji odgovara kasno, i ništa od toga ne dokazuje samo čekanje. Zabilježite stvarni upit, njegov odgovor i pokušaj veze prije nego što promijenite postavku razrješivača.