Kaksi DNS-palvelinta yhdessä sovittimessa ei jaa nimiavaruuksia

Kahden ratkaisijan listaaminen yhdessä sovittimessa näyttää tavalta lähettää yksi verkkotunnus yhdelle palvelimelle ja toinen verkkotunnus toiselle, eikä mikään ratkaisijaluettelossa toimi niin. Windows ratkaisee nimen perusteella, ja päätös siitä, miltä palvelimelta kysytään, tulee käytäntöobjekteista eikä järjestetystä osoiteluettelosta. Korvattava mielikuvamalli on jono: ei ole ensimmäistä palvelinta verkkotunnukselle A ja toista palvelinta verkkotunnukselle B. On nimiavaruuskohtainen sääntöjoukko, joka nimeää palvelimet eksplisiittisesti, ja kun nämä säännöt ovat olemassa, sovittimen luettelo lakkaa kiinnostamasta.

Myytti: kaksi osoitetta jakaa kaksi verkkotunnusta

Uskomus säilyy, koska se toimii sattumalta, kun yksi palvelin vastaa kaikkeen ja toinen on vain varavaihtoehto. Asiakas kysyy ensimmäiseltä palvelimelta, tämä välittää tai rekursioi, ja vastaus saapuu; kukaan ei huomaa, millä ratkaisijalla vyöhyke todella oli. Illuusio rikkoutuu heti, kun kaksi nimiavaruutta elävät erillisissä yksityisissä vyöhykkeissä ilman niiden välistä välitystä, koska silloin ensimmäinen palvelin vastaa valtuutetusti, ettei nimeä ole. Ensimmäisen palvelimen kielteinen vastaus ei laukaise varavaihtoehtoa, koska asiakas sai lopullisen vastauksen eikä virhettä.

Järjestetyllä luettelolla ei ole verkkotunnuksen käsitettä, joten se ei voi ilmaista aikomusta. Luettelo itse asiassa hallitsee sitä, miltä palvelimelta kysytään ensin ja mitä yritetään toisena, ja molemmat vastaukset pätevät jokaiseen nimeen yhtä lailla.

Mitä Windows todella käyttää valintaan

Nimenratkaisun käytäntötaulukko sovittaa nimen määritettyihin nimiavaruuksiin ja valitsee palvelimet ja asetukset kyseiselle osumalle. Säännöt voidaan määrittää paikallisesti, toimittaa ryhmäkäytännöllä tai antaa VPN-profiilista, ja tehokas käytäntö on yhdistelmä eikä yksittäinen luettelo. Siksi ensimmäinen diagnostiikka on aina tehokas tila: paikallisesti luotu sääntö, joka häviää hallitulle käytännölle, tuottaa laboratorion, joka ei käyttäydy lainkaan niin kuin sen kokoonpano antaa ymmärtää. Säännöt sovitetaan myös spesifisyyden mukaan, joten laaja nimiavaruusmerkintä voi peittää kapean tavoilla, jotka eivät näy määritettyjen kohteiden luettelossa. Tehokkaan järjestyksen lukeminen on ainoa tapa nähdä, mikä sääntö voittaa.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Ensimmäinen komento luettelee, mitä koneelle on määritetty; toinen näyttää, mitä asiakas todella soveltaa, mukaan lukien muualta tulleet merkinnät. Jos tehokas tuloste sisältää hallittuja nimiavaruuksia, kyseisen käytännön omistaja on oikea paikka pyytää muutosta, ei paikallinen sääntöluettelo. Molemmat komennot vain lukevat tilaa, joten niiden ajaminen ennen kuin joku suostuu muutokseen ei maksa mitään.

Yksi sääntö nimiavaruutta kohden, säilytä objekti

Kun tehokas tila on ymmärretty, luo yksi sääntö nimiavaruutta kohden ja säilytä objekti, jonka kukin komento palauttaa. Näyttönimet ovat ihmisille tarkoitettuja nimikkeitä, ja palautetun objektin yksilöllinen tunniste on jatkossa luotettava poistokohde. Kirjoita molemmat tunnisteet samaan muutosmuistioon, joka tallentaa nimiavaruudet ja ratkaisijat, sillä istunto, joka ne loi, ei ole se istunto, joka siivoaa.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

Alkupiste merkitsee jälkiliiteosumaa, joten sääntö kattaa app.svc.internal.example ja kaiken muun sen alla. Tässä olevat kaksi osoitetta kuuluvat tämän laboratorion omaan reitityssuunnitelmaan; sääntö ei luo vyöhykettä, asenna reittiä eikä valtuuta sovellusta, joka lopulta yhdistää, ja Add-DnsClientNrptRule-viite dokumentoi tarkalleen, mikä parametri tekee mitä.

Huomaa, mitä nämä komennot eivät tee: ne ovat koneenlaajuisia, eivät rajoitu VPN-istuntoon, ja ne säilyvät ikkunan sulkemisen jälkeen. Laboratorio, joka unohtaa tämän, jättää käytännön jälkeensä, kun tunneli on poissa.

Todista, että asiakas valitsi palvelimen

Kysyminen tietyltä palvelimelta, tunteeko se nimen, todistaa, että palvelin pystyy vastaamaan, mikä ei ole sama väite kuin se, että asiakas valitsi kyseisen palvelimen. Merkitsevä testi ratkaisee oikean nimen asiakkaan tavallisella polulla ja vahvistaa sitten, mikä ratkaisija sitä käsitteli, mieluiten kun reitin tarjoava tunneli on ylhäällä. Jos tunneli on alhaalla, oikein rajattu sääntö osoittaa silti tavoittamattomaan palvelimeen, mikä on reititysongelma eikä käytäntöongelma. Testaa molemmat tilat, jotta ne voidaan myöhemmin erottaa.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

Varo ennen sääntöjen olemassaoloa välimuistiin tallennettuja vastauksia ja sovelluksia, jotka ohittavat järjestelmän ratkaisijan kokonaan omalla salatulla DNS:llään. Hakuliitteet ovat vielä erillinen ominaisuus: sääntö voi valita ratkaisijan täydelle nimelle opettamatta Windowsille paljaan isäntänimen laajentamista kyseiseen nimiavaruuteen.

Poista juuri se, minkä loit

Siivous on paikka, jossa laboratoriosta tulee varoittava tarina. Jokaisen koneen säännön poistaminen on nopeaa ja poistaa käytäntöä, josta joku muu riippuu, joten käytä tunnisteita, jotka tallennettiin sääntöjä luotaessa, ja lue tehokas tila sen jälkeen uudelleen vahvistaaksesi, että kone palasi siihen, mistä se alkoi. Jos säännöt luonut istunto on poissa, muutosmuistio on ainoa paikka, jossa tunnisteet ovat olemassa. Siksi ne kirjoitetaan ennen ensimmäisen komennon ajamista, ei sen jälkeen.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

Käyttöönotossa eikä laboratoriossa elinkaarikysymys on yhtä tärkeä kuin sääntö. VPN-profiili voi kantaa nimiavaruussäännöt ja valita, säilyvätkö ne yhteyden jälkeen; sääntö, joka säilyy, kun ratkaisija on tavoittamaton, saa asiakkaat suosimaan kuollutta palvelinta, ja yhteyteen rajattu sääntö katoaa tunnelin mukana. Päätä, mitä näistä käyttäytymisistä palvelu tarvitsee, merkitse, kuka säännön omistaa, ja jätä valtuuden jako dokumentoiduksi profiilin viereen eikä jonkun muistiin laboratoriosta.