Avalik DNS töötab, kuid see ei tähenda, et Active Directory oleks leitav

VPN ühendub, brauser avab avaliku saidi ja sülearvuti ei saa ikkagi domeeni sisse logida. Tavaline järeldus on, et DNS on korras, sest nimed lahendatakse. See ei ole korras, ja põhjus on selles, et brauseri test kontrollib ainult üht päringut ahelast, mida domeeniga liidetud klient vajab. Domeeni tuvastus küsib kõigepealt teenusekirjeid, seejärel nende kirjetega nimetatud kontrollerite aadresse ja lõpuks marsruuti portideni, millel need kontrollerid kuulavad. Avalik vastus ei rahulda ühtegi neist sammudest.

Müüt: nimed lahendatakse, seega on DNS valmis

See, et avalik sait lahendatakse, ütleb ainult, et mõni resolver vastas ühele A- või AAAA-päringule avalikus tsoonis oleva nime kohta. Active Directory kasutab sama protokolli teise küsimuse jaoks: kus on domeeni teenused ja millist kontrollerit peaks see klient kasutama. Küsimus väljendub SRV-kirjetena domeeni järgi nimetatud tsoonis ning rekursiivsel avalikul resolveril pole põhjust neid hoida.

Kui kirje puudub, tagastab resolver eitava vastuse, mis on kehtiv DNS-vastus, mitte katkestus. Seejärel laskub klient vahemällu salvestatud kontrolleri teabele, kui seda on, ja täpselt seepärast võib töölauaarvuti tunde hea välja näha ning pärast taaskäivitust või parooli muutmist ebaõnnestuda.

Mida domeeni klient tegelikult küsib, järjekorras

Domeeni nagu corp.example puhul on üldine lokaatoripäring _ldap._tcp.dc._msdcs.corp.example. SRV-vastused nimetavad võimalikke kontrollereid ja nende porte, seejärel vajab klient nende hostinimede aadressikirjeid, enne kui saab ühenduse avada. Saidi teadlik tuvastus lisab päringud saidi alamdomeeni alla ning vastused määravad, millised kontrollerid on eelistatud, mitte milline on kohustuslik.

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

Järgige ahelat selles järjekorras, võrgust, kus probleem tekib. Hostinimi, mis lahendub kättesaamatule aadressile, on marsruutimise tõrge, mitte DNS-i tõrge. Kättesaadav kontroller, mille lokaatorikirjed puuduvad, on DNS-i tõrge, mitte marsruutimise tõrge. Mõlemad tekitavad sarnaseid kasutajakaebusi ja täiesti erinevaid parandusi.

Miks avalik resolver vastab ja sisselogimine ikkagi katkeb

Kui adapter annab kliendile avaliku resolveri, töötavad avalikud nimed ja sisemine nimeruum ei tööta. Teise avaliku resolveri lisamine ei aita, sest kumbki ei hoia tsooni. Ka tavaline loend „kõigepealt sisemine, siis avalik“ ei käitu domeenipõhise reeglina: esimese serveri eitav vastus on seaduslik vastus ning klient ei proovi teist serverit uuesti ainult seetõttu, et vastus oli tühi.

Mõlemad sisemised resolverid, kui neid kaks on, peavad hoidma AD nimeruumi ja olema kliendi praegusest võrgust kättesaadavad. Just seda lõhuvad poolitatud tunneliga lahendused: VPN võib kanda tunneli alamvõrku, samal ajal kui sisemine resolver asub prefiksil, mida tunnel ei marsruudi, nii et päring läheb resolverile, mis ei saa sellele vastata.

Windows rakendab ka nimelahenduse poliitikat, mis võib suunata kindlad nimeruumid kindlatele serveritele, ning adapteri näidatud DNS-aadressid ei ole kogu lugu. Adapteri loendi muutmine ilma seda poliitikat muutmata võib jätta tegeliku konfiguratsiooni puutumata ja seetõttu ei ole rakendatuna näival parandusel mingit mõju.

Hoidke tunneli DNS ja selle marsruudid kooskõlas

VPN-profiil, mis saadab resolveri, kuid mitte seda sisaldava prefiksi, loob resolveri, milleni klient ei ulatu; profiil, mis saadab prefiksi ilma resolverita, jätab kliendi kohalikku küsima. Käsitlege paari ühe konfiguratsiooniüksusena ja kontrollige mõlemat pärast iga profiilimuudatust, sest ümberjärjestatud saatmine või uus poolitatud tunneli poliitika võib need lahutada.

Kontrollige ka, mida klient saadetud seadistusega teeb. Mõned kliendid rakendavad DNS-serveri ainult tunneli liidesele ja jätavad füüsilise adapteri resolveri paigale, nii et võitja sõltub liidese metrikast ja küsitavast nimest. Kui sisemine vastus tuleb ainult siis, kui füüsiline adapter on välja lülitatud, on see mehhanism parandamist vajav, mitte domeeni kirjed.

Võtke vastu tuvastuskutse ja ühe reaalse toiminguga

Kasulik vastuvõtutest käivitab lokaatoripäringu ja teeb seejärel ühe tõelise autenditud toimingu, näiteks avab kataloogipõhise jagatud ressursi või taotleb pileti. Tehke seda enne VPN-i üleminekut ja uuesti pärast, samal masinal, ilma vahepealse taaskäivituseta. Vahemällu salvestatud volitused ja juba avatud sessioonid muudavad katkise tee hea meelega terveks, seega õnnestunud töölaua sisselogimine ei ole test.

Microsofti DNS-kliendi soovitused tõmbavad sama piiri sisemise nimeruumi lahendamise ja avalike päringute edasisaatmise vahele ning see on korraldus, mida VPN-i kasutuselevõtul säilitada.

Kui tõrge on ainult aeglane, mitte ebaõnnestunud, hoidke viivitus diagnoosist eraldi. Tuvastamise ajal võib aegumine tulla kättesaamatust kontrollerist, blokeeritud portist või hilja vastavast resolverist ning ükski neist ei ole tõestatav ainult ootamisega. Jäädvustage tegelik päring, selle vastus ja ühenduskatse enne resolveri seadistuse muutmist.