Tre sorgenti possono pubblicare l’indirizzo VPN di un controller di dominio nel DNS

Tre componenti diversi su un controller di dominio con più interfacce possono inserire lo stesso indirizzo VPN nel DNS, e falliscono in modo indipendente. Confronta ciò che pubblica ciascuno invece di fidarti della casella di controllo dell’adattatore, che ne governa solo uno. Il sintomo è identico in ogni caso: un client risolve il nome, riceve l’indirizzo del tunnel e non riesce a raggiungere il controller di dominio. Chi lo ha pubblicato decide come fermarlo.

Un’impostazione, un servizio e un ruolo; tre sorgenti, tre interruttori.

Parti dal record, non dalla casella di controllo

Interroga il nome completo del server interessato tramite il server DNS che i client usano davvero, e annota ogni indirizzo restituito. Confronta ogni indirizzo restituito con le interfacce LAN e tunnel reali del server e con le reti in cui si trovano i client. Un indirizzo può essere perfettamente valido in locale e irraggiungibile per i client che contano. Gli errori di autenticazione intermittenti sono un sintomo comune, perché i client ricevono o scelgono indirizzi diversi in tentativi diversi.

Che la macchina risolva correttamente il proprio nome dimostra molto poco. Il test che conta si esegue dalle reti dei client.

L’adattatore è solo una delle sorgenti

Le proprietà TCP/IP dell’adattatore contengono una casella per registrare l’indirizzo di quella connessione, e toglierla silenzia esattamente una sorgente. Non ferma le altre, ed è per questo che il record può ricomparire dopo un riavvio. Se il controller di dominio esegue anche il servizio DNS, quel servizio ha una propria configurazione di ascolto e propri record di server dei nomi. La guida Microsoft per gli ambienti con più interfacce tratta il comportamento dell’interfaccia, il servizio DNS e Netlogon come sorgenti distinte e rilevanti.

Tre interruttori, tre proprietari, e solo uno di loro vive nella pagina delle proprietà dell’adattatore.

Il servizio DNS ha i propri indirizzi

Un server DNS a cui viene detto di ascoltare su un indirizzo VPN continua a pubblicarlo nei propri record, qualunque cosa affermi la casella di controllo dell’adattatore. Allinea gli indirizzi di ascolto del servizio alle interfacce previste e rivedi nello stesso momento le voci del server dei nomi della zona. Cambiare gli ascolti può interrompere client che stanno usando proprio un indirizzo che rimuovi, quindi stabilisci prima chi dipende da ciascuno. Cancellare un ascolto solo perché è un indirizzo VPN può tagliare fuori i client che volevi aiutare.

Netlogon, e in generale l’individuazione dei controller di dominio, registrano anch’essi indirizzi come parte dei propri compiti. Non sopprimere le registrazioni a livello di dominio e non copiare una vecchia soluzione di registrazione per l’accesso remoto senza verificare che valga per la tua versione e il tuo ruolo.

La proprietà prima della pulizia

Correggi la sorgente prima di rimuovere il record, altrimenti il successivo evento di registrazione lo rimette e l’esercizio si ripete. Elimina le voci obsolete tramite il processo del proprietario del DNS e tieni conto della cache e dell’invecchiamento. Verifica dalle reti dei client, coprendo l’individuazione del dominio e l’applicazione che ha fallito all’inizio, poi attiva lo stesso evento VPN che ha prodotto l’indirizzo la prima volta.

Ciò che vuoi alla fine è un insieme noto di indirizzi e ascolti pubblicati, con la registrazione di dominio quotidiana che continua a fare il suo lavoro. Una macchina il cui nome si risolve correttamente subito dopo una pulizia manuale non è questo.

Annota quale sorgente era responsabile, quali record sono cambiati e quali client sono stati testati. Il prossimo server con più interfacce avrà gli stessi tre sospetti.