Julkinen DNS toimii, mutta se ei tarkoita, että Active Directory löytyy

VPN yhdistyy, selain avaa julkisen sivuston, eikä kannettava silti pysty kirjautumaan domeeniin. Tavallinen johtopäätös on, että DNS on kunnossa, koska nimet ratkeavat. Se ei ole kunnossa, ja syy on siinä, että selaintesti harjoittaa vain yhtä kyselyä ketjusta, jonka domeeniin liitetty asiakas tarvitsee. Domeenin etsintä kysyy ensin palvelutietueita, sitten niiden tietueiden nimeämien ohjainten osoitteita ja lopuksi reittiä portteihin, joissa nuo ohjaimet kuuntelevat. Julkinen vastaus ei täytä yhtäkään näistä askelista.

Myytti: nimet ratkeavat, joten DNS on valmis

Se, että julkinen sivusto ratkeaa, kertoo vain, että jokin ratkaisija vastasi yhteen A- tai AAAA-kyselyyn julkisen vyöhykkeen nimestä. Active Directory käyttää samaa protokollaa toiseen kysymykseen: missä domeenin palvelut ovat ja mitä ohjainta tämän asiakkaan pitäisi käyttää. Kysymys ilmaistaan SRV-tietueina domeenin mukaan nimetyn vyöhykkeen alla, eikä rekursiivisella julkisella ratkaisijalla ole syytä pitää niitä.

Kun tietue puuttuu, ratkaisija palauttaa kielteisen vastauksen, joka on kelvollinen DNS-vastaus eikä katkos. Asiakas turvautuu silloin välimuistiin tallennettuihin ohjaintietoihin, jos niitä on, ja juuri siksi työpöytäkone voi näyttää tunteja hyvältä ja epäonnistua uudelleenkäynnistyksen tai salasanan vaihdon jälkeen.

Mitä domeenin asiakas todella kysyy, järjestyksessä

Domeenille kuten corp.example yleinen paikanninkysely on _ldap._tcp.dc._msdcs.corp.example. SRV-vastaukset nimeävät ehdokasohjaimet ja niiden portit, ja sen jälkeen asiakas tarvitsee osoitetietueet noille isäntänimille ennen kuin voi avata yhteyden. Sivustotietoinen etsintä lisää kyselyitä sivuston alidomeenin alle, ja vastaukset määräävät, mitkä ohjaimet ovat ensisijaisia, eivät mitkä pakollisia.

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

Seuraa ketjua tässä järjestyksessä, siitä verkosta, jossa ongelma ilmenee. Isäntänimi, joka ratkeaa tavoittamattomaan osoitteeseen, on reititysvirhe, ei DNS-virhe. Tavoitettavissa oleva ohjain, jolta paikannintietueet puuttuvat, on DNS-virhe, ei reititysvirhe. Molemmat tuottavat samankaltaisia käyttäjävalituksia ja täysin erilaisia korjauksia.

Miksi julkinen ratkaisija vastaa ja kirjautuminen silti rikkoutuu

Jos sovitin antaa asiakkaalle julkisen ratkaisijan, julkiset nimet toimivat eikä sisäinen nimiavaruus toimi. Toisen julkisen ratkaisijan lisääminen ei auta, koska kumpikaan ei pidä vyöhykettä. Eikä tavallinen luettelo ”ensin sisäinen, sitten julkinen” käyttäydy vyöhykekohtaisena sääntönä: ensimmäisen palvelimen kielteinen vastaus on laillinen vastaus, eikä asiakas yritä toista palvelinta uudelleen vain siksi, että vastaus oli tyhjä.

Molempien sisäisten ratkaisijoiden, jos niitä on kaksi, on pidettävä AD:n nimiavaruus ja oltava tavoitettavissa asiakkaan nykyisestä verkosta. Juuri tämän jaetun tunnelin mallit rikkovat: VPN voi kuljettaa tunnelin aliverkkoa, kun sisäinen ratkaisija istuu etuliitteellä, jota tunneli ei reititä, joten kysely lähtee ratkaisijalle, joka ei voi vastata siihen.

Windows soveltaa myös nimenratkaisukäytäntöä, joka voi ohjata tietyt nimiavaruudet tietyille palvelimille, eivätkä sovittimen näyttämät DNS-osoitteet ole koko tarina. Sovittimen luettelon muuttaminen ilman tuon käytännön muuttamista voi jättää tehokkaan kokoonpanon ennalleen, ja siksi korjaus, joka näyttää käytetyltä, ei vaikuta mitenkään.

Pidä tunnelin DNS ja sen reitit sopusoinnussa

VPN-profiili, joka työntää ratkaisijan mutta ei sitä sisältävää etuliitettä, luo ratkaisijan, jota asiakas ei tavoita; profiili, joka työntää etuliitteen ilman ratkaisijaa, jättää asiakkaan kysymään paikalliselta. Kohtele paria yhtenä kokoonpanokohteena ja tarkista molemmat jokaisen profiilimuutoksen jälkeen, koska uudelleenjärjestetty työntö tai uusi jaetun tunnelin käytäntö voi erottaa ne.

Tarkista myös, mitä asiakas tekee työnnetyllä asetuksella. Jotkin asiakkaat soveltavat DNS-palvelinta vain tunnelin liitäntään ja jättävät fyysisen sovittimen ratkaisijan paikalleen, joten voittaja riippuu liitännän metriikasta ja kysyttävästä nimestä. Jos sisäinen vastaus saapuu vain fyysisen sovittimen ollessa poissa käytöstä, se on korjattava mekanismi, ei domeenin tietueet.

Hyväksy etsintäkutsulla ja yhdellä elävällä toiminnolla

Hyödyllinen hyväksyntätesti ajaa paikanninkyselyn ja suorittaa sitten yhden todellisen todennetun toiminnon, kuten hakemistopohjaisen jaon avaamisen tai lipun pyytämisen. Tee se ennen VPN-siirtymää ja uudelleen sen jälkeen, samalla koneella, ilman uudelleenkäynnistystä välissä. Välimuistiin tallennetut tunnistetiedot ja jo avoimet istunnot tekevät mielellään rikkinäisestä polusta terveen näköisen, joten onnistunut työpöytäkirjautuminen ei ole testi.

Microsoftin DNS-asiakkaan suositukset vetävät saman rajan sisäisen nimiavaruuden ratkaisemisen ja julkisten kyselyjen edelleenlähettämisen välille, ja se on järjestely, joka on säilytettävä, kun VPN otetaan käyttöön.

Jos vika on vain hidas eikä epäonnistunut, pidä viive erillään diagnoosista. Etsinnän aikainen aikakatkaisu voi tulla tavoittamattomasta ohjaimesta, estetystä portista tai ratkaisijasta, joka vastaa myöhään, eikä mitään niistä todista pelkkä odotus. Tallenna todellinen kysely, sen vastaus ja yhteysyritys ennen kuin muutat ratkaisijan asetusta.