WireGuard non mostra alcun handshake recente: cosa controllare per primo

Un campo dell’ultimo handshake vuoto di solito significa che l’interfaccia non ha completato alcun handshake da quando è stata attivata, il che dice meno sulla configurazione di quanto sembri. WireGuard resta silenzioso finché un pacchetto non deve uscire dall’interfaccia, quindi un peer inattivo senza nulla da inviare riporta esattamente questo. Stabilisci se qualcosa è stato realmente offerto prima di ispezionare le chiavi.

Il test è un pacchetto consentito verso una destinazione che il peer dovrebbe trasportare. Tutto il resto su quella schermata di stato descrive intenzione, non attività.

Un’interfaccia inattiva non ha nulla da segnalare

WireGuard esegue gli handshake con pigrizia: il primo pacchetto che necessita del tunnel avvia lo scambio e l’interfaccia tace fino ad allora. Un peer configurato e mai usato mostra un handshake vuoto, zero byte ricevuti e un intervallo crescente dall’ultimo. Questo stato è sano per un client inattivo e allarmante solo se ti aspettavi che il traffico fosse già fluito. Controlla anche i contatori di trasferimento, perché separano nulla-inviato da tentato-e-fallito.

Se i contatori restano a zero su entrambi i lati, il problema è a monte del tunnel. Nulla ha raggiunto l’interfaccia per attivare qualcosa.

Attiva il traffico che il peer può trasportare

Scegli un indirizzo all’interno dei prefissi consentiti del peer, sulla macchina locale, e conferma che la tabella di routing lo invierebbe attraverso l’interfaccia. Una destinazione fuori da quei prefissi produce una normale richiesta instradata senza alcun coinvolgimento di WireGuard. Usa un servizio che risponde rapidamente, come un ping o una breve connessione TCP, così che il tentativo abbia un inizio e una fine visibili. Poi rileggi la riga dell’handshake invece di fissare lo schermo e aspettare.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

La query di rotta conta più del ping. Se nomina l’interfaccia fisica, il pacchetto non è mai entrato nel tunnel e l’handshake vuoto è una risposta di routing, non crittografica. Ripara la rotta prima di eseguire il debug del peer.

Confronta la coppia di chiavi e l’endpoint

Una volta che il traffico viene davvero offerto, l’identità è il controllo successivo. La chiave privata locale deve corrispondere alla chiave pubblica autorizzata dall’altro lato, la chiave pubblica remota configurata deve identificare il peer previsto e qualsiasi chiave precondivisa deve corrispondere su entrambe le estremità. Una sola differenza di carattere in una chiave base64 produce un peer che sembra configurato e non completa mai uno scambio. Confronta con il registro di provisioning invece di rigenerare le chiavi, perché una nuova chiave invalida ogni peer che si fidava della vecchia.

L’endpoint richiede lo stesso esame: nome host, indirizzo, porta UDP e la famiglia usata per raggiungerlo. Un indirizzo obsoleto o la porta sbagliata producono silenzio invece di un messaggio.

Tieni d’occhio il percorso UDP esterno

L’handshake viaggia come UDP verso l’endpoint, quindi il percorso esterno deve trasportarlo. I comandi qui sotto verificano se esiste un listener, se lo stack locale ha emesso il datagramma e quale endpoint è configurato. Esegui la cattura mentre attivi il traffico, non prima.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

Una cattura che mostra l’inizio senza risposta indica l’esterno della macchina, perché l’estremità remota non ascolta, è filtrata o è indirizzata male. Una cattura che non mostra nulla significa che il pacchetto non è mai partito, il che ti riporta alla rotta e a qualsiasi marcatura socket in gioco. Quando amministri entrambe le estremità, correla il tentativo per timestamp con una cattura ristretta sul server invece che con una generale. Un test di porta TCP non dimostra nulla qui, perché il protocollo è solo UDP.

Appena compare un handshake, prova un’applicazione attraverso il tunnel, perché uno scambio completato dimostra identità e raggiungibilità, non una capacità utilizzabile o un DNS corretto. Conserva l’output di stato prima e dopo la modifica, e la differenza diventa la tua prova.