AD-platsmappning kontra att fästa en domänkontrollant för VPN-klienter

Fjärråtkomstklienter i en VPN-pool kan hamna i att prata med en domänkontrollant på andra sidan jorden, och det går att åtgärda på två sätt: beskriv poolen som ett Active Directory-undernät knutet till platsen som har rätt kontrollanter, eller fäst klienten eller programmet vid en specifik kontrollant. Det första är ett topologipåstående som DC Locator kan agera på. Det andra är en överstyrning per program som helt bortser från topologin. De kostar olika saker, och att gripa efter den snabbare i dag är precis hur ett katalogteam till slut underhåller båda.

Vad varje angreppssätt faktiskt ändrar

Ett undernätsobjekt är en katalogpost som säger vilken plats ett adressområde tillhör. Med Active Directory-modulen och en befintlig plats är operationen liten nog att förhandsgranska:

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

-WhatIf förhandsgranskar skrivningen till katalogen. Det skapar inte objektet och testar inte om en klient i området kan nå något, och det är just den delen folk förväntar sig. DC Locator läser platsmodellen när den matchar tjänsteposter, så ett korrekt undernätsobjekt ändrar vad klienten erbjuds.

Fästning verkar i ett annat lager. Ett fast kontrollantnamn i en programkonfiguration, en LDAP-sträng med en värd i, eller ett registervärde som namnger en föredragen server tar alla bort upptäckten från vägen. Programmet pratar med den kontrollanten tills någon ändrar inställningen, och växling vid fel är vad det programmet självt implementerar.

Där undernätsmappning vinner

Att mappa poolen beskriver nätverksplatsen en gång, för varje klient som använder DC Locator. När poolen växer från ett /24 till tre ändras modellen i två eller tre objekt i stället för i en programinventering. Det är hela fördelen, och den är stor när klientpopulationen inte är under din kontroll.

Haken är att objektet måste stämma med adressen som kontrollanten faktiskt ser. Om VPN-gatewayen översätter varje klient till en hubbadress beskriver tillägget av den oöversatta poolen en nätverksplats som ingen kontrollant någonsin observerar. Bestäm tidigt om designen bevarar klientens källadress, och om inte, mappa det översatta området i stället för poolen du konfigurerade på VPN-servern.

En andra gräns: platsmodellen är en preferens och ett topologipåstående. Den gör inte en kontrollant nåbar och ger inte en användare något. Nåbarheten görs av rutter och brandväggspolicy; behörigheten av kontopolicyn.

Där fästning vinner

Fästning är rätt svar när upptäckt inte kan fungera: ett äldre program som matchar en kontrollant via ett namn du inte kan ändra, ett filter som tillåter exakt en kontrollantadress, eller en fast uppsättning servrar där kontrollanten är en del av programdesignen. I de fallen är fästningen dokumentation av en verklig begränsning, inte en genväg.

Dess pris är motsatsen till mappning. Ett fäst namn följer inte poolen, växlar inte vid fel om inte programmet vet hur, och överlever inte att en kontrollant byter namn eller avvecklas utan en inventeringsgenomgång. Det döljer också topologiproblem, eftersom varje klient som fäster ser frisk ut medan platsmodellen tyst ruttnar.

Att ersätta domänens vanliga adressposter med en enda föredragen server är inte ett tredje alternativ. Det bryter varje konsument som förväntar sig den normala upptäcktsuppsättningen, och det styr fortfarande inte hur en katalogmedveten klient väljer plats.

Välj efter tre villkor

Fråga i den här ordningen och beslutet fattar sig oftast självt. För det första, använder programmet DC Locator alls, eller bär det redan en kontrollantadress? För det andra, ser kontrollanten pooladressen, eller en översatt? För det tredje, hur ofta ändras poolen jämfört med hur många platser en fästning skulle behöva uppdateras på?

Katalogmedvetna program plus källbevarande routning plus en pool som ändras: mappa undernätet. Ett program som inte kan upptäcka, eller ett filter som släpper in en adress: fäst det, och skriv ned varför. Allt annat är ett fall för att laga topologin i stället för att lägga till ännu en överstyrning.

Verifiera från VPN-klienten och håll avtalen åtskilda

Testa från den faktiska fjärrvägen, inte från en LAN-arbetsstation som redan sitter på platsen. Bara klientens egen vy räknas:

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

Rapporteras den plats du mappade stämmer objektet. Rapporterar klienten ingen plats faller adressen den presenterar inte inom något undernätsobjekt, vilket oftast betyder en översättning eller ett inaktuellt prefix. Kontrollera sedan att den valda kontrollanten är den du avsåg innan du antar att mappningen misslyckades, eftersom klienter cachar upptäcktsresultat och växling vid fel lagligt kan välja en annan kontrollant.

Håll de tre avtalen i ett dokument: poolen och dess undernätsobjekt, kontrollanterna som nås från VPN-vägen, och policyn som avgör vad en inloggad användare får göra. En plats är inte en brandväggsregel och inte en isoleringsgräns, och nästa ändring av poolen kommer tyst att koppla bort fjärranvändare från katalogens nätverksmodell om inte mappningen, rutterna och de dokumenterade alternativen rör sig tillsammans.