L'handshake di WireGuard funziona, ma la sottorete dell'ufficio non risponde

L'handshake si completa, wg show segnala un trasferimento recente, e l'indirizzo del tunnel del server risponde al ping. Un host sulla LAN del server no. Tre condizioni devono valere insieme: il client deve instradare il prefisso della LAN nel tunnel, il server deve inoltrare i pacchetti, e la risposta ha bisogno di un percorso di ritorno. Quando manca una delle tre, il sintomo è identico.

AllowedIPs è sia una lista di accesso sia una tabella di routing

Sul client, la lista AllowedIPs decide sia cosa può essere inviato a quel peer sia quali rotte installa WireGuard. Una voce di peer che elenca solo l'indirizzo del tunnel del server installa una sola rotta host, quindi le destinazioni della LAN non entrano mai nel tunnel. Aggiungere il prefisso della LAN è la prima cosa da verificare, ed è anche la modifica che più spesso manca dopo una configurazione copiata. Un peer esteso a una rotta predefinita è un altro progetto, e sposterà anche il traffico internet del client.

Tenere la rotta host e il prefisso della LAN come voci separate. Se l'ufficio ha due sottoreti, entrambe appartengono alla lista, e il secondo prefisso mancante produce un guasto che sembra selettivo anziché totale.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

L'inoltro e la traduzione appartengono al server

Il server ha bisogno dell'inoltro IP attivo, di una regola di inoltro che accetti il traffico proveniente dal tunnel e di una regola di traduzione verso la sua interfaccia LAN. È la traduzione che fa funzionare il progetto senza toccare ogni host della rete dell'ufficio. Le risposte tornano allora al server invece che a un indirizzo che la LAN non ha mai sentito. Senza di essa, ogni host ha bisogno di una rotta per la sottorete del tunnel e di una regola del firewall che la consenta, cosa raramente accettabile su una rete gestita da qualcun altro.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Le regole aggiunte a mano scompaiono al riavvio, quindi collegarle all'interfaccia con i comandi hook della configurazione del server. Un insieme di regole che sopravvive alla propria interfaccia è il modo in cui una macchina finisce per tradurre il traffico di un tunnel che non esiste più.

Quando la LAN si è spostata e la regola no

La sostituzione di un router che rinumera la sottorete dell'ufficio è la versione classica di questo guasto. Il tunnel resta attivo, l'handshake resta fresco, e nulla dietro il server risponde, perché la regola di traduzione nomina ancora l'indirizzo vecchio. Gli script di installazione spesso incorporano l'indirizzo LAN del server in una regola POSTROUTING, e dopo una rinumerazione quell'indirizzo non esiste su nessuna interfaccia. I pacchetti vengono allora riscritti verso una destinazione che non può rispondere.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Confrontare i due output. Una destinazione di traduzione che non compare nell'elenco delle interfacce è il bug, e correggerlo è una modifica di una riga una volta che la si è vista. La regola può risiedere in un'unità generata anziché nella configurazione di WireGuard, quindi ricaricare quell'unità dopo la modifica e confermare che il prossimo avvio non riscriva la modifica.

Due sedi dietro NAT hanno bisogno di un luogo d'incontro

Quando nessuno dei due lati accetta connessioni in entrata, la risposta pratica è un piccolo host con un indirizzo pubblico e due interfacce WireGuard. Ogni sede si collega verso l'esterno, l'host centrale elenca la LAN di ogni peer nella propria AllowedIPs, e l'inoltro trasporta i pacchetti tra i due tunnel. Nulla del firewall di nessuna delle due sedi deve cambiare, ed è per questo che questo progetto si diffonde facilmente.

Il routing tra le sedi conserva gli indirizzi di origine originali e quindi mantiene significativa la registrazione per host. La traduzione sull'host centrale è più semplice quando le due LAN si sovrappongono, al costo di perdere l'identità dell'origine nei log. Decidere quale proprietà conta prima di scegliere.

Separare i livelli con quattro controlli

Eseguire un controllo per livello invece di cambiare tre cose e sperare. Il primo mostra l'età dell'handshake e i contatori per ogni peer. Il secondo mostra se il client instrada davvero quella destinazione nel tunnel. Il terzo e il quarto dicono se la richiesta è arrivata e se una policy l'ha scartata dopo l'arrivo.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Una richiesta che arriva e non ottiene risposta punta al percorso della risposta o all'host della LAN. Una richiesta che non arriva mai punta a AllowedIPs o alla rotta del client. Questi due esiti richiedono correzioni diverse, e la cattura è ciò che li distingue.