WireGuard usa ancora l’endpoint vecchio dopo le modifiche DNS

Il tunnel ha smesso di far passare traffico dopo che il record DNS del server si è spostato, e il nome si risolve correttamente dalla stessa macchina. Questi due fatti non sono in conflitto. Una configurazione WireGuard contiene un endpoint, e lo strumento risolve il nome nel momento in cui applica quella configurazione, quindi l’interfaccia in esecuzione può continuare a usare l’indirizzo che ha interrogato ore fa. Controllate cosa usa l’interfaccia prima di sostituire chiavi o toccare l’intervallo del tunnel.

Il nome viene risolto una volta, non di continuo

La configurazione di base di WireGuard prende un endpoint come indirizzo e porta, e lo strumento che alza un’interfaccia risolve un nome host in quel momento. Nulla nel protocollo di base interroga il DNS secondo un calendario, e un’applicazione client può aggiungere sopra un proprio comportamento di aggiornamento. Registrare l’indirizzo risolto, la famiglia e la porta accanto al nome rende visibile il divario. Senza quella registrazione la configurazione sembra corretta mentre l’interfaccia parla con un altro posto.

Esiste un vero aggiornamento automatico, e vale la pena conoscerlo perché somiglia a un aggiornamento DNS senza esserlo. L’endpoint di un peer può spostarsi quando arriva traffico correttamente autenticato da un nuovo indirizzo, il che è roaming e non risoluzione dei nomi. Segue il peer, quindi non può scoprire un nuovo server non correlato che il vecchio endpoint non ha mai contattato.

Confrontate il record con l’indirizzo in uso

Interrogate il nome documentato tramite il resolver che usa il client, poi chiedete all’interfaccia quale endpoint tiene. Le due risposte sono il confronto che decide il resto di questa pagina:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

La pagina di manuale wg(8) documenta i sottocomandi show usati da queste righe. Confrontate anche la famiglia dell’indirizzo, non solo l’indirizzo, perché un record che ha guadagnato una voce IPv6 è un confronto diverso da uno la cui voce IPv4 è cambiata. Se l’endpoint differisce dal record, l’interfaccia funziona su informazioni obsolete e il nome non è mai stato il problema. Se coincidono e il tunnel fallisce ancora, passate all’ascoltatore e alle regole invece che al profilo.

Il timestamp della stretta di mano è in quel blocco perché l’endpoint da solo non dice se il peer è raggiungibile. Un timestamp obsoleto accanto a un endpoint corretto è un problema di percorso, non di risoluzione, e questa distinzione cambia ciò che toccate dopo.

Riavviate tramite il gestore dell’interfaccia

Una volta confermato che l’endpoint è obsoleto, aggiornatelo tramite il meccanismo che possiede l’interfaccia invece di modificare la configurazione attiva. Per un’interfaccia avviata da wg-quick è un giù e su, per un’unità systemd è un riavvio, e per un’interfaccia di proprietà di un gestore è una modifica fatta in quel gestore, perché una modifica a caldo viene sovrascritta alla successiva applicazione:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Poi confermate che l’ascoltatore sostitutivo e la sua identità siano il servizio che intendevate. Uno spostamento DNS non è un cambio di identità, quindi non dovrebbe mai essere l’occasione per fidarsi di una chiave che non avete verificato. Se l’interfaccia ora riporta il nuovo indirizzo e continua a non produrre alcuna stretta di mano, il guasto si è spostato sul nuovo percorso di rete o sull’ascoltatore, il che è un progresso e non lo stesso guasto due volte.

Prima la stretta di mano, poi il percorso dei dati

Separate i due esiti prima di scegliere una lista di controllo. Una stretta di mano che riesce sotto un’applicazione che fallisce è un problema del percorso dati: rotte, prefissi consentiti o DNS dentro il tunnel. Una stretta di mano che non avviene mai è un problema di raggiungibilità o di identità all’endpoint. Mescolare le due cose produce un rapporto che nessuno può riprodurre e un registro delle modifiche con tre modifiche non correlate.

Annotate il nome, l’indirizzo risolto, l’endpoint in uso e se la stretta di mano è stata completata. Quei quattro fatti rispondono alla domanda che questo guasto continua a porre, e trasformano l’occorrenza successiva in una verifica di due minuti. La manutenzione del nome e l’adozione del client restano lavori separati: correggere il record non esegue l’adozione, e riavviare l’interfaccia non ripara un record ancora sbagliato.