Il peer WireGuard esce dalla WAN sbagliata: cinque controlli in ordine

Due uplink, un gateway e un peer WireGuard il cui traffico continua a comparire sulla linea di riserva. L’handshake resta sano per tutto il tempo. Ecco perché il sintomo è facile da leggere male come guasto di WireGuard invece che come guasto di routing.

Esegui i controlli qui sotto in ordine. Ognuno ha una condizione di arresto, e saltare avanti di solito produce una risposta sbagliata e sicura di sé.

Separa l’handshake dal flusso inoltrato

Lo scambio cifrato con il peer ha una rotta di endpoint verso l’indirizzo pubblico del server. Il traffico client inoltrato ha una destinazione diversa e può essere selezionato da marcature o regole di policy. Sono due decisioni di routing che condividono un’interfaccia. Trattarne una come prova sull’altra è il primo errore.

Fermati appena ti accorgi di ragionare a partire dall’handshake. È prova solo sul percorso verso l’endpoint.

Leggi la regola di policy, non la tabella predefinita

Una tabella predefinita mostra cosa succede quando nessuna regola di policy corrisponde. Su un gateway che instrada per sorgente, marcatura o destinazione, la regola decisiva vive altrove. La tabella semplice può sembrare del tutto ragionevole mentre la scelta reale viene fatta sopra di essa.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Leggi le regole di policy e le tabelle a cui puntano. Poi conferma quale regola corrisponde al tuo flusso di test. Una regola che fa riferimento a un’interfaccia che non porta più l’uplink previsto è un riscontro, non un dettaglio. La ricerca di rotta alla fine mostra la risposta molto più in fretta che leggere una tabella e indovinare.

Controlla la marcatura e la traduzione insieme

Il routing per policy si basa su una marcatura di pacchetto impostata prima nella catena. Se la regola di marcatura manca il tuo traffico, il flusso ricade nella tabella principale ed esce da qualunque predefinito vi sia. I pacchetti inoltrati spesso saltano catene scritte per il traffico generato localmente.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

La traduzione deve concordare con l’uplink che porta il flusso. Una regola che traduce verso l’indirizzo primario mentre il pacchetto esce dalla linea di riserva produce risposte indirizzate a un’interfaccia che il flusso non ha mai usato. Controlla la condizione di interfaccia della regola di traduzione stessa. Una regola incondizionata funziona finché non si usa il secondo uplink, poi fallisce in un modo che sembra intermittente.

Osserva quale interfaccia porta la risposta

Cattura su entrambi gli uplink mentre gira una richiesta. Annota quale interfaccia porta la richiesta e quale la risposta. I percorsi asimmetrici sono molto più facili da vedere che da prevedere.

Se la risposta arriva dall’uplink sbagliato, il problema si è spostato da WireGuard al tracciamento delle connessioni o alla traduzione. Nessuna modifica alla configurazione del peer lo risolverà.

Cambia una cosa sola con una via di ritorno

Mantieni l’accesso da console o fuori banda prima di modificare regole di policy su un gateway. Fai un solo cambiamento, prova la stessa destinazione autorizzata, poi riconnettiti e conferma che l’handshake usa ancora il percorso di endpoint previsto. Aggiungi un test numerico sulla seconda famiglia di indirizzi, perché una policy solo v4 lascia lo stesso errore disponibile.

Annota quale uplink ha usato ogni flusso. Quel registro trasforma il prossimo rapporto in un controllo di due minuti invece di un intero pomeriggio. le note di WireGuard su spazi dei nomi e routing descrivono come separare deliberatamente il percorso di endpoint dal traffico incanalato nel tunnel, cosa di solito più pulita che copiare un aggiramento con rotta predefinita.