Due VPN, un solo resolver: vince chi ha scritto per ultimo

Due client VPN sono connessi, uno per il lavoro e uno per una rete di laboratorio, e i nomi interni si risolvono solo per il client che si è connesso per ultimo. Questo schema sembra un bug in uno dei client. Di solito è il risultato prevedibile di due programmi che scrivono la stessa configurazione del resolver senza un accordo su chi possiede quale nome.

Il mito: il VPN più recente possiede il DNS

Non esiste una regola generale per cui vince la connessione più recente. Ciò che accade dipende dal meccanismo della piattaforma e da come lo scrive ciascun client. Un client che sostituisce un file del resolver produce un esito; un client che aggiunge un dominio per collegamento ne produce un altro; un client che non fa nulla lascia intatto lo stato precedente.

Il comportamento osservato è quindi una proprietà delle due implementazioni, non una priorità documentata. Ragionare solo sull’ordine di avvio sarà a volte corretto e a volte sbagliato in modi difficili da riprodurre. Scrivete invece la mappatura. Un progetto che vive in due client non è un progetto.

Mappate gli spazi dei nomi ai resolver

Elencate i suffissi privati e il resolver richiesto da ciascuna rete, poi decidete dove devono andare i nomi pubblici. Quell’elenco è il progetto. Senza di esso, i client decidono per caso.

Una piattaforma che supporta DNS per collegamento o domini di routing può esprimere la separazione deliberatamente: un dominio va a un collegamento, un altro dominio all’altro, e tutto il resto segue un valore predefinito esplicito. Due script piatti che sovrascrivono lo stesso file non possono preservare quel progetto, perché ciascuno crede di possedere l’intera configurazione.

Su Windows, la tabella dei criteri di risoluzione dei nomi può indirizzare i suffissi a server specifici, e un client VPN può installarvi regole. Controllate il criterio invece dell’elenco degli adattatori, perché non è l’elenco degli adattatori a risolvere il nome.

Mantenete un percorso di bootstrap

Ogni client deve individuare il proprio endpoint prima di poter usare il servizio che quell’endpoint fornisce. Se il nome host dell’endpoint può essere risolto solo attraverso il tunnel, e il tunnel ha bisogno del nome host risolto, avete una dipendenza circolare che appare come un timeout di connessione. Mantenete un percorso di bootstrap fuori da entrambi i tunnel. Non costa nulla fino al giorno in cui salva la connessione.

Guardate il percorso verso ogni resolver, non solo il nome configurato per esso. Un resolver raggiungibile solo attraverso l’altro tunnel si comporta come uno mancante, e il sintomo è un timeout anziché un errore di routing.

Gli indirizzi sovrapposti non sono un problema di DNS

Due reti private che usano lo stesso intervallo di indirizzi non si risolvono con l’ordine DNS. Se entrambi i tunnel rivendicano 10.0.0.0/8, un nome che si risolve correttamente punta comunque a un indirizzo che l’host non può instradare verso il tunnel giusto. Serve una soluzione a livello di indirizzo, come intervalli distinti, uno spazio dei nomi o la traduzione, non un’altra impostazione del resolver. Deciderlo presto evita un lungo giro attraverso una configurazione DNS che non avrebbe mai funzionato.

Confrontate le assegnazioni di indirizzi dei due tunnel prima di dare la colpa alla risoluzione dei nomi. Quando entrambe le parti spingono lo stesso prefisso, l’host mantiene una sola rotta per esso, e un nome risolto attraverso il secondo tunnel finisce comunque su un indirizzo che possiede il primo tunnel. Intervalli distinti, uno spazio dei nomi per rete o la traduzione sono le correzioni; dopo la connessione di ogni client, confermate che la tabella di routing mostri il percorso previsto.

Dimostratelo con applicazioni reali

Scegliete due host che esistono solo nel proprio spazio dei nomi e un nome pubblico, poi risolvete ciascuno tramite il client che dovrebbe possederlo. Una risposta corretta dal resolver atteso non dimostra che l’applicazione raggiunga l’host, perché la rotta verso quell’indirizzo può ancora fallire. Fate seguire ogni ricerca da un test di connessione dal programma che l’utente eseguirà davvero.

Un client con la propria opzione DNS cifrata può aggirare il criterio appena verificato, quindi controllate quell’impostazione come parte della revisione. Poi riconnettete entrambi i client nell’ordine supportato dal fornitore e ripetete le ricerche; se le risposte si scambiano quando cambia l’ordine, uno scrittore concorrente possiede ancora parte della configurazione. Scoprite quale componente installa la regola - il client, il profilo del sistema operativo o un agente di gestione - prima di modificare qualcosa. Annotate l’ordine e i proprietari perché la persona successiva non debba riscoprirli.