Come funziona IPsec basato sulle rotte con un'interfaccia XFRM

IPsec basato sulle rotte affida alla tabella di routing una decisione che prima spettava ai selettori di policy. Su Linux, il pezzo che lo rende possibile è l'interfaccia XFRM: un dispositivo virtuale il cui traffico viene confrontato con lo stato IPsec tramite un identificatore di interfaccia anziché tramite un selettore. Crearne una richiede un solo comando e non dimostra nulla sull'esistenza di un tunnel. Il dispositivo è un gancio tra routing e policy di sicurezza, ed entrambi i lati di quel gancio devono essere configurati prima che qualcosa sia protetto.

Che cos'è il dispositivo e che cosa non è

Un'interfaccia XFRM è una maniglia di routing. I pacchetti instradati al suo interno vengono confrontati con policy XFRM che referenziano lo stesso identificatore di interfaccia, e se esistono una policy e uno stato vengono incapsulati. Senza di essi l'interfaccia esiste, i contatori restano fermi e il traffico finisce in un posto inutile.

Questa è la prima separazione diagnostica. Una rotta verso il dispositivo è un fatto di routing, uno stato installato è un fatto di sicurezza, e un contatore che sale sul dispositivo non è né l'uno né l'altro. Quando si dice che il tunnel è attivo perché l'interfaccia mostra UP, si stanno descrivendo i flag di collegamento di un dispositivo virtuale che non ha un proprio peer. Il flag significa che il dispositivo è stato creato e abilitato, niente di più.

Un altro confine: l'identificatore di interfaccia non è un nome. Due dispositivi con nomi simili e identificatori diversi non condividono stato, e una connessione configurata con l'identificatore sbagliato installa uno stato che nessuna rotta userà mai.

Costruiscine uno nell'ordine giusto

Inizia dal dispositivo esterno e da un numero che metterai anche nella configurazione del demone. L'esempio usa eth0 come interfaccia esterna e 42 come identificatore, indirizzi che dovresti sostituire con i tuoi.

Solleva il dispositivo, poi conferma l'identificatore registrato dal kernel prima di toccare la configurazione VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Ora configura la connessione in strongSwan con lo stesso identificatore, perché il demone deve installare policy e stati che vi fanno riferimento. Imposta i selettori di traffico locale e remoto sull'intervallo che intendi instradare, poi instrada quell'intervallo nel dispositivo. La configurazione del demone e la tabella di routing devono concordare sia sull'identificatore sia sulle destinazioni, e nessuna delle due fornisce l'altra.

Tieni IKE ed ESP fuori dalla rotta del tunnel

Una rotta predefinita che punta nel dispositivo XFRM cattura i pacchetti incapsulati e anche il traffico che trasportano. Il risultato è un ciclo: il gateway prova a inviare il proprio ESP attraverso il tunnel che ESP dovrebbe costruire.

La correzione è una rotta più specifica per l'indirizzo esterno del peer attraverso l'interfaccia fisica, che vince sulla predefinita perché corrisponde a più bit. Il routing basato su marcature fa lo stesso lavoro quando più tunnel condividono una tabella, e strongSwan documenta entrambi gli approcci per i deployment basati sulle rotte.

Qualunque cosa scegli, verifica che il pacchetto esterno esca senza incapsulamento. Un controllo rapido è fare ping all'indirizzo esterno del peer dopo che il tunnel è attivo; se fallisce mentre l'interfaccia è attiva, sospetta una cattura e non la raggiungibilità. Lo stesso ragionamento vale per la porta IKE, perché il traffico UDP del demone stesso non deve essere instradato nel dispositivo che sta cercando di stabilire.

Controlla i contatori in due punti prima di dare la colpa alla cifratura

I contatori dell'interfaccia e i contatori di stato misurano fasi diverse. I pacchetti instradati nel dispositivo incrementano il dispositivo anche quando nessuno stato corrisponde, mentre i contatori di stato si muovono solo per il traffico realmente incapsulato.

Leggi entrambi, poi leggi la visione del demone sull'associazione figlio:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Contatori del dispositivo che salgono con un output di stato vuoto significano che il routing funziona e la policy non corrisponde, di solito un errore di identificatore o selettore. Contatori di stato che salgono mentre il lato remoto non segnala nulla significano che i pacchetti escono ma non arrivano o falliscono l'autenticazione, il che punta al percorso o alla configurazione del peer. Un'associazione figlio elencata senza traffico è un problema di selettore a un'estremità, non un cifrario rotto.

Decidi chi installa le rotte

Due proprietari per una tabella di routing sono la solita fonte di flapping. Se il demone installa le rotte automaticamente, il tuo gestore di rete non deve installare anche una rotta predefinita attraverso lo stesso dispositivo, e una rotta manuale aggiunta da uno script di avvio verrà rimossa alla successiva riconfigurazione del demone.

Scegli un proprietario e scrivilo. Quando le rotte sono del demone, tieni lo script di avvio fuori dalla tabella e lascia che la definizione della connessione descriva i selettori di traffico. Quando sono del gestore di rete, disattiva l'installazione automatica e accetta che il demone non riparerà una rotta mancante alla riconnessione.

Le regole di inoltro e del firewall sono una decisione separata in più, perché un gateway che lascia passare il traffico di altri host ha bisogno di entrambe. IPsec basato sulle rotte rende quel traffico facile da esprimere con strumenti di routing ordinari; non rende lo strato di policy facoltativo.