Një DNS publik që funksionon nuk do të thotë që Active Directory gjendet

VPN lidhet, shfletuesi hap një sajt publik dhe laptopi ende nuk mund të hyjë në domen. Përfundimi i zakonshëm është se DNS është në rregull sepse emrat zgjidhen. Nuk është, dhe arsyeja është se një provë në shfletues ushtron vetëm një kërkim nga një zinxhir që i nevojitet një klienti të bashkuar me domenin. Zbulimi i domenit kërkon fillimisht regjistrime shërbimi, pastaj adresat e kontrollorëve që emërtojnë ato regjistrime dhe në fund një rrugë drejt porteve ku dëgjojnë ata kontrollorë. Një përgjigje publike nuk plotëson asnjë prej këtyre hapave.

Miti: emrat zgjidhen, pra DNS ka mbaruar

Fakti që një sajt publik zgjidhet thotë vetëm se ndonjë zgjidhës u përgjigj një kërkese A ose AAAA për një emër në një zonë publike. Active Directory përdor të njëjtin protokoll për një pyetje tjetër: ku janë shërbimet e domenit dhe cili kontrollor duhet të përdorë ky klient. Pyetja shprehet si regjistrime SRV nën një zonë të quajtur sipas domenit, dhe një zgjidhës publik rekurziv nuk ka arsye t'i mbajë ato.

Kur regjistrimi mungon, zgjidhësi kthen një përgjigje negative, që është një përgjigje DNS e vlefshme dhe jo një ndërprerje. Klienti pastaj kthehet te informacioni i kontrollorëve në memorie nëse e ka, dhe pikërisht për këtë një kompjuter tavoline mund të duket mirë për orë të tëra dhe të dështojë pas një rindezjeje ose një ndryshimi fjalëkalimi.

Çfarë kërkon në të vërtetë një klient domeni, sipas radhës

Për një domen si corp.example, kërkimi i përgjithshëm i lokatorit është _ldap._tcp.dc._msdcs.corp.example. Përgjigjet SRV emërtojnë kontrollorë kandidatë dhe portet e tyre, dhe pastaj klienti ka nevojë për regjistrime adresash për ata emra hostesh përpara se të hapë një lidhje. Zbulimi që njeh sajtin shton kërkime nën nëndomenin e sajtit, dhe përgjigjet përcaktojnë cilët kontrollorë preferohen, jo cili është i detyrueshëm.

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

Ndiqni zinxhirin në atë radhë, nga rrjeti ku shfaqet problemi. Një emër hosti që zgjidhet në një adresë të paarritshme është dështim rrugëtimi, jo dështim DNS. Një kontrollor i arritshëm që i mungojnë regjistrimet e lokatorit është dështim DNS, jo dështim rrugëtimi. Të dyja prodhojnë ankesa të ngjashme të përdoruesve dhe riparime krejt të ndryshme.

Pse një zgjidhës publik përgjigjet dhe hyrja prapë thyhet

Nëse përshtatësi i jep klientit një zgjidhës publik, emrat publikë funksionojnë dhe hapësira e emrave të brendshëm nuk funksionon. Shtimi i një zgjidhësi të dytë publik nuk ndihmon, sepse asnjëri nuk e mban zonën. Edhe lista e zakonshme “i brendshëm i pari, publik më pas” nuk sillet si rregull për çdo domen: një përgjigje negative nga serveri i parë është përgjigje e ligjshme, dhe klienti nuk e riprovon serverin e dytë vetëm sepse përgjigja ishte e zbrazët.

Të dy zgjidhësit e brendshëm, nëse mbani dy, duhet të mbajnë hapësirën e emrave të AD dhe të jenë të arritshëm nga rrjeti aktual i klientit. Kjo është pjesa që prishin modelet me tunel të ndarë: VPN mund të transportojë nënrrjetin e tunelit ndërsa zgjidhësi i brendshëm ndodhet në një parashtesë që tuneli nuk e rrugëton, kështu që kërkimi del drejt një zgjidhësi që nuk mund t'i përgjigjet.

Windows zbaton gjithashtu një politikë zgjidhjeje emrash që mund të drejtojë hapësira të caktuara emrash drejt serverëve të caktuar, dhe adresat DNS që shfaq përshtatësi nuk janë e gjithë historia. Ndryshimi i listës së përshtatësit pa ndryshuar atë politikë mund të lërë konfigurimin efektiv të paprekur, dhe për këtë një rregullim që duket i zbatuar nuk ka asnjë efekt.

Mbani DNS-në e tunelit dhe rrugët e tij në pajtim

Një profil VPN që shtyn një zgjidhës por jo parashtesën që e përmban krijon një zgjidhës që klienti nuk e arrin; një profil që shtyn parashtesën pa zgjidhës e lë klientin të pyesë atë lokal. Trajtoni çiftin si një element të vetëm konfigurimi dhe kontrolloni të dyja pas çdo ndryshimi profili, sepse një shtytje e rirenditur ose një politikë e re tuneli të ndarë mund t'i ndajë.

Kontrolloni gjithashtu çfarë bën klienti me cilësimin e shtyrë. Disa klientë e zbatojnë serverin DNS vetëm në ndërfaqen e tunelit dhe e lënë zgjidhësin e përshtatësit fizik në vend, kështu që kush fiton varet nga metrika e ndërfaqes dhe emri i pyetur. Nëse përgjigja e brendshme vjen vetëm kur përshtatësi fizik është i çaktivizuar, ai është mekanizmi për t'u rregulluar, jo regjistrimet e domenit.

Pranoni me një thirrje zbulimi dhe një operacion të gjallë

Një provë pranimi e dobishme ekzekuton kërkimin e lokatorit dhe pastaj kryen një operacion të vërtetë të vërtetuar, si hapja e një ndarjeje të mbështetur nga drejtoria ose kërkimi i një bilete. Bëjeni para kalimit të VPN dhe përsëri pas tij, në të njëjtin makinë, pa rindezje në mes. Kredencialet në memorie dhe sesionet tashmë të hapura do ta bëjnë me kënaqësi një rrugë të thyer të duket e shëndetshme, prandaj një hyrje e suksesshme në desktop nuk është prova.

Rekomandimet e Microsoft për klientin DNS tërheqin të njëjtën vijë midis zgjidhjes së hapësirës së emrave të brendshëm dhe përcjelljes së kërkimeve publike lart, dhe ky është rregullimi që duhet ruajtur kur futet një VPN.

Nëse dështimi është vetëm i ngadaltë dhe jo i dështuar, mbajeni vonesën të ndarë nga diagnoza. Një skadim kohe gjatë zbulimit mund të vijë nga një kontrollor i paarritshëm, një port i bllokuar ose një zgjidhës që përgjigjet vonë, dhe asnjëra prej tyre nuk vërtetohet vetëm nga pritja. Regjistroni kërkimin real, përgjigjen e tij dhe përpjekjen për lidhje përpara se të ndryshoni një cilësim të zgjidhësit.