Il DNS della VPN prende ogni richiesta: correggi dns-priority in NetworkManager

Connetti la VPN dell’ufficio e all’improvviso ogni richiesta di nome va al resolver aziendale. I nomi pubblici si risolvono ancora, quindi nulla sembra rotto finché non fallisce il nome di una stampante locale o un record split-horizon restituisce l’indirizzo dell’ufficio. Su alcune installazioni Fedora accade il contrario: il resolver del provider continua a rispondere quando il tunnel è attivo. Entrambe sono una sola domanda — quale resolver possiede questa richiesta — e sui sistemi NetworkManager la risposta vive nelle proprietà DNS di ogni connessione.

Due connessioni, un solo resolver vincente

Ogni connessione dichiara una priorità DNS. Le connessioni ordinarie valgono 50 per impostazione predefinita e quelle VPN 0, e vince il valore più basso. Proprio questo valore predefinito è il motivo per cui una connessione VPN supera in silenzio il collegamento via cavo per ogni dominio che rivendica: zero batte cinquanta senza che nessuno lo abbia scelto.

La priorità ordina i candidati. Non limita ciò che viene chiesto al vincitore. Una connessione VPN senza dominio di ricerca rivendica tutto, quindi preferirla manda anche le richieste pubbliche dentro il tunnel e, in un progetto a tunnel diviso, dove il resolver aziendale inoltra.

La priorità decide l’ordine, la lista di ricerca decide la proprietà

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

La lista di ricerca è la dichiarazione di proprietà. Un dominio nudo come corp.example diventa un suffisso di ricerca e un dominio di instradamento. La forma solo instradamento ~corp.example manda le richieste sotto quel suffisso a questa connessione senza aggiungere il dominio ai nomi brevi. Quella tilde è la differenza tra «chiedi a questo server» e «chiedi a questo server e finisci la mia digitazione».

Usa entrambe le forme quando gli utenti digitano nomi host brevi e i record sono indirizzati anche con nomi completamente qualificati. Usa solo la forma di instradamento quando vuoi la divisione senza cambiare il modo in cui il resolver completa un nome nudo.

Poi rendi esplicita la preferenza e riattiva:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Una priorità negativa è il modo documentato di dire «preferisci questa connessione», e impostare entrambe le famiglie di indirizzi mantiene coerente il comportamento su un host con connettività IPv6. Cambiare la proprietà senza riattivare la connessione non cambia nulla di ciò che è in esecuzione ora, per questo la sequenza termina con un up esplicito.

Lascia che systemd-resolved gestisca la divisione

Il plugin dnsmasq predefinito convoglia le richieste in un solo resolver locale, quindi la separazione per collegamento resta grossolana. systemd-resolved espone la divisione per collegamento, e resolvectl query nomina il collegamento che ha risposto.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Dopo di che il collegamento aziendale porta corp.example e un resolver pubblico serve il resto. Quando una richiesta raggiunge il collegamento sbagliato, il comando nomina il collegamento che ha risposto, e saperlo vale più che conoscere solo l’indirizzo.

Adatta il progetto DNS al tipo di tunnel

I progetti di privacy che mandano tutto attraverso il tunnel non dovrebbero portare una lista di divisione, perché restituirebbe i nomi pubblici al resolver locale e annullerebbe l’intento. I progetti a tunnel diviso ne hanno bisogno: senza, il resolver aziendale vede ogni richiesta pubblica, e la configurazione si rompe nel momento in cui il tunnel cade.

Poi c’è il kill switch che blocca il DNS fuori dal tunnel. I nomi si risolvono per le zone del tunnel e falliscono ovunque altro mentre la connessione è perfettamente sana. Le risposte praticabili sono un permesso esplicito per il resolver della LAN o una cache locale che inoltra solo la zona aziendale, e ciascuna delle due è un’eccezione con un proprietario, non un difetto del tunnel.

Un profilo che riscrive la configurazione del resolver all’avvio dell’interfaccia si comporta quasi allo stesso modo: una volta che il resolver locale è irraggiungibile, si risolveranno solo i nomi che il tunnel conosce. Qualunque meccanismo si applichi, annota quali nomi devono funzionare in ogni stato, e passa quella lista a chi gestisce le segnalazioni.

Verifica per collegamento, poi di nuovo dopo la riconnessione

Chiedi un nome interno e uno pubblico, e guarda dove va davvero la richiesta. Una pagina di controllo delle perdite ti dice quale resolver ha risposto, non quale collegamento ha scelto il sistema, quindi non dice nulla sull’ordine che hai appena configurato.

Esegui di nuovo le due richieste dopo una disconnessione e una riconnessione. Le priorità vengono riapplicate quando una connessione si attiva, e un vecchio collegamento simbolico può sopravvivere a un aggiornamento che nessuno ricorda. Quello che vuoi lasciare scritto alla fine è quale resolver possiede quale suffisso, più un controllo che vale ancora domani.