DNS publikoak funtzionatzen du, baina horrek ez du esan nahi Active Directory aurki daitekeenik

VPN konektatzen da, nabigatzaileak gune publiko bat irekitzen du, eta eramangarriak oraindik ezin du domeinuan saioa hasi. Ohiko ondorioa da DNS ondo dagoela izenak ebazten direlako. Ez dago ondo, eta arrazoia da nabigatzaileko proba batek domeinuari lotutako bezero batek behar duen katearen kontsulta bakarra soilik probatzen duela. Domeinuaren aurkikuntzak zerbitzu-erregistroak eskatzen ditu lehenik, gero erregistro horiek izendatzen dituzten kontrolatzaileen helbideak, eta gero kontrolatzaile horiek entzuten dituzten portuetarako ibilbidea. Erantzun publikoak ez ditu pauso horietako bat bera ere betetzen.

Mitoa: izenak ebazten dira, beraz DNS eginda dago

Gune publiko bat ebazteak soilik esaten du resolverren batek A edo AAAA kontsulta bat erantzun ziola zona publiko bateko izen bati. Active Directoryk protokolo bera erabiltzen du beste galdera baterako: non daude domeinuaren zerbitzuak eta zein kontrolatzaile erabili behar du bezero honek. Galdera domeinuaren izena duen zonaren azpiko SRV erregistro gisa adierazten da, eta resolver publiko errekurtsiboak ez du arrazoirik horiek gordetzeko.

Erregistroa falta denean, resolverrak erantzun negatiboa itzultzen du, hau da DNS erantzun balioduna eta ez etendura. Ondoren bezeroak kontrolatzaileen informazio katxeratura jotzen du, badu, eta horregatik beragatik mahaigain batek orduetan ondo eman dezake eta huts egin berrabiarazi edo pasahitza aldatu ondoren.

Zer eskatzen duen domeinu-bezero batek benetan, hurrenez hurren

corp.example bezalako domeinu baterako, kokapen-kontsulta orokorra _ldap._tcp.dc._msdcs.corp.example da. SRV erantzunek hautagai diren kontrolatzaileak eta haien portuak izendatzen dituzte, eta gero bezeroak host-izen horien helbide-erregistroak behar ditu konexio bat ireki aurretik. Guneaz jabetzen den aurkikuntzak gunearen azpidomeinuaren azpiko kontsultak gehitzen ditu, eta erantzunek zein kontrolatzaile diren hobetsiak zehazten dute, ez zein den derrigorrezkoa.

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

Jarraitu katea ordena horretan, arazoa gertatzen den sarean hasita. Helbide iristezin batera ebazten den host-izena bideratze-hutsegitea da, ez DNS hutsegitea. Kokapen-erregistroak falta zaizkion kontrolatzaile iristeko modukoa DNS hutsegitea da, ez bideratze-hutsegitea. Biek antzeko erabiltzaile-kexak eta erabat desberdinak diren konponketak sortzen dituzte.

Zergatik erantzuten duen resolver publiko batek eta hala ere saio-hasiera hausten duen

Adapterrak bezeroari resolver publiko bat ematen badio, izen publikoek funtzionatzen dute eta barne-izen espazioak ez. Bigarren resolver publiko bat gehitzeak ez du laguntzen, ez batek ez besteak ez baitu zona gordetzen. Ohiko “barnekoa lehen, publikoa gero” zerrendak ere ez du domeinu bakoitzeko arau gisa jokatzen: lehen zerbitzariaren erantzun negatiboa erantzun zilegia da, eta bezeroak ez dio bigarren zerbitzariari berriro saiatzen erantzuna hutsik zegoelako soilik.

Bi resolver barnekoek, bi badituzu, AD izen-espazioa gorde behar dute eta bezeroaren uneko saretik irisgarriak izan behar dira. Hori da tunel zatituaren diseinuek hausten duten zatia: VPNak tuneleko azpisarea eraman dezake, bitartean barne resolverra tunelak bideratzen ez duen aurrizki batean dago, beraz kontsulta erantzun ezin duen resolver batera irteten da.

Windows-ek izen-ebazpen politikak ere aplikatzen ditu, izen-espazio jakinak zerbitzari jakin batzuetara zuzendu ditzakeenak, eta adapterrak erakusten dituen DNS helbideak ez dira istorio osoa. Adapterraren zerrenda politika hori aldatu gabe aldatzeak konfigurazio eraginkorra ukituta gera dezake, eta horregatik aplikatuta dirudien konponketa batek ez du eraginik.

Eduki itzazu tuneleko DNSa eta bere ibilbideak bat etorrita

Resolverra baina hura biltzen duen aurrizkia bidaltzen ez dituen VPN profilak bezeroak irits ezin dezakeen resolverra sortzen du; aurrizkia baina resolverrik bidaltzen ez duenak bezeroa bertakoari galdetzen uzten du. Hartu bikotea konfigurazio-elementu bakar gisa eta egiaztatu biak profileko aldaketa bakoitzaren ondoren, berrordenatutako bidalketa edo tunel zatituaren politika berri batek bereiz ditzakeelako.

Egiaztatu ere zer egiten duen bezeroak bidalitako ezarpenarekin. Bezero batzuek DNS zerbitzaria tunelaren interfazean soilik aplikatzen dute eta adapter fisikoaren resolverra bere lekuan uzten dute, beraz zein nagusitzen den interfazearen metrikaren eta galdetzen den izenaren araberakoa da. Barne-erantzuna adapter fisikoa desgaituta dagoenean soilik iristen bada, hori da konpondu beharreko mekanismoa, ez domeinuaren erregistroak.

Onartu aurkikuntza-dei batekin eta zuzeneko eragiketa batekin

Onarpen-proba erabilgarri batek kokapen-kontsulta exekutatzen du eta gero benetako eragiketa autentikatu bat egiten du, hala nola direktorioak onartutako partekatze bat irekitzea edo txartel bat eskatzea. Egin VPNaren trantsizioa baino lehen eta berriro ondoren, makina berean, tartean berrabiarazi gabe. Katxeratutako kredentzialek eta jada irekita dauden saioek bide hautsi bat osasuntsu itxuratuko dute gustura, beraz mahaigaineko saio-hasiera arrakastatsua ez da proba.

Microsoften DNS bezeroaren gomendioek marra bera marrazten dute barne-izen espazioa ebaztearen eta kontsulta publikoak gorantz birbidaltzearen artean, eta hori da VPN bat sartzean mantendu beharreko antolamendua.

Hutsegitea motela bada eta ez porrot egina, eduki atzerapena diagnostikotik bereizita. Aurkikuntzan zehar denbora-muga kontrolatzaile iristezin batetik, portu blokeatu batetik edo berandu erantzuten duen resolver batetik etor daiteke, eta horietako bat ere ez da espero hutsarekin frogatzen. Erregistratu benetako kontsulta, haren erantzuna eta konexio-saiakera resolver ezarpen bat aldatu aurretik.