A nyilvános DNS működése nem jelenti azt, hogy az Active Directory megtalálható

A VPN csatlakozik, a böngésző megnyit egy nyilvános oldalt, a laptop mégsem tud bejelentkezni a tartományba. A szokásos következtetés, hogy a DNS rendben van, mert a nevek feloldódnak. Nincs rendben, és az ok az, hogy egy böngészős teszt csak egyetlen lekérdezést gyakorol abból a láncból, amelyre egy tartományhoz csatlakoztatott kliensnek szüksége van. A tartományfelderítés először szolgáltatásrekordokat kér, aztán azokat a vezérlőcímeket, amelyeket ezek a rekordok megneveznek, majd egy útvonalat azokhoz a portokhoz, amelyeken ezek a vezérlők figyelnek. Egy nyilvános válasz egyik lépést sem elégíti ki.

A mítosz: a nevek feloldódnak, tehát a DNS kész

Egy nyilvános oldal feloldódása csak azt mondja meg, hogy valamelyik feloldó válaszolt egy A vagy AAAA lekérdezésre egy nyilvános zónában lévő névhez. Az Active Directory ugyanazt a protokollt használja egy másik kérdésre: hol vannak a tartomány szolgáltatásai, és melyik vezérlőt használja ez a kliens. A kérdést SRV-rekordok fejezik ki a tartományról elnevezett zóna alatt, és egy rekurzív nyilvános feloldónak nincs oka ezeket tárolni.

Ha a rekord hiányzik, a feloldó negatív választ ad, ami érvényes DNS-válasz, és nem kiesés. A kliens ezután a gyorsítótárazott vezérlőinformációkra esik vissza, ha vannak, és pontosan ezért nézhet ki egy asztali gép órákig jól, majd bukhat el újraindítás vagy jelszóváltoztatás után.

Mit kér valójában egy tartományi kliens, sorrendben

Egy corp.example szerű tartományhoz az általános keresőlekérdezés a _ldap._tcp.dc._msdcs.corp.example. Az SRV-válaszok megnevezik a jelölt vezérlőket és portjaikat, majd a kliensnek címrekordokra van szüksége ezekhez a hosztnevekhez, mielőtt kapcsolatot nyithat. A helytudatos felderítés lekérdezéseket ad a hely aldóménje alatt, és a válaszok határozzák meg, mely vezérlők előnyben részesítettek, és nem azt, hogy melyik kötelező.

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

Kövesse a láncot ebben a sorrendben, abból a hálózatból, ahol a probléma jelentkezik. Egy elérhetetlen címre feloldódó hosztnév útválasztási hiba, nem DNS-hiba. Egy elérhető vezérlő, amelynek hiányoznak a keresőrekordjai, DNS-hiba, nem útválasztási hiba. A kettő hasonló felhasználói panaszokat és teljesen eltérő javításokat eredményez.

Miért válaszol egy nyilvános feloldó, és miért törik mégis a bejelentkezés

Ha az adapter nyilvános feloldót ad a kliensnek, a nyilvános nevek működnek, a belső névtér nem. Egy második nyilvános feloldó hozzáadása nem segít, mert egyik sem tartja a zónát. A szokásos „előbb belső, aztán nyilvános” lista sem viselkedik tartományonkénti szabályként: az első szerver negatív válasza érvényes válasz, és a kliens nem próbálja újra a második szervert csak azért, mert a válasz üres volt.

Mindkét belső feloldónak, ha kettőt futtat, az AD névterét kell tartania, és elérhetőnek kell lennie a kliens jelenlegi hálózatából. Pontosan ezt törik meg az osztott alagút tervei: a VPN szállíthatja az alagút alhálózatát, miközben a belső feloldó olyan előtagon ül, amelyet az alagút nem irányít, így a lekérdezés olyan feloldóhoz megy, amely nem tud rá válaszolni.

A Windows névfeloldási szabályzatot is alkalmaz, amely bizonyos névtereket bizonyos szerverekhez irányíthat, és az adapter által megjelenített DNS-címek nem a teljes történet. Az adapterlista módosítása e szabályzat nélkül érintetlenül hagyhatja a tényleges konfigurációt, és ezért nincs hatása egy alkalmazottnak látszó javításnak.

Tartsa összhangban az alagút DNS-ét és útvonalait

Egy VPN-profil, amely feloldót küld, de az őt tartalmazó előtagot nem, olyan feloldót hoz létre, amelyet a kliens nem ér el; amelyik az előtagot küldi feloldó nélkül, a kliensnél hagyja a helyi kérdezését. Kezelje a párt egy konfigurációs elemként, és minden profilváltoztatás után ellenőrizze mindkettőt, mert egy átrendezett küldés vagy egy új osztott alagút szabályzat szétválaszthatja őket.

Azt is ellenőrizze, mit tesz a kliens a küldött beállítással. Egyes kliensek csak az alagút interfészére alkalmazzák a DNS-szervert, és a fizikai adapter feloldóját a helyén hagyják, ezért hogy melyik nyer, az interfész metrikájától és a kérdezett névtől függ. Ha a belső válasz csak akkor érkezik, amikor a fizikai adapter le van tiltva, az a javítandó mechanizmus, nem a tartományi rekordok.

Fogadja el egy felderítő hívással és egy élő művelettel

Egy hasznos átvételi teszt lefuttatja a keresőlekérdezést, majd végrehajt egy valódi hitelesített műveletet, például megnyit egy címtáralapú megosztást vagy jegyet kér. Tegye ezt a VPN-átmenet előtt és utána is, ugyanazon a gépen, újraindítás nélkül közben. A gyorsítótárazott hitelesítő adatok és a már nyitott munkamenetek szívesen egészségesnek láttatják a törött útvonalat, ezért a sikeres asztali bejelentkezés nem a teszt.

A Microsoft DNS-kliensre vonatkozó ajánlásai ugyanazt a határvonalat húzzák meg a belső névtér feloldása és a nyilvános lekérdezések felfelé továbbítása között, és ezt az elrendezést kell megőrizni a VPN bevezetésekor.

Ha a hiba csak lassú, és nem sikertelen, tartsa a késleltetést elkülönítve a diagnózistól. A felderítés közbeni időtúllépés jöhet elérhetetlen vezérlőtől, blokkolt porttól vagy későn válaszoló feloldótól, és ezek egyikét sem bizonyítja a várakozás önmagában. Rögzítse a tényleges lekérdezést, annak válaszát és a kapcsolódási kísérletet, mielőtt feloldóbeállítást módosít.