Publika DNS funkcias, sed tio ne signifas, ke Active Directory estas trovebla

La VPN konektiĝas, la retumilo malfermas publikan retejon, kaj la tekkomputilo tamen ne povas sinĝeni en la domajnon. La kutima konkludo estas, ke DNS estas en ordo ĉar nomoj solviĝas. Ĝi ne estas en ordo, kaj la kialo estas, ke retumila provo ekzercas nur unu serĉon el ĉeno, kiun bezonas kliento aliĝinta al la domajno. Domajna malkovro unue petas servajn rikordojn, poste la adresojn de la regiloj, kiujn tiuj rikordoj nomas, kaj poste itineron al la pordoj, sur kiuj tiuj regiloj aŭskultas. Publika respondo kontentigas neniun el tiuj paŝoj.

La mito: nomoj solviĝas, do DNS estas finita

Tio, ke publika retejo solviĝas, diras nur, ke iu solvilo respondis al unu A aŭ AAAA-demando pri nomo en publika zono. Active Directory uzas la saman protokolon por alia demando: kie estas la servoj de la domajno, kaj kiun regilon uzu ĉi tiu kliento. La demando esprimiĝas per SRV-rikordoj sub zono nomita laŭ la domajno, kaj rikura publika solvilo havas neniun kialon teni ilin.

Kiam la rikordo mankas, la solvilo redonas negativan respondon, kio estas valida DNS-respondo kaj ne interrompo. La kliento tiam reiras al kaŝmemoraj informoj pri regiloj, se ĝi havas ilin, kaj ĝuste tial labortabla komputilo povas aspekti bone dum horoj kaj malsukcesi post restartigo aŭ pasvorta ŝanĝo.

Kion domajna kliento efektive demandas, laŭ ordo

Por domajno kiel corp.example, la ĝenerala lokserĉo estas _ldap._tcp.dc._msdcs.corp.example. La SRV-respondoj nomas kandidatajn regilojn kaj iliajn pordojn, kaj poste la kliento bezonas adresajn rikordojn por tiuj gastigaj nomoj antaŭ ol malfermi konekton. Loke konscia malkovro aldonas demandojn sub la subdomajno de la loko, kaj la respondoj difinas, kiuj regiloj estas preferataj, ne kiun devigas.

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

Sekvu la ĉenon en tiu ordo, de la reto, kie la problemo okazas. Gastiga nomo, kiu solviĝas al neatingebla adreso, estas itinera fiasko, ne DNS-fiasko. Atingebla regilo, kies lokaj rikordoj mankas, estas DNS-fiasko, ne itinera fiasko. La du produktas similajn plendojn de uzantoj kaj tute malsamajn riparojn.

Kial publika solvilo respondas kaj tamen rompas sinĝenon

Se la adaptilo donas al la kliento publikan solvilon, publikaj nomoj funkcias kaj la interna nomspaco ne. Aldoni duan publikan solvilon ne helpas, ĉar neniu el ili tenas la zonon. Ankaŭ la kutima listo „unue interna, poste publika“ ne kondutas kiel regulo por ĉiu domajno: negativa respondo de la unua servilo estas laŭleĝa respondo, kaj la kliento ne reprovas la duan servilon nur ĉar la respondo estis malplena.

Ambaŭ internaj solviloj, se vi funkciigas du, devas teni la nomspacon de AD kaj esti atingeblaj de la nuna reto de la kliento. Ĝuste tion rompas dezajnoj de dividita tunelo: la VPN povas porti la subreton de la tunelo, dum la interna solvilo sidas sur prefikso, kiun la tunelo ne itineras, do la demando eliras al solvilo, kiu ne povas respondi ĝin.

Windows ankaŭ aplikas politikon de nomsolvado, kiu povas direkti specifajn nomspacojn al specifaj serviloj, kaj la DNS-adresoj montrataj de la adaptilo ne estas la tuta rakonto. Ŝanĝi la liston de la adaptilo sen ŝanĝi tiun politikon povas lasi la efektivan agordon netuŝita, kaj tial riparo, kiu aspektas aplikita, havas neniun efikon.

Tenadu la DNS de la tunelo kaj ties itinerojn en konsento

VPN-profilo, kiu puŝas solvilon sed ne la prefikson enhavantan ĝin, kreas solvilon, kiun la kliento ne povas atingi; unu, kiu puŝas la prefikson sed neniun solvilon, lasas la klienton demandi la lokan. Traktu la paron kiel unu agordan eron kaj kontrolu ambaŭ post ĉiu profila ŝanĝo, ĉar reordigita puŝo aŭ nova politiko de dividita tunelo povas disigi ilin.

Kontrolu ankaŭ, kion la kliento faras kun la puŝita agordo. Iuj klientoj aplikas la DNS-servilon nur al la tunela interfaco kaj lasas la solvilon de la fizika adaptilo surloke, do kiu venkas dependas de la interfaca metriko kaj de la demandata nomo. Se la interna respondo venas nur kiam la fizika adaptilo estas malŝaltita, tiu estas la mekanismo riparinda, ne la domajnaj rikordoj.

Akceptu per malkovra voko kaj unu viva operacio

Utila akcepta provo rulas la lokserĉon kaj poste plenumas unu veran aŭtentikigitan operacion, ekzemple malfermi dosierujan kunhavaĵon aŭ peti bileton. Faru tion antaŭ la VPN-transiro kaj denove poste, sur la sama maŝino, sen restartigo intere. Kaŝmemoraj legitimiloj kaj jam malfermitaj seancoj volonte igos rompitan vojon aspekti sana, do sukcesa labortabla sinĝeno ne estas la provo.

La rekomendoj de Microsoft por la DNS-kliento desegnas la saman limon inter solvado de la interna nomspaco kaj plusendado de publikaj demandoj supren, kaj tio estas la aranĝo konservinda kiam VPN enkondukiĝas.

Se la fiasko nur malrapidas kaj ne malsukcesas, tenadu la prokraston aparte de la diagnozo. Tempolimo dum malkovro povas veni de neatingebla regilo, blokita pordo aŭ solvilo, kiu respondas malfrue, kaj nenion el tio pruvas la atendo sola. Kaptu la faktan demandon, ĝian respondon kaj la konektan provon antaŭ ol ŝanĝi solvilan agordon.