Il nameserver del VPN finisce sempre sotto quello della LAN, e modificare /etc/resolv.conf lo sistema per qualche minuto. Quel file viene generato, quindi la correzione non sopravvive mai. Nel resolvconf di Debian l’input dell’ordinamento è /etc/resolvconf/interface-order, e ordina nomi di record anziché indirizzi DNS. Verifica quale stack di risoluzione comanda davvero prima di toccare uno dei due file.

Verifica che resolvconf possieda l’output

Inizia chiedendoti cosa ha scritto il file attuale e cosa lo riscriverà. Il pacchetto resolvconf si descrive come una struttura per la configurazione dinamica del resolver, e un host che esegue systemd-resolved o un resolver gestito da NetworkManager può sembrare identico dall’esterno pur usando una politica del tutto diversa.

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

Se il percorso risolto non porta nella directory di runtime di resolvconf, fermati qui: questo manuale appartiene a un altro stack.

Solo dopo questo controllo vale la pena elencare i record che resolvconf detiene al momento.

Leggi i record prima di scrivere i pattern

interface-order corrisponde ai nomi dei record del fornitore, non agli indirizzi e non ai nomi delle interfacce del kernel. Elenca ciò che è registrato perché i tuoi pattern facciano riferimento a voci esistenti.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

Un nome di record di solito porta un suffisso che identifica il fornitore, quindi un record di tunnel e un record DHCP possono condividere un prefisso di interfaccia e comunque ordinarsi diversamente. Copia i nomi esatti dall’elenco della directory. Non dedurre un nome dal nome dell’interfaccia, perché è l’integrazione del client a decidere cosa registra. Un nome inventato non corrisponderà mai, e il record finirà nel pattern che cattura tutto senza alcun messaggio di errore.

Scrivi l’ordine come pattern di prima corrispondenza

Il file è un elenco di pattern glob della shell, uno per riga. Un record prende la posizione del primo pattern con cui corrisponde, quindi un pattern ampio sopra uno specifico rende irraggiungibile la riga specifica.

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Metti il pattern specifico del tunnel sopra il pattern che cattura tutto e sopra il pattern dell’interfaccia fisica.

Mantieni le altre righe che il file già aveva. Sostituire l’intera politica con un esempio è il modo in cui fornitori non correlati si spostano in silenzio; cambia una riga, rigenera e confronta. I pattern non possono contenere spazi, barre oblique né un punto o una tilde iniziali, e le righe vuote e i commenti con cancelletto vengono ignorati.

Rigenera e verifica il risultato

L’ordine si applica quando gli script di aggiornamento ricostruiscono il file. Attiva il percorso di aggiornamento supportato invece di modificare l’output generato, poi leggi ciò che il resolver ha realmente ricevuto.

resolvconf -u
cat /etc/resolv.conf

Verifica due risoluzioni, non una: un nome privato che dovrebbe risolversi attraverso il tunnel, e un nome di controllo pubblico. Se il nome privato continua a fallire mentre l’ordine sembra corretto, il problema è l’instradamento dello spazio dei nomi e non la priorità dei record, e nessun riordino lo risolverà. Confronta ogni risposta con il server che l’ha restituita, non solo con il successo. Un nome privato risposto dal resolver sbagliato resta un fallimento, e per l’utente sembra un’interruzione del DNS.

Dismetti il record obsoleto invece di declassarlo

Un record VPN obsoleto che riappare dopo la disconnessione è un bug del ciclo di vita nell’integrazione del client. Spostarlo in fondo nasconde il sintomo e lascia un resolver morto nell’elenco.

Dismettilo attraverso il componente che lo registra, poi conferma che la directory dei record non lo elenca più.

Annota il nome del fornitore, il pattern che hai cambiato e le due risoluzioni eseguite. La persona successiva ha più bisogno di quei nomi che della storia.

Articoli correlati