WireGuard invia dati ma non riceve nulla indietro: quale lato?

I contatori di trasmissione che salgono mentre il contatore di ricezione resta a zero descrivono una direzione, non una diagnosi. La stessa lettura compare quando il peer non ha mai completato un handshake, quando la destinazione ha scelto il peer sbagliato, quando il lato remoto non ha una rotta di ritorno e quando un filtro scarta la risposta sulla via del ritorno. Ognuno di questi casi si ripara in un punto diverso.

Il confronto che accorcia il lavoro è tra una richiesta che non ha mai lasciato il tunnel e una risposta che non è mai tornata. Una cattura sull’interfaccia giusta decide tra le due.

I contatori descrivono il volume, non la direzione del guasto

I contatori di WireGuard registrano ciò che l’interfaccia ha consegnato al peer e ciò che ne ha ricevuto. Non dicono quale destinazione, quale peer o quale metà di uno scambio ha fallito. Il traffico di fondo rende i totali ancora meno informativi, perché alcuni byte possono essere messaggi di mantenimento o flussi non correlati. Leggeteli come un indizio che l’interfaccia è attiva, poi smettete di trattarli come prova.

Il primo fatto utile è se un handshake è aggiornato. Senza di esso non è stato cifrato nulla per questo peer e il contatore di ricezione non ha motivo di muoversi.

Scelta del peer o percorso della risposta: due spiegazioni

La prima spiegazione è che il pacchetto non ha mai raggiunto il peer previsto, perché la rotta puntava altrove o perché i prefissi consentiti del peer non coprivano la destinazione. La seconda è che il pacchetto è arrivato e la risposta non è potuta tornare, il che è un problema di routing all’estremità remota. La tabella li separa in base a ciò che osservereste in ogni punto.

Leggete la tabella dall’alto. Un handshake mancante vi manda a chiavi, endpoint e percorso esterno, perché non c’è ancora nient’altro da esaminare. Un handshake aggiornato con la richiesta visibile sul server sposta il problema nella direzione di ritorno, dove decide la tabella di routing della destinazione stessa. Una richiesta che non appare mai sul server è un problema di selezione, e i prefissi consentiti su entrambi i peer sono la prima cosa da confrontare.

Due di queste quattro righe si riparano sul client e due sul server. Sapere in quale coppia vi trovate è la maggior parte del lavoro.

Dove scompaiono le risposte

Una risposta lascia la destinazione, raggiunge l’interfaccia tunnel del server e viene cifrata per il peer i cui indirizzi consentiti corrispondono all’indirizzo interno del client. Se questa corrispondenza fallisce, la risposta viene scartata in silenzio, cosa che dal lato client sembra esattamente un guasto di rete. Se la risposta è cifrata e il filtro del client stesso la rifiuta, il sintomo è di nuovo identico. Entrambi i casi richiedono la cattura e non il contatore.

La forma più forte di questo errore è un server che inoltra pacchetti per il client ma non ha una rotta di ritorno verso l’intervallo interno del client. Accetta la richiesta, invia la risposta verso il proprio gateway predefinito e il tunnel non la vede mai. Una regola di traduzione ampia aggiunta al server nasconde quel guasto invece di riparare la rotta.

Provate una sola destinazione da un capo all’altro

Scegliete un’unica destinazione dentro l’intervallo del peer e provatela mentre l’handshake è dimostrabilmente aggiornato. I comandi seguenti leggono lo stato del peer, la rotta scelta e i due lati dello scambio. Eseguite la cattura sull’interfaccia che i pacchetti cifrati usano davvero.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

Una cattura che mostra la richiesta sull’interfaccia tunnel senza nulla che torni è una risposta lato server, e la tabella di routing della destinazione è il prossimo posto da guardare. Se non appare assolutamente nulla, il pacchetto ha preso un’altra strada, quindi la rotta locale è la sospetta. Uno scambio visibile in entrambe le catture senza progresso nell’applicazione sposta la domanda sulla dimensione dei pacchetti o su un filtro che le statistiche dell’interfaccia non mostrano mai. Tenete una destinazione e un client nella prova, perché una seconda variabile trasforma di nuovo la prova in un’impressione.

Se i nomi falliscono mentre un indirizzo consentito funziona, la risposta è nel DNS e non nel tunnel. Se solo i trasferimenti grandi si bloccano, esaminate la dimensione dei pacchetti separatamente.