Ciclo della rotta predefinita di WireGuard: trovare il percorso dell’estremità

L’interfaccia si alza, la configurazione del peer sembra corretta e nessun handshake si completa mai. Aggiungere una rotta predefinita attraverso il tunnel è il passaggio che spesso lo causa: la stessa tabella di routing decide ora dove devono andare i pacchetti cifrati del tunnel, e la risposta che produce torna dentro il tunnel. Niente può trasportare il pacchetto esterno che trasporterebbe quello interno, quindi la connessione si blocca prima di iniziare. La riparazione è piccola, ma ha un ordine, e la verifica conta più della modifica.

Conferma il ciclo prima di cambiare una rotta

Leggi l’indirizzo attuale dell’estremità del peer e poi chiedi allo stack di routing dove andrebbe un pacchetto verso quell’indirizzo. Se la risposta nomina l’interfaccia del tunnel, il ciclo è confermato e non serve ulteriore diagnosi. Salva entrambi gli output nel registro delle modifiche prima di toccare qualsiasi cosa, perché il confronto dopo la riparazione sono gli stessi due comandi. Un ciclo non è sottile una volta visto; la difficoltà è che l’interfaccia sembra sana mentre accade.

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

Includi le regole di policy in quella cattura. Una rotta predefinita che sembra corretta nella tabella principale può comunque perdere contro una regola che seleziona una tabella diversa per il traffico marcato o non marcato, e il ciclo riapparirà con una tabella di routing che sembra a posto.

Leggi il percorso dell’estremità, non il percorso del tunnel

Il percorso dell’estremità è la rotta che i datagrammi cifrati prendono verso l’indirizzo pubblico del peer, e deve restare fuori dal tunnel finché il tunnel esiste. Il percorso del tunnel è tutto ciò che al peer è consentito trasportare. Questi due percorsi condividono una tabella di routing, ed è esattamente per questo che una singola voce catch-all può farli collassare l’uno nell’altro. Separare il traffico del tunnel dal trasporto proprio del tunnel è l’intero problema di progettazione, e ogni strumento supportato lo risolve da qualche parte in modo leggermente diverso.

Controlla separatamente entrambe le famiglie di indirizzi se l’interfaccia porta entrambe. Un’esclusione IPv4 funzionante non dice nulla sulla raggiungibilità dell’estremità IPv6, e una configurazione mista può sembrare funzionare finché non viene selezionato l’indirizzo IPv6 del peer.

Ripristina il percorso dell’estremità con un solo cambiamento coerente

Esistono due approcci supportati, e mescolarli è il modo in cui una configurazione funzionante diventa imprevedibile. Il primo è lasciare che lo strumento che possiede l’interfaccia gestisca l’intero tunnel: wg-quick ha una gestione dedicata per un intervallo di peer predefinito che installa una tabella separata, regole di policy e un socket mark, il che tiene i pacchetti esterni fuori dal tunnel. Lascia intatta quella macchineria invece di riprodurne metà a mano. Una configurazione che mescola una rotta predefinita aggiunta a mano con un gestore che già installa marcature e regole tende a fallire dopo la riconnessione, quando il gestore riscrive lo stato che il passaggio manuale dava per scontato.

Il secondo è un progetto manuale in cui l’estremità riceve una rotta host esplicita attraverso il gateway fisico. Aggiungi quella rotta prima della predefinita, sostituisci invece di aggiungere perché una voce obsoleta non possa vincere, e conferma la ricerca dopo.

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

Verifica, poi conserva una via di ritorno

Un timestamp di handshake che avanza è la prima prova, ed è più forte di un’interfaccia che semplicemente esiste. Seguilo con un test applicativo attraverso il tunnel, poi abbassa l’interfaccia di proposito e conferma che l’host torna a uno stato utilizzabile invece di mantenere una rotta predefinita che punta al nulla. Quell’ultimo passaggio è quello che le persone saltano, ed è quello che decide se un riavvio lascerà la macchina bloccata.

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

Prima di tutto questo, salva lo stato di routing attuale e assicurati che esista una via d’ingresso che non dipenda dal tunnel: una console, un indirizzo di gestione fuori banda o un collega sul posto. Una macchina remota che perde la rotta predefinita non è recuperabile attraverso la connessione che ha appena perso, e il passaggio più sicuro del runbook è quello fatto prima del primo comando.