Delujoč javni DNS še ne pomeni, da je Active Directory mogoče najti

VPN se poveže, brskalnik odpre javno spletno mesto, prenosnik pa se vseeno ne more prijaviti v domeno. Običajen sklep je, da je DNS v redu, ker se imena razrešijo. Ni v redu, in razlog je, da preizkus v brskalniku izvede samo eno poizvedbo iz verige, ki jo potrebuje odjemalec, pridružen domeni. Odkrivanje domene najprej zahteva zapise storitev, nato naslove krmilnikov, ki jih ti zapisi imenujejo, in nazadnje pot do vrat, na katerih ti krmilniki poslušajo. Javni odgovor ne zadosti nobenemu od teh korakov.

Mit: imena se razrešijo, torej je DNS končan

To, da se javno spletno mesto razreši, pove le, da je nek razreševalnik odgovoril na eno poizvedbo A ali AAAA za ime v javni coni. Active Directory uporablja isti protokol za drugo vprašanje: kje so storitve domene in kateri krmilnik naj ta odjemalec uporabi. Vprašanje je izraženo z zapisi SRV pod cono, imenovano po domeni, rekurzivni javni razreševalnik pa nima razloga, da bi jih hranil.

Ko zapisa ni, razreševalnik vrne negativen odgovor, kar je veljaven odgovor DNS in ne izpad. Odjemalec se nato vrne na predpomnjene podatke o krmilnikih, če jih ima, in prav zato je lahko namizni računalnik ure videti v redu in odpove po ponovnem zagonu ali spremembi gesla.

Kaj odjemalec domene v resnici zahteva, po vrsti

Za domeno, kot je corp.example, je splošna poizvedba lokatorja _ldap._tcp.dc._msdcs.corp.example. Odgovori SRV imenujejo kandidate za krmilnike in njihova vrata, nato pa odjemalec potrebuje naslovne zapise za ta imena gostiteljev, preden lahko odpre povezavo. Odkrivanje, ki upošteva mesto, doda poizvedbe pod subdomeno mesta, odgovori pa določijo, kateri krmilniki so prednostni, ne kateri je obvezen.

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

Sledite verigi v tem vrstnem redu, iz omrežja, kjer se težava pojavi. Ime gostitelja, ki se razreši v nedosegljiv naslov, je napaka usmerjanja, ne napaka DNS. Dosegljiv krmilnik, ki mu manjkajo zapisi lokatorja, je napaka DNS, ne napaka usmerjanja. Oba dajeta podobne pritožbe uporabnikov in povsem različna popravila.

Zakaj javni razreševalnik odgovori in prijava se vseeno zlomi

Če vmesnik odjemalcu dodeli javni razreševalnik, javna imena delujejo, notranji imenski prostor pa ne. Dodajanje drugega javnega razreševalnika ne pomaga, ker nobeden od njiju ne hrani cone. Tudi običajen seznam »najprej notranji, nato javni« se ne obnaša kot pravilo za vsako domeno: negativen odgovor prvega strežnika je zakonit odgovor in odjemalec ne poskusi drugega strežnika znova samo zato, ker je bil odgovor prazen.

Oba notranja razreševalnika, če ju imate dva, morata hraniti imenski prostor AD in biti dosegljiva iz trenutnega omrežja odjemalca. Prav to lomijo zasnove z razdeljenim tunelom: VPN lahko prenaša podomrežje tunela, medtem ko je notranji razreševalnik na predponi, ki je tunel ne usmerja, zato poizvedba odide k razreševalniku, ki je ne more odgovoriti.

Windows uporablja tudi pravilnik o razreševanju imen, ki lahko usmerja določene imenske prostore na določene strežnike, in naslovi DNS, ki jih prikaže vmesnik, niso vsa zgodba. Če seznam vmesnika spremenite brez spremembe tega pravilnika, lahko dejanska konfiguracija ostane nedotaknjena, in zato popravek, ki je videti uporabljen, nima nobenega učinka.

Naj bosta DNS tunela in njegove poti usklajeni

Profil VPN, ki potisne razreševalnik, ne pa predpone, ki ga vsebuje, ustvari razreševalnik, ki ga odjemalec ne doseže; profil, ki potisne predpono brez razreševalnika, pusti odjemalca, da vpraša lokalnega. Obravnavajte par kot eno konfiguracijsko postavko in po vsaki spremembi profila preverite oba, ker potiskanje v drugem vrstnem redu ali nov pravilnik razdeljenega tunela lahko loči enega od drugega.

Preverite tudi, kaj odjemalec naredi s potisnjeno nastavitvijo. Nekateri odjemalci uporabijo strežnik DNS samo na vmesniku tunela in razreševalnik fizičnega vmesnika pustijo na mestu, zato je zmagovalec odvisen od metrike vmesnika in poizvedovanega imena. Če notranji odgovor pride le, ko je fizični vmesnik onemogočen, je to mehanizem, ki ga je treba popraviti, ne zapisi domene.

Sprejmite s klicem odkrivanja in eno živo operacijo

Koristen sprejemni preizkus izvede poizvedbo lokatorja in nato eno resnično overjeno operacijo, na primer odpre mapo, ki jo podpira imenik, ali zaprosi za vstopnico. Naredite to pred prehodom na VPN in ponovno po njem, na istem računalniku, brez ponovnega zagona vmes. Predpomnjeni podatki za prijavo in že odprte seje bodo z veseljem naredili pokvarjeno pot videti zdravo, zato uspešna prijava na namizje ni preizkus.

Microsoftova priporočila za odjemalca DNS potegnejo isto mejo med razreševanjem notranjega imenskega prostora in posredovanjem javnih poizvedb navzgor, in to je ureditev, ki jo je treba ohraniti ob uvajanju VPN.

Če je okvara le počasna in ne neuspešna, imejte zamudo ločeno od diagnoze. Časovna omejitev med odkrivanjem lahko pride od nedosegljivega krmilnika, blokiranih vrat ali razreševalnika, ki odgovori pozno, in nobenega od tega ne dokaže samo čakanje. Zabeležite dejansko poizvedbo, njen odgovor in poskus povezave, preden spremenite nastavitev razreševalnika.