Due peer WireGuard condividono un intervallo: quale riceve il pacchetto

Due peer elencano intervalli che si toccano, e il traffico raggiunge quello sbagliato. Nulla è corrotto: WireGuard sceglie un peer confrontando la destinazione con gli intervalli configurati, e vince la corrispondenza più specifica. Prima di allargare qualsiasi cosa, decidi quale peer dovrebbe possedere quale prefisso.

Il prefisso più lungo vince dentro WireGuard

Ogni voce di peer porta un insieme di prefissi di destinazione. Quando un pacchetto viene instradato verso l’interfaccia, l’implementazione cerca la voce con il prefisso corrispondente più specifico — la stessa regola che applica una tabella di routing. Un /24 batte quindi un /16 che lo contiene, e il peer più stretto riceve il traffico.

Le configurazioni road-warrior lo usano deliberatamente. Un peer possiede un intervallo ampio per un sito, e singoli host vengono ritagliati con voci /32 che appartengono ad altri peer. Lo schema funziona perché i ritagli sono più specifici, non per l’ordine.

Annota la proprietà come tabella di prefisso e peer. Se due voci descrivono lo stesso prefisso, la configurazione non esprime più un’intenzione, esprime una corsa.

Il sistema operativo sceglie prima l’interfaccia

WireGuard sceglie solo tra i peer di una singola interfaccia. Quale interfaccia riceve il pacchetto si decide prima, dalla tabella di routing dell’host, e una seconda rotta predefinita o una rotta obsoleta può inviare il traffico dove la lista dei peer non lo vede mai. Per questo una diagnosi a livello di peer può essere corretta e comunque non spiegare il guasto. Controlla la rotta verso la destinazione prima di leggere la configurazione del peer, perché una rotta che punta all’interfaccia fisica aggira tutta la questione.

Lo strumento di solito installa quelle rotte dagli intervalli dei peer, il che significa che una modifica alla lista di un peer può silenziosamente reindirizzare traffico che prima apparteneva a un altro. Modificare un peer è quindi un cambio di routing travestito. Esamina entrambi insieme, o ne riparerai uno e romperai l’altro.

I pacchetti in ingresso vengono controllati per origine

La lista degli intervalli svolge un doppio compito. Per il traffico in uscita sceglie un peer per destinazione, e per il traffico in ingresso autorizza un indirizzo di origine. Un pacchetto che arriva da un indirizzo fuori dagli intervalli di quel peer viene scartato prima che qualsiasi firewall lo veda.

Questa asimmetria è facile da trascurare quando si legge un lato della configurazione. Un peer che può raggiungere una sottorete non è per questo autorizzato a inviare da quella sottorete, e le due direzioni sono imposte da controlli diversi.

Una proprietà dell’origine ristretta trasforma questo in un vantaggio. Dai a ogni peer un /32 per il proprio indirizzo e il firewall a valle avrà un’origine affidabile da confrontare, invece di un intervallo di gruppo che qualsiasi membro potrebbe rivendicare.

Gli intervalli duplicati non sono failover

Assegnare lo stesso prefisso a due peer non crea un bilanciatore di carico né un percorso di riserva. Non c’è controllo di salute né affinità di sessione: la voce vincente è decisa dall’ordine interno dell’implementazione, che non è un contratto su cui progettare. Se hai bisogno di uscite alternative, esprimile dove la selezione è definita. Una politica di routing, una metrica o una coppia di prefissi distinti con un proprietario documentato ciascuno producono un comportamento che puoi prevedere e testare.

Allargare un intervallo per correggere un guasto non correlato è l’altro errore comune. Allontana il traffico dal peer che funzionava, e il nuovo sintomo arriva prima che il vecchio sia capito.

Verifica la selezione prima di modificare

Tre comandi rispondono alle tre domande in ordine. Il primo elenca gli intervalli che ogni peer rivendica. Il secondo mostra quale interfaccia l’host userebbe per una destinazione. Il terzo mostra lo stato live dei peer dopo che il traffico è fluito.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Eseguili prima e dopo una modifica e confronta. Se l’output della rotta è cambiato ma il traffico arriva ancora al peer sbagliato, le liste dei prefissi si sovrappongono in un modo che non hai ancora annotato. Se l’output della rotta non è cambiato, la configurazione del peer non era mai ciò che veniva consultato.

Registra nel ticket la destinazione, l’interfaccia scelta e il peer scelto. È quella terna che rende una sovrapposizione verificabile in seguito, ed è molto più utile di uno screenshot della configurazione.