wg-quick rompe il DNS alla connessione: leggete l’errore di configurazione

Il tunnel sale, la stretta di mano si completa e la risoluzione dei nomi si ferma. Nulla nella configurazione del peer è cambiato, perché la riga DNS non è mai stata parte di quella configurazione. Appartiene all’assistente di configurazione, il che significa che il guasto vive negli strumenti del resolver dell’host e non nelle chiavi di WireGuard.

Leggete il primo messaggio stampato dall’assistente, non l’ultimo, e la differenza tra un’utilità mancante e un server irraggiungibile diventa evidente.

La riga DNS è una funzione dell’assistente

I campi di base della configurazione descrivono peer, chiavi e indirizzi consentiti. La risoluzione viene aggiunta sopra dallo script che alza l’interfaccia, e ogni implementazione lo fa in modo diverso. Un client desktop può gestire il DNS tramite il proprio servizio, uno script di distribuzione può chiamare una delle varie utilità di resolver, e un container può non fare nessuna delle due cose. Il file di configurazione non può dirvi quale di questi percorsi è in gioco.

Per questo un file di configurazione può essere valido per il protocollo e fallire comunque durante la configurazione: il guasto appartiene a un hook che il protocollo non vede mai.

Scrivere un campo esteso in una configurazione di base e aspettarsi che lo strumento del protocollo lo accetti produce la stessa confusione dalla direzione opposta. I due parser leggono file diversi.

Sapere quale dei due è in esecuzione è il primo passo diagnostico, e di solito si vede nel comando digitato più che nel file di configurazione.

Leggete il primo errore stampato dall’assistente

Alzate l’interfaccia in primo piano e leggete l’output in ordine. Un’utilità di resolver mancante, un hook fallito e un server irraggiungibile fermano lo stesso comando in punti diversi, e ciascuno ha la sua riparazione.

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

Il primo comando riporta l’avanzamento della configurazione, il secondo mostra quali server l’interfaccia rivendica ora, e il terzo mostra se l’indirizzo del resolver è davvero raggiungibile attraverso il tunnel. Un resolver configurato ma non instradabile produce timeout invece di errori di configurazione, ed è per questo che i due controlli vanno insieme. Leggere solo l’output di stato produce una conclusione sicura e sbagliata.

Se la configurazione è terminata e la risoluzione dei nomi fallisce ancora, confrontate il resolver installato dall’assistente con quello che la rete usava prima. Un resolver privato ha bisogno di una rotta attraverso il tunnel, e una configurazione che lo elenca senza coprirne il prefisso lascia ogni query in attesa.

Quale resolver ha davvero l’host

Gli host Linux moderni eseguono spesso un resolver stub locale, quindi l’indirizzo installato dall’assistente viene consumato da quello stub e non direttamente dalle applicazioni. Modificare a mano un file generato può sembrare funzionare fino alla riconnessione successiva, quando l’assistente lo riscrive.

Usate l’integrazione supportata per la distribuzione e lasciate che un solo componente possieda lo stato del resolver. Due proprietari producono la stessa corsa di due proprietari di un indirizzo di interfaccia, e il sintomo è un host che risolve correttamente per qualche minuto dopo ogni modifica.

I nomi interni meritano un controllo a parte. Un resolver pubblico può ripristinare la navigazione generale facendo fallire ogni nome aziendale, che è l’opposto di ciò a cui serviva il tunnel. Interrogate il server previsto sul nome interno prima di concludere che il DNS è riparato.

La pulizia conta quanto la configurazione

Abbassate l’interfaccia e ispezionate di nuovo lo stato del resolver. Un assistente che ripristina la configurazione precedente lascia l’host utilizzabile; uno che lascia dietro i propri server crea il guasto successivo, spesso ore dopo, quando il tunnel è sparito da tempo.

Lo stato obsoleto è facile da notare quando lo si cerca. Un elenco di resolver può puntare a un indirizzo su un’interfaccia che non esiste più, e un dominio di ricerca può sopravvivere a una rete che avete lasciato stamattina. Ognuno dei due rende imprevedibile la connessione successiva, e nessuno appare nell’output di stato del tunnel stesso. Il controllo richiede dieci secondi e risparmia un’ora alla persona successiva.

Tenete la diagnosi separata dalla riparazione. Se fallisce ogni destinazione, non solo le ricerche di nomi, le rotte e l’inoltro sono i sospetti e la riga DNS è una distrazione. Il manuale di wg-quick documenta quali campi gestisce e quali appartengono al protocollo, e quel confine è tutta la risposta alla maggior parte di questi resoconti.