Ang paggana ng pampublikong DNS ay hindi ibig sabihin na mahahanap ang Active Directory

Kumokonekta ang VPN, nagbubukas ang browser ng pampublikong site, at hindi pa rin makapag-sign in ang laptop sa domain. Ang karaniwang konklusyon ay maayos ang DNS dahil nalulutas ang mga pangalan. Hindi ito maayos, at ang dahilan ay ang pagsubok sa browser ay nagsasanay lamang ng isang paghahanap mula sa kadena na kailangan ng kliyenteng sumali sa domain. Hinihingi muna ng pagtuklas ng domain ang mga service record, pagkatapos ang mga address ng controller na pinapangalanan ng mga record na iyon, at pagkatapos ang ruta patungo sa mga port na pinakikinggan ng mga controller. Walang natutugunan ang pampublikong sagot sa alinman sa mga hakbang na iyon.

Ang mito: nalulutas ang mga pangalan, kaya tapos na ang DNS

Ang nalulutas na pampublikong site ay nagsasabi lamang na may resolver na sumagot sa isang A o AAAA query para sa pangalan sa pampublikong zone. Ginagamit ng Active Directory ang parehong protocol para sa ibang tanong: nasaan ang mga serbisyo ng domain, at aling controller ang dapat gamitin ng kliyenteng ito. Ang tanong ay ipinapahayag bilang mga SRV record sa ilalim ng zone na pinangalanan sa domain, at walang dahilan ang recursive na pampublikong resolver na itago ang mga iyon.

Kapag wala ang record, nagbabalik ang resolver ng negatibong sagot, na isang wastong sagot sa DNS at hindi pagkawala. Bumabalik ang kliyente sa naka-cache na impormasyon ng controller kung mayroon, at iyon mismo ang dahilan kung bakit ang desktop ay maaaring magmukhang maayos nang maraming oras at mabigo pagkatapos ng restart o pagbabago ng password.

Ano ang talagang hinihingi ng kliyente ng domain, sunod-sunod

Para sa domain na tulad ng corp.example, ang pangkalahatang locator query ay _ldap._tcp.dc._msdcs.corp.example. Pinapangalanan ng mga SRV answer ang mga kandidatong controller at ang kanilang mga port, at pagkatapos ay kailangan ng kliyente ang mga address record para sa mga hostname na iyon bago makapagbukas ng koneksyon. Ang pagtuklas na may kamalayan sa site ay nagdadagdag ng mga query sa ilalim ng subdomain ng site, at ang mga sagot ang nagtatakda kung aling mga controller ang ginusto, hindi kung alin ang sapilitan.

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

Sundin ang kadena sa ganoong ayos, mula sa network kung saan nangyayari ang problema. Ang hostname na nalulutas sa address na hindi maabot ay pagkabigo sa routing, hindi pagkabigo sa DNS. Ang maabot na controller na kulang sa locator record ay pagkabigo sa DNS, hindi pagkabigo sa routing. Pareho silang gumagawa ng magkatulad na reklamo ng user at ganap na magkaibang pag-aayos.

Bakit sumasagot ang pampublikong resolver at nasisira pa rin ang pag-sign in

Kung bibigyan ng adapter ang kliyente ng pampublikong resolver, gumagana ang mga pampublikong pangalan at hindi gumagana ang panloob na namespace. Hindi nakakatulong ang pagdaragdag ng pangalawang pampublikong resolver, dahil wala sa kanila ang may hawak ng zone. Ni ang karaniwang listahan na “panloob muna, pampubliko pagkatapos” ay hindi kumikilos na parang tuntunin sa bawat domain: ang negatibong sagot mula sa unang server ay lehitimong sagot, at hindi sinusubukan muli ng kliyente ang pangalawang server dahil lang sa walang laman ang sagot.

Ang dalawang panloob na resolver, kung dalawa ang pinapatakbo mo, ay dapat may hawak ng AD namespace at maabot mula sa kasalukuyang network ng kliyente. Ito ang parteng sinisira ng mga disenyong split tunnel: maaaring dalhin ng VPN ang subnet ng tunnel habang ang panloob na resolver ay nasa prefix na hindi niruruta ng tunnel, kaya lumalabas ang query sa resolver na hindi ito masasagot.

Naglalapat din ang Windows ng patakaran sa paglutas ng pangalan na maaaring magturo ng partikular na namespace sa partikular na server, at ang mga DNS address na ipinapakita ng adapter ay hindi ang buong kuwento. Ang pagbabago ng listahan ng adapter nang hindi binabago ang patakarang iyon ay maaaring mag-iwan sa aktwal na configuration na hindi nagalaw, at iyon ang dahilan kung bakit walang epekto ang isang pag-aayos na mukhang naipatupad.

Panatilihing magkasundo ang DNS ng tunnel at ang mga ruta nito

Ang profile ng VPN na nagtutulak ng resolver ngunit hindi ang prefix na naglalaman nito ay gumagawa ng resolver na hindi maabot ng kliyente; ang nagtutulak ng prefix na walang resolver ay nag-iiwan sa kliyente na magtanong sa lokal. Ituring ang pares bilang isang configuration item at suriin ang pareho pagkatapos ng bawat pagbabago ng profile, dahil ang naayos na pagkakasunod-sunod ng pagtutulak o bagong patakaran ng split tunnel ay maaaring maghiwalay sa kanila.

Suriin din kung ano ang ginagawa ng kliyente sa itinulak na setting. May mga kliyenteng inilalapat ang DNS server sa interface ng tunnel lamang at iniiwan ang resolver ng pisikal na adapter sa puwesto nito, kaya kung alin ang mananalo ay depende sa metric ng interface at sa pangalang itinatanong. Kung ang panloob na sagot ay dumarating lamang kapag naka-disable ang pisikal na adapter, iyon ang mekanismong dapat ayusin, hindi ang mga record ng domain.

Tanggapin gamit ang isang tawag sa pagtuklas at isang live na operasyon

Ang kapaki-pakinabang na acceptance test ay nagpapatakbo ng locator query at pagkatapos ay nagsasagawa ng isang tunay na authenticated na operasyon, tulad ng pagbubukas ng share na sinusuportahan ng directory o paghingi ng ticket. Gawin ito bago ang paglipat ng VPN at muli pagkatapos, sa parehong makina, nang walang restart sa gitna. Ang mga naka-cache na kredensyal at nakabukas nang session ay kusang gagawing mukhang malusog ang sirang landas, kaya ang matagumpay na pag-sign in sa desktop ay hindi ang pagsubok.

Ang mga rekomendasyon ng Microsoft para sa DNS client ay gumuhit ng parehong linya sa pagitan ng paglutas ng panloob na namespace at pagpapasa ng mga pampublikong query pataas, at iyon ang kaayusang dapat panatilihin kapag ipinakilala ang VPN.

Kung ang pagkabigo ay mabagal lamang at hindi nabigo, panatilihing hiwalay ang pagkaantala sa diagnosis. Ang timeout sa panahon ng pagtuklas ay maaaring magmula sa controller na hindi maabot, port na naka-block o resolver na huling sumasagot, at wala sa mga iyon ang napatutunayan ng paghihintay lamang. Itala ang aktwal na query, ang sagot nito at ang pagtatangka sa koneksyon bago baguhin ang setting ng resolver.