AD-toimipaikan kartoitus vai toimialueen ohjauskoneen kiinnittäminen VPN-asiakkaille

VPN-poolin etäkäyttöasiakkaat voivat päätyä puhumaan toisella puolella maailmaa olevalle toimialueen ohjauskoneelle, ja se korjataan kahdella tavalla: kuvaile pooli Active Directory -aliverkoksi, joka on sidottu siihen toimipaikkaan, jossa oikeat ohjauskoneet ovat, tai kiinnitä asiakas tai sovellus yhteen tiettyyn ohjauskoneeseen. Ensimmäinen on topologiaväite, jonka pohjalta DC Locator voi toimia. Toinen on sovelluskohtainen ohitus, joka jättää topologian kokonaan huomiotta. Ne maksavat eri asioita, ja tänään nopeampaan tarttuminen on juuri se, miten hakemistotiimi päätyy ylläpitämään molempia.

Mitä kukin lähestymistapa todella muuttaa

Aliverkon objekti on hakemistotietue, joka kertoo, mihin toimipaikkaan osoitealue kuuluu. Active Directory -moduulin ja olemassa olevan toimipaikan kanssa toimenpide on tarpeeksi pieni esikatseltavaksi:

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf esikatselee hakemistokirjoituksen. Se ei luo objektia eikä testaa, pääseekö alueen asiakas mihinkään, ja juuri sitä ihmiset odottavat. DC Locator lukee toimipaikkamallia, kun se ratkaisee palvelutietueita, joten tarkka aliverkko-objekti muuttaa sitä, mitä asiakkaalle tarjotaan.

Kiinnittäminen toimii eri kerroksessa. Kiinteä ohjauskoneen nimi sovelluksen asetuksissa, LDAP-merkkijono, jossa on isäntä, tai rekisteriarvo, joka nimeää ensisijaisen palvelimen, poistavat kaikki löytämisen polulta. Sovellus puhuu kyseiselle ohjauskoneelle, kunnes joku muuttaa asetusta, ja vikasietotila on se, mitä kyseinen sovellus itse toteuttaa.

Missä aliverkon kartoitus voittaa

Poolin kartoittaminen kuvaa verkkosijainnin kerran, jokaiselle asiakkaalle, joka käyttää DC Locatoria. Kun pooli kasvaa yhdestä /24:stä kolmeen, malli muuttuu kahdessa tai kolmessa objektissa sovellusluettelon sijaan. Siinä on koko etu, ja se on suuri, kun asiakasmäärä ei ole hallinnassasi.

Koukku on siinä, että objektin on vastattava osoitetta, jonka ohjauskone todella näkee. Jos VPN-yhdyskäytävä kääntää jokaisen asiakkaan keskitinosoitteeksi, kääntämättömän poolin lisääminen kuvaa verkkosijaintia, jota mikään ohjauskone ei koskaan havaitse. Päätä varhain, säilyttääkö suunnittelu asiakkaan lähdeosoitteen, ja jos ei, kartoita käännetty alue sen poolin sijaan, jonka määritit VPN-palvelimelle.

Toinen raja: toimipaikkamalli on mieltymys ja topologiaväite. Se ei tee ohjauskoneesta tavoitettavaa eikä anna käyttäjälle mitään. Tavoitettavuuden tekevät reitit ja palomuurikäytäntö; valtuutuksen tekee tilitkäytäntö.

Missä kiinnittäminen voittaa

Kiinnittäminen on oikea vastaus, kun löytäminen ei voi toimia: vanha sovellus, joka ratkaisee ohjauskoneen nimellä, jota et voi muuttaa, suodatin, joka sallii täsmälleen yhden ohjauskoneen osoitteen, tai kiinteä palvelinryhmä, jossa ohjauskone on osa sovelluksen suunnittelua. Näissä tapauksissa kiinnitys on todellisen rajoitteen dokumentointia eikä oikotie.

Sen hinta on kartoituksen vastakohta. Kiinnitetty nimi ei seuraa poolia, ei vaihda vikatilanteessa ellei sovellus osaa, eikä kestä ohjauskoneen uudelleennimeämistä tai poistoa ilman inventaarion läpikäyntiä. Se myös piilottaa topologiaongelmia, koska jokainen kiinnitetty asiakas näyttää terveeltä, kun toimipaikkamalli hiljaa mätänee.

Toimialueen tavallisten osoitetietueiden korvaaminen yhdellä ensisijaisella palvelimella ei ole kolmas vaihtoehto. Se rikkoo jokaisen kuluttajan, joka odottaa tavallista löytämisjoukkoa, eikä silti hallitse sitä, miten hakemistotietoinen asiakas valitsee toimipaikan.

Valitse kolmen ehdon perusteella

Kysy ne tässä järjestyksessä ja päätös tekee yleensä itse itsensä. Ensinnäkin, käyttääkö sovellus ylipäätään DC Locatoria vai kantaa jo ohjauskoneen osoitetta? Toiseksi, näkeekö ohjauskone poolin osoitteen vai käännetyn? Kolmanneksi, kuinka usein pooli muuttuu verrattuna siihen, kuinka moneen paikkaan kiinnitys pitäisi päivittää?

Hakemistotietoiset sovellukset plus lähteen säilyttävä reititys plus muuttuva pooli: kartoita aliverkko. Sovellus, joka ei voi löytää, tai suodatin, joka hyväksyy yhden osoitteen: kiinnitä se ja kirjoita miksi. Kaikki muu on tapaus topologian korjaamiseksi sen sijaan, että lisättäisiin vielä yksi ohitus.

Vahvista VPN-asiakkaasta ja pidä sopimukset erillään

Testaa todelliselta etäpolulta, älä LAN-työasemalta, joka istuu jo toimipaikassa. Vain asiakkaan oma näkymä ratkaisee:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

Jos raportoitu toimipaikka on se, jonka kartoitat, objekti täsmää. Jos asiakas ei raportoi toimipaikkaa, sen esittämä osoite ei osu mihinkään aliverkko-objektiin, mikä yleensä tarkoittaa käännöstä tai vanhentunutta etuliitettä. Tarkista sitten, että valittu ohjauskone on se, jonka tarkoitit, ennen kuin oletat kartoituksen epäonnistuneen, koska asiakkaat välimuistittavat löytämistuloksia ja vikasietotila voi laillisesti valita toisen ohjauskoneen.

Pidä kolme sopimusta yhdessä asiakirjassa: pooli ja sen aliverkko-objektit, VPN-polulta tavoitettavat ohjauskoneet ja käytäntö, joka päättää, mitä kirjautunut käyttäjä saa tehdä. Toimipaikka ei ole palomuurisääntö eikä eristysraja, ja seuraava poolin muutos irrottaa etäkäyttäjät hiljaa hakemiston verkkomalista, elleivät kartoitus, reitit ja dokumentoidut vaihtoehdot liiku yhdessä.