Mappatura del sito AD contro l aggancio di un controller di dominio per i client VPN

I client in accesso remoto su un pool VPN possono finire per parlare con un controller di dominio dall altra parte del mondo, e questo si corregge in due modi: descrivere il pool come subnet di Active Directory legata al sito che contiene i controller giusti, oppure agganciare il client o l applicazione a un controller specifico. Il primo è un enunciato di topologia su cui DC Locator può agire. Il secondo è una deroga per applicazione che ignora del tutto la topologia. Costano cose diverse, e afferrare oggi la più rapida è esattamente come un team della directory finisce per mantenerle entrambe.

Cosa cambia davvero ciascun approccio

Un oggetto subnet è un record della directory che dice a quale sito appartiene un intervallo di indirizzi. Con il modulo Active Directory e un sito esistente, l operazione è abbastanza piccola da essere visualizzata in anteprima:

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

-WhatIf visualizza in anteprima la scrittura nella directory. Non crea l oggetto e non verifica se un client di quell intervallo possa raggiungere qualcosa, ed è proprio la parte che la gente si aspetta. DC Locator legge il modello dei siti quando risolve i record di servizio, quindi un oggetto subnet accurato cambia ciò che viene offerto al client.

L aggancio agisce a un altro livello. Un nome di controller fisso nella configurazione di un applicazione, una stringa LDAP che contiene un host, o un valore di registro che nomina un server preferito tolgono tutti la scoperta dal percorso. L applicazione parla con quel controller finché qualcuno cambia l impostazione, e il failover è ciò che quell applicazione implementa.

Dove vince la mappatura della subnet

Mappare il pool descrive la posizione di rete una volta, per ogni client che usa DC Locator. Quando il pool passa da una /24 a tre, il modello cambia in due o tre oggetti invece che in un inventario di applicazioni. È tutto il vantaggio, ed è grande quando la popolazione di client non è sotto il tuo controllo.

La trappola è che l oggetto deve corrispondere all indirizzo che il controller vede davvero. Se il gateway VPN traduce ogni client in un indirizzo di concentratore, aggiungere il pool non tradotto descrive una posizione di rete che nessun controller osserva mai. Decidi presto se il progetto conserva l indirizzo sorgente del client e, se non lo fa, mappa l intervallo tradotto invece del pool configurato sul server VPN.

Un secondo limite: il modello dei siti è una preferenza e un enunciato di topologia. Non rende raggiungibile un controller e non concede nulla a un utente. Le rotte e la politica del firewall danno la raggiungibilità; la politica degli account dà l autorizzazione.

Dove vince l aggancio

L aggancio è la risposta giusta quando la scoperta non può funzionare: un applicazione legacy che risolve un controller tramite un nome che non puoi cambiare, un filtro che consente esattamente un indirizzo di controller, o un insieme fisso di server in cui il controller fa parte del progetto dell applicazione. In quei casi l aggancio è documentazione di un vincolo reale, non una scorciatoia.

Il suo costo è l opposto della mappatura. Un nome agganciato non segue il pool, non esegue failover se l applicazione non sa come, e non sopravvive alla rinomina o alla dismissione di un controller senza una revisione dell inventario. Nasconde anche i problemi di topologia, perché ogni client agganciato sembra sano mentre il modello dei siti marcisce in silenzio.

Sostituire i record di indirizzo ordinari del dominio con un solo server preferito non è una terza opzione. Rompe ogni consumatore che si aspetta il normale insieme di scoperta, e continua a non controllare come un client consapevole della directory scelga un sito.

Scegli in base a tre condizioni

Ponile in questo ordine e la decisione di solito si prende da sola. Primo, l applicazione usa DC Locator oppure porta già un indirizzo di controller? Secondo, il controller vede l indirizzo del pool o uno tradotto? Terzo, quanto spesso cambia il pool rispetto a quanti punti dovrebbe aggiornare un aggancio?

Applicazioni consapevoli della directory più instradamento che preserva la sorgente più un pool che cambia: mappa la subnet. Un applicazione che non può scoprire, o un filtro che ammette un indirizzo: agganciala, e scrivi perché. Tutto il resto è un caso per riparare la topologia invece di aggiungere un altra deroga.

Verifica dal client VPN e tieni separati i contratti

Prova dal percorso remoto reale, non da una postazione LAN che si trova già nel sito. Conta solo la visuale del client stesso:

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

Se il sito riportato è quello che hai mappato, l oggetto corrisponde. Se il client non riporta alcun sito, l indirizzo che presenta non ricade in nessun oggetto subnet, il che di solito significa una traduzione o un prefisso obsoleto. Poi verifica che il controller scelto sia quello che intendevi prima di supporre che la mappatura sia fallita, perché i client mettono in cache i risultati della scoperta e il failover può legittimamente scegliere un altro controller.

Tieni i tre contratti in un unico documento: il pool e i suoi oggetti subnet, i controller raggiungibili dal percorso VPN e la politica che decide cosa può fare un utente autenticato. Un sito non è una regola del firewall e non è un confine di contenimento, e il prossimo cambio del pool staccherà silenziosamente gli utenti remoti dal modello di rete della directory se la mappatura, le rotte e le alternative documentate non si muovono insieme.