Gruppi di peer WireGuard all'hub: proprietà dell'origine più policy

Un hub che esegue WireGuard può tenere separati i gruppi di peer senza un'interfaccia o una tabella di routing separata per gruppo. Due meccanismi fanno il lavoro, e confonderli è la ragione abituale per cui una policy sembra corretta e non fa nulla. Uno strato decide chi può rivendicare un indirizzo di origine. L'altro decide dove a quel pacchetto è consentito andare.

Due compiti, tenuti separati

Lo strato tunnel risponde a una domanda stretta: la chiave di questo peer ha autorizzato questo indirizzo di origine interno. Lo strato di inoltro risponde a una più ampia: questo pacchetto può uscire verso quella destinazione. Nessuno dei due risponde alla domanda dell'altro, e nessuno dei due da solo è una policy di accesso completa.

Questa separazione è il motivo per cui un peer può essere autenticato, indirizzato correttamente e comunque non riuscire a raggiungere un host che non dovrebbe raggiungere. Spiega anche il contrario: una regola del firewall che permette tutto non dimostra nulla su chi può rivendicare quale indirizzo.

Progettate i due strati insieme, poi provate entrambi. Una configurazione corretta su uno strato e non provata sull'altro fallisce aperta o chiusa a seconda del valore predefinito.

Date a ogni peer solo il suo indirizzo

I peer con più host tentano di farvi concedere l'intera gamma del gruppo sul lato server. Quel permesso è una rivendicazione di indirizzo di origine, quindi un client compromesso o configurato male può presentare qualsiasi indirizzo della gamma e il tunnel lo accetterà. Assegnate una /32 per peer per il suo indirizzo interno. Impostate le gamme di gruppo solo sui client, dove descrivono quali destinazioni quel client può raggiungere e non quali origini può usare.

Il firewall confronta quindi un'origine di cui può fidarsi. Una regola scritta per la gamma del gruppo resta un raggruppamento utile, e diventa significativa solo quando nessun singolo peer può rivendicare un indirizzo che appartiene a un altro membro.

Scrivete la policy di inoltro che separa i gruppi

Il traffico interessante qui entra ed esce dalla stessa interfaccia tunnel, quindi attraversa il percorso di inoltro e non il percorso di input dell'host. Le regole appartengono alla catena di inoltro esistente del gestore del firewall che possiede l'host, e sono frammenti, non un insieme di regole completo.

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

Le prime due regole consentono il traffico all'interno di ogni gruppo. L'ultima blocca tutto il resto che attraversa quell'interfaccia, ed è ciò che produce l'isolamento tra i gruppi. Aggiungete regole esplicite per l'altra famiglia di indirizzi se vi servono, perché un drop scritto per IPv4 non autorizza né descrive il comportamento di IPv6.

L'ordine decide se la policy si applica

L'ordine delle regole conta più del frammento stesso. Una regola generica che accetta le connessioni stabilite e posta prima di queste voci lascia continuare un vecchio flusso tra gruppi, quindi l'isolamento vale solo per le connessioni nuove. Decidete quale di questi due esiti volete prima di ricaricare.

Un verdetto di accettazione non è sempre definitivo tra catene sullo stesso hook. Se un'altra catena base viene eseguita dopo, la policy effettiva è la combinazione, quindi ispezionate i contatori invece del file che avete modificato. I contatori sono la prova più economica disponibile. Una regola senza conteggio dei pacchetti non corrisponde, e una regola che corrisponde mentre una catena successiva accetta vi dice che il drop è nel posto sbagliato.

Provate la matrice, non il numero di file

Costruite una piccola matrice di risultati attesi e controllate ogni cella. Dal gruppo A al gruppo A dovrebbe funzionare, dal gruppo B al gruppo B dovrebbe funzionare, e da A a B non dovrebbe, in entrambe le direzioni e per entrambe le famiglie di indirizzi se le supportate.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

Le prime due mostrano cosa è configurato. Il ping da un membro del gruppo sbagliato mostra cosa accade davvero. L'elenco conntrack mostra se un flusso più vecchio è ancora accettato, ed è così che un cambiamento di isolamento fallisce silenziosamente nel diventare effettivo.

I servizi host sull'hub e l'accesso a una LAN dietro di esso sono percorsi separati con policy separata. Annotate quali di essi la matrice copre, perché un test che controlla solo il traffico tra peer non dice nulla su nessuno dei due.