Un peer WireGuard irraggiungibile mentre un altro funziona: lista di controllo

Un peer WireGuard trasporta traffico e un secondo completa la stretta di mano ma non raggiunge mai nulla dietro il tunnel. Il peer che funziona vi dice che l’interfaccia, la porta UDP e la chiave del server sono probabilmente a posto. Non vi dice nulla sulle AllowedIPs del secondo peer, sul suo indirizzo sorgente interno né sulle regole di inoltro in mezzo. Seguite l’elenco in ordine e fermatevi al primo passo la cui condizione fallisce.

Passo 1: Annotate il percorso che il pacchetto dovrebbe seguire

Due client sullo stesso concentratore non si raggiungono automaticamente. In una progettazione a concentratore e raggi, il server riceve il pacchetto su wg0 e deve inoltrarlo di nuovo fuori da wg0 verso l’altro peer, il che richiede inoltro IP e una regola di inoltro. In una progettazione diretta peer a peer, ogni lato ha bisogno dell’endpoint dell’altro e dell’indirizzo del suo tunnel dentro le AllowedIPs. Decidete quale progettazione state diagnosticando prima di leggere qualsiasi configurazione.

Il percorso atteso vi dice anche dove guardare. Se il pacchetto deve attraversare il concentratore, il salto che fallisce è o le AllowedIPs del mittente, o l’inoltro del concentratore, o le AllowedIPs del destinatario. Se deve andare diretto, il concentratore è irrilevante e contano i campi endpoint su entrambi i peer.

Passo 2: Confrontate le AllowedIPs su entrambi i lati, non solo su uno

WireGuard usa le AllowedIPs sia come tabella di instradamento sia come elenco di accesso. In invio, l’indirizzo di destinazione viene cercato nelle AllowedIPs del peer per scegliere il tunnel; in ricezione, l’indirizzo sorgente interno deve cadere dentro le AllowedIPs del peer mittente, altrimenti il pacchetto viene scartato. Un intervallo mancante su uno dei due lati produce lo stesso sintomo: il trasporto funziona, il carico utile sparisce.

Leggete lo stato attivo invece del file, perché un ricaricamento può essere fallito in silenzio: sudo wg show wg0 allowed-ips. Sul server, la voce del peer che fallisce deve includere il suo indirizzo di tunnel, per esempio 10.90.0.3/32. Sul client, la voce del peer server deve includere la destinazione che state testando, che sia l’indirizzo di tunnel del concentratore o la sottorete remota. Gli intervalli sovrapposti rendono la ricerca ambigua e possono selezionare un peer che non volevate, quindi teneteli separati.

Passo 3: Verificate l’indirizzo sorgente interno

Un client che instrada 10.90.0.3 attraverso wg0 ma invia pacchetti dal suo indirizzo Wi-Fi verrà rifiutato dal destinatario, perché la sorgente non corrisponde alle AllowedIPs del peer. Verificate cosa seleziona realmente il kernel con ip route get 10.90.0.3 from 10.90.0.2, e verificate l’indirizzo assegnato all’interfaccia del tunnel con ip -brief addr show wg0.

Sull’host Linux che riceve, il filtraggio del percorso inverso è una seconda porta. Un rp_filter severo sull’interfaccia che possiede la rotta di ritorno può scartare traffico del tunnel il cui percorso di ritorno non corrisponde all’interfaccia da cui è arrivato. Verificate il valore effettivo prima di disattivarlo; in molte topologie la correzione giusta è una rotta, non un filtro allentato.

Passo 4: Esaminate l’inoltro del concentratore e il percorso di ritorno

Se il concentratore deve inoltrare tra peer, il kernel ha bisogno di net.ipv4.ip_forward=1, e il firewall deve accettare il flusso inoltrato: in ingresso su wg0, in uscita su wg0, dall’indirizzo di tunnel del mittente a quello del destinatario. Un guasto comune è una regola di ingresso che accetta UDP 51820 ma nessuna regola di inoltro], così la stretta di mano riesce e il carico utile muore. Elencate le regole effettive con sudo nft list ruleset o l’equivalente per il vostro gestore di firewall.

Poi verificate la risposta. L’host di destinazione deve avere una rotta di ritorno verso il mittente, sia attraverso il concentratore sia attraverso il proprio gateway. Se il concentratore fa anche NAT sulla sottorete del tunnel, verificate che la traduzione si applichi al flusso inoltrato e che la risposta raggiunga il concentratore prima che lo stato scada. Un guasto unidirezionale che sembra un problema di chiave spesso è solo questa rotta di ritorno.

Infine, separate la stretta di mano dai dati. Un peer che completa la stretta di mano ma si blocca sui trasferimenti grandi di solito ha un problema di MTU o MSS su quel percorso specifico, non un problema di AllowedIPs. Provate prima con un ping piccolo, poi con uno a dimensione piena, e confrontate i due peer.

Passo 5: Cambiate una sola cosa e mantenete intatto il peer che funziona

Fate una sola modifica sul percorso che fallisce e provate di nuovo entrambi i peer. Sostituire le AllowedIPs di ogni peer con 0.0.0.0/0 è il modo più rapido per rompere il peer che già funzionava, perché cambia la decisione di instradamento per tutto il traffico su quell’interfaccia. Modificate quella sola voce, ricaricate e rileggete lo stato attivo.

Annotate quale percorso ha funzionato, quale ha fallito e l’output esatto del comando per ciascuno. Quel confronto vale più di un rapporto generico che la VPN è rotta, ed è la prima cosa che la persona successiva chiederà.