Perché un nome di server si risolve nel suo indirizzo VPN dopo la connessione telefonica

Un server file di ufficio risponde sul suo indirizzo LAN per tutta la mattina, poi un utente remoto si connette per telefono e il nome inizia a risolversi in un indirizzo di tunnel invece. Nulla è stato modificato in DNS a mano, e questo è l’indizio: il record è stato pubblicato dalla macchina stessa. Tre condizioni decidono se correggete il registrar, il record o la visione del client, e sbagliare l’ordine significa che il record torna dopo la connessione successiva.

Due indirizzi, un nome, tre condizioni

Un server Windows con più interfacce può avere un indirizzo LAN, uno o più indirizzi di connessione telefonica e talvolta una seconda scheda di rete. Ogni interfaccia può registrare i propri indirizzi in DNS se le è consentita la registrazione dinamica. Quando l’adattatore PPP si registra, lo stesso nome host ottiene un indirizzo raggiungibile solo dal peer del tunnel, e i client della LAN lo ricevono come risposta valida.

Tre condizioni decidono la riparazione. Primo, l’indirizzo aggiuntivo è raggiungibile dai client che lo ricevono? Secondo, qualche consumatore dipende ancora da quella registrazione? Terzo, il record è dinamico e quindi può tornare, oppure statico e quindi una voce deliberata?

Rispondete a questo prima di toccare qualsiasi cosa. Se l’indirizzo non è raggiungibile dalla rete che interroga, nessuna pulizia della cache del client lo corregge a lungo. Se qualcosa ne dipende, come un percorso di gestione usato dai peer del tunnel stessi, rimuoverlo spezza quel percorso. E un record dinamico cancellato senza gestire il suo publisher ricomparirà al prossimo evento di registrazione.

Leggete il record prima di cambiare il registrar

Interrogate il nome completo qualificato esatto dalla rete che segnala il problema e confrontate le risposte con le interfacce e gli ascoltatori reali del server. Un solo nome che restituisce più indirizzi è normale; la questione è se ciascuno sia utilizzabile dal client che lo riceve.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

La prima query usa il resolver locale, la seconda interroga direttamente un server DNS specifico e la terza fa lo stesso da PowerShell su Windows. Confrontarle separa una cache client obsoleta da una risposta autorevole. Se la query diretta restituisce già l’indirizzo del tunnel, il problema sono i dati pubblicati e non la cache locale.

Annotate la marca temporale del record e se la console DNS lo mostra come dinamico. Quell’unico attributo vi dice quale delle tre condizioni sopra si applica, ed è la differenza tra una pulizia di cinque minuti e una riparazione che dura.

Correggete il publisher o il record, ma sappiate quale

Se il record è dinamico e indesiderato, la correzione duratura è impedire a quell’interfaccia di registrarsi. Windows espone impostazioni di registrazione per interfaccia, e il servizio client DNS ripubblica alla connessione o al cambio di indirizzo successivo. Disattivare la registrazione per l’adattatore di connessione telefonica lascia intatta la registrazione dell’adattatore LAN, che di solito è ciò che si vuole.

Attenzione agli interruttori validi per l’intera macchina. Un’impostazione globale che disattiva l’aggiornamento dinamico influisce su ogni interfaccia di quell’host, compresa quella su cui altri client fanno affidamento per la registrazione. Su un controller di dominio la stessa cautela vale con maggiore forza, perché l’host può possedere anche record di posizione del servizio da cui i client dipendono per l’accesso.

Se il record è statico, è stato collocato lì di proposito e la conversazione è con chi lo ha collocato. Cancellare un record statico perché oggi è scomodo elimina l’unica prova del perché esiste. In entrambi i casi, cancellate la risposta obsoleta solo dopo aver gestito il publisher, e annotate cosa avete cambiato così la persona successiva può distinguere una voce deliberata da un incidente.

Verificate dalla rete client che ha fallito

La verifica appartiene alla rete che ha segnalato il sintomo, non al server. Svuotate la cache del resolver del client tramite il suo meccanismo supportato, poi ripetete la ricerca originale e la connessione originale al servizio per nome.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

Il primo comando svuota la cache del resolver di Windows, e il secondo mostra se il nome è di nuovo in cache e quale indirizzo è stato memorizzato. Una connessione riuscita del server a se stesso non dimostra nulla su un client della LAN, e rimuovere una rotta verso l’indirizzo indesiderato non corregge ciò che il DNS pubblica.

Infine, ripetete l’evento che in passato introduceva l’indirizzo: ricollegate il client VPN o rinnovate la sessione di connessione telefonica. Controllate di nuovo il nome pubblicato dopo quel cambio di ciclo di vita. Una riparazione che dura solo fino alla connessione successiva era una pulizia, non una riparazione, e sapere quale delle due avete eseguito è la differenza tra chiudere il ticket e riaprirlo la settimana prossima.