Handshake attivo, indirizzo sparito: tre stati di WireGuard

WireGuard può avere un handshake recente e nessun indirizzo nello stesso momento, e quello stato è coerente, non contraddittorio. L'handshake è un evento del peer, l'indirizzo appartiene all'interfaccia, e la rotta decide da quale collegamento ascendente esce un pacchetto. Tre livelli, tre proprietari, e ciascuno può fallire mentre gli altri due sembrano sani.

Leggerli come un solo stato è ciò che trasforma una diagnosi di due minuti in un intero pomeriggio di riavvii di servizi.

L'handshake è un evento del peer, non un evento di indirizzamento

L'handshake di WireGuard dimostra che il peer configurato ha risposto con una chiave valida e che le chiavi di sessione sono aggiornate. Non dice nulla sull'indirizzo locale dell'interfaccia, né se una rotta punti lì. L'indirizzo lo assegna un assistente o un gestore di rete, mentre la configurazione del protocollo nomina solo peer e chiavi. Confondere i due è il modo in cui un handshake sano viene letto come un tunnel funzionante.

Per questo wg show può riportare un handshake vecchio di secondi su un'interfaccia che non riesce ad accettare un solo pacchetto da un'applicazione.

Un gestore che ricrea l'interfaccia può far cadere l'indirizzo senza toccare la configurazione del peer, e l'handshake successivo riesce subito perché le chiavi non sono mai cambiate. La riga di log su un handshake riuscito è esatta e irrilevante per il guasto.

L'indirizzo dell'interfaccia ha il suo proprietario

Un indirizzo sul dispositivo tunnel può venire dalla riga Address di un assistente, da un client DHCP in esecuzione sull'interfaccia, o da un demone di gestione che lo crea al momento della connessione. Qualunque sia, quel componente possiede l'indirizzo e lo ripristinerà o no secondo la propria logica. Leggere l'indirizzo senza nominarne il proprietario ti lascia senza spiegazione del perché sia sparito.

Due proprietari su una sola interfaccia è il guasto classico. Avviare un assistente e un gestore di rete desktop sullo stesso dispositivo produce una corsa in cui uno rimuove ciò che l'altro ha appena configurato, e l'endpoint continua a rispondere per tutto il tempo.

Scegli un solo proprietario e lascia che l'altro strumento osservi invece di gestire. Vale la pena annotare quella decisione, perché il sintomo compare settimane dopo e sembra una perdita casuale di indirizzo.

La rotta sceglie un collegamento ascendente, non l'interfaccia

Una rotta interna che punta a wg0 decide che il traffico entra nel tunnel. Una decisione separata invia i pacchetti esterni cifrati verso il peer, e su un host con più collegamenti ascendenti quella decisione viene dalla tabella di inoltro e dalle regole di policy. Un roaming Wi-Fi può cambiare il percorso esterno senza toccare l'indirizzo interno.

Quindi un tunnel funzionante e un peer irraggiungibile sono stati compatibili, e lo stesso vale per un peer corretto e una rotta interna rotta. Le tre osservazioni vanno prese insieme, nello stesso momento, altrimenti il confronto non ha senso.

Confronta i tre stati in un solo passaggio

Tre comandi di sola lettura rispondono alle tre domande nell'ordine che isola il guasto più in fretta. Eseguili senza cambiare nulla tra l'uno e l'altro.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

Il primo mostra se l'interfaccia ha un indirizzo, e il secondo mostra quale dispositivo userebbe adesso una destinazione precisa. Il terzo riporta l'ora dell'ultimo handshake e i contatori di byte, ed è l'unico dei tre a descrivere il peer invece dell'host locale.

Leggi i contatori oltre al timestamp. Un handshake che si rinnova di continuo mentre il trasferimento resta piatto significa che il peer risponde ma non passa nulla di utile, il che punta al routing o a una ACL e non alle chiavi. Un timestamp che smette di avanzare mentre un indirizzo è presente punta invece a monte. Entrambe le letture vengono dalla stessa riga di output, e nessuna è visibile se controlli solo che un handshake esista.

Correggi lo stato preciso che è sbagliato, poi ricontrolla l'applicazione e non il tunnel. Un handshake recente è una prova sul peer, e la prova sul peer non è la prova che la prossima richiesta del browser troverà un indirizzo, una rotta e un collegamento ascendente funzionante. Il manuale di wg-quick dice esplicitamente quali di queste cose imposta l'assistente e quali appartengono al protocollo.