DNS diviso su OpenVPN: cosa deve fare un dominio di instradamento su ogni sistema operativo

Ogni richiesta di DNS diviso inizia con la stessa frase: i nomi dell’azienda vanno al DNS dell’azienda, tutto il resto continua a funzionare. Trasformare quella frase in una configurazione significa rispondere a tre domande per sistema operativo, e le risposte usano meccanismi diversi su ciascuno. I profili che funzionano su un portatile Linux spesso falliscono su Windows per motivi che non hanno nulla a che vedere con il tunnel. Il divario è di solito un’impostazione del resolver scambiata per una rotta.

Nominate prima la politica, poi scegliete la primitiva della piattaforma che la esprime.

Tre impostazioni facili da confondere

Un suffisso di ricerca espande un nome breve: digitare files diventa files.corp.example quando il resolver prova i suffissi in ordine. Un dominio di instradamento sceglie quale resolver risponde alle query dentro uno spazio dei nomi. Una rotta IP rende raggiungibile solo il resolver scelto. Questi tre vivono in livelli diversi, e scambiare l’uno con l’altro produce una configurazione che sembra corretta e non risolve nulla.

La confusione ha un costo: aggiungere un suffisso di ricerca manda ogni nome breve al resolver del lavoro, compresi nomi che appartengono altrove. Scegliere un dominio di instradamento tiene le query non correlate sul resolver locale e comunque invia *.corp.example attraverso il tunnel.

Linux: un dominio di sola rotta, non un suffisso di ricerca

Su systemd-resolved, un dominio preceduto da una tilde è un dominio di sola rotta, il che significa che le query per quello spazio dei nomi vanno al resolver collegato senza diventare anche un suffisso di ricerca. resolvectl domain tun0 '~corp.example' lo imposta, e resolvectl dns tun0 10.8.0.1 nomina il server. Entrambe le impostazioni appartengono all’interfaccia, quindi spariscono con essa. La tilde è la parte che la gente omette, e senza di essa i nomi brevi iniziano a risolversi tramite il resolver del lavoro.

Non installate anche lo stesso dominio come suffisso di ricerca globale. Le due impostazioni non sono ridondanti; una instrada e l’altra riscrive ciò che avete digitato.

Windows vuole una politica dello spazio dei nomi, non un suffisso

Windows conserva la politica di DNS diviso nella Name Resolution Policy Table, non nel suffisso DNS della scheda di rete. Una regola mappa uno spazio dei nomi su server specifici: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Impostare solo il suffisso cambia l’aspetto dei nomi brevi; non indirizza la query a un altro server.

Controllate la politica effettiva con Get-DnsClientNrptPolicy dopo la connessione, perché una regola di una connessione precedente può sopravvivere al tunnel. Rimuovete le regole per nome quando il tunnel cade, e mantenete stabile il nome visualizzato così che la pulizia colpisca la voce giusta.

Un solo proprietario del resolver per piattaforma

Un gestore del desktop, uno script up di OpenVPN e un demone del resolver locale possono tutti provare a scrivere la stessa configurazione. Quando non sono d’accordo, vince l’ultimo che scrive e il risultato dipende dall’ordine di smontaggio. Scegliete un componente che possieda lo stato del resolver, lasciate che gli altri riportino invece di scrivere, e provate una riconnessione: la politica dovrebbe sopravvivervi senza duplicare le regole. Provate anche una disconnessione, perché è lo stato residuo che fa comportare diversamente la connessione successiva.

Le applicazioni che portano con sé un proprio resolver cifrato ignorano del tutto la politica del sistema operativo. È una proprietà dell’applicazione, non un difetto del tunnel.

Verificate il risultato, non il testo del profilo

Risolvete un nome che deve passare dal tunnel e uno che non deve, su ogni piattaforma, e confermate quale server ha risposto. resolvectl query host.corp.example e Resolve-DnsName host.corp.example riportano entrambi il server che ha risposto. Ripetete dopo una riconnessione. Poi confermate che il resolver del tunnel è raggiungibile all’indirizzo che il profilo spinge, perché una politica corretta che punta a un server irraggiungibile fallisce come nessuna politica.

Registrate il comportamento previsto nelle note del profilo: quale suffisso instrada, quale server risponde e cosa succede a tutto il resto. La prossima piattaforma che supporterete avrà più bisogno di quella frase che del file di configurazione.