VPN da sito a sito basata su rotte o su criteri: che cosa cambia

Entrambi i progetti proteggono lo stesso traffico con la stessa macchina IPsec, e differiscono in ciò che decide quale pacchetto entra nel tunnel. In una connessione basata su criteri lo fanno i selettori di traffico negoziati; in una basata su rotte lo fa una rotta che punta a un’interfaccia di tunnel. Confondere i due produce il solito thread di assistenza in cui il tunnel si dichiara stabilito mentre l’applicazione non raggiunge nulla. La distinzione conta soprattutto quando aggiungi una rete, esegui un protocollo di routing o esegui il debug di un percorso che esce in silenzio dall’uscita sbagliata.

Due modi per decidere cosa entra nel tunnel

Una VPN basata su criteri costruisce una politica di sicurezza che corrisponde ai prefissi di origine e destinazione, poi cifra ciò che rientra. Il peer deve negoziare selettori compatibili, quindi l’ambito effettivo finisce per essere l’intersezione di ciò che entrambe le parti hanno proposto. Nulla fuori da quell’intersezione è protetto, qualunque cosa dica la tabella di routing.

Una VPN basata su rotte crea un’interfaccia che rappresenta il tunnel e lascia che la tabella di routing vi invii il traffico. Il demone IKE installa comunque lo stato e la politica per interfaccia, ed è il dettaglio che si salta quando si decide che le rotte hanno sostituito la cifratura. Entrambi i progetti cifrano con IPsec; cambia solo il meccanismo di selezione.

Leggi il confronto qui sotto come un insieme di firme di guasto e non come un tabellone, perché nessuna colonna vince da sola.

Basata su criteri: il selettore è il contratto

I selettori si negoziano, non si configurano soltanto. Proponi 10.10.0.0/16 da un lato e 10.10.1.0/24 dall’altro, e l’associazione coprirà ciò su cui si è fermata la negoziazione mentre ogni altro host resta fuori.

Leggi lo stato installato invece del file di configurazione. Su un peer Linux le tabelle del kernel sono la verità di base, e mostrano ciò che è sopravvissuto alla negoziazione. Una politica che nomina i prefissi giusti senza stato corrispondente significa che l’associazione non è mai salita. Lo stato abbinato a una politica per il prefisso sbagliato è il problema opposto, e produce il tunnel che sembra sano mentre una sottorete non raggiunge nulla.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Confronta entrambi gli output con i prefissi che credi di proteggere. Quell’unico confronto risolve la maggior parte delle segnalazioni di un tunnel funzionante con un server irraggiungibile. Indica anche quale peer cambiare, perché la discrepanza di solito è visibile solo in una direzione.

Basata su rotte: l’interfaccia è il contratto

Un’interfaccia XFRM dà al tunnel un nome e un’identità, e il traffico la raggiunge perché la tabella di routing lo dice. Più prefissi remoti diventano allora un problema di routing invece che di selettore, e un protocollo di routing può annunciarli. È il guadagno reale, non la cifratura.

L’interfaccia non elimina la necessità di una politica. Il demone installa regole per interfaccia legate all’identità dell’interfaccia, quindi un pacchetto che arriva sull’interfaccia sbagliata fallisce comunque. Anche un indirizzo di origine che il peer non accetterà fallisce, persino con una rotta perfetta. Basata su rotte significa che la rotta decide l’ingresso, non che la politica è scomparsa.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Osserva i contatori dell’interfaccia una volta che la rotta è a posto. Una rotta che esiste mentre i contatori restano a zero significa che nulla viene associato al tunnel, il che di solito indica uno stato mancante più che una rotta mancante.

Dove i due progetti divergono davvero

Aggiungere una rete è il test più pulito di quale modello fa per te. Un progetto basato su rotte aggiunge una rotta e al massimo allarga il selettore una volta, mentre un progetto basato su criteri modifica coppie di prefissi su entrambi i peer e rinegozia. Due sottoreti stabili rendono quella modifica banale, e venti la trasformano in un progetto.

Nessuno dei modelli sostituisce un firewall, e i confronti di solito si fermano prima di questo punto. Un selettore ampio o una rotta ampia decidono cosa viene cifrato, non cosa è consentito.

Anche il comportamento dell’MTU differisce in pratica. L’incapsulamento riduce il carico utile e un’interfaccia basata su rotte porta il proprio MTU, quindi fissare l’MSS su entrambi i gateway evita il sintomo del buco nero in cui arrivano le risposte piccole e spariscono quelle grandi. I tunnel basati su criteri incontrano lo stesso muro dall’altro lato, perché un selettore non dice nulla sulla dimensione dei pacchetti. Imposta il limite di proposito invece di dare la colpa al peer.

Migrare senza perdere la rotta di ritorno

Registra le coppie di prefissi esistenti prima di cambiare qualcosa, poi sposta un percorso applicativo e osservalo da un capo all’altro. Un tunnel che si stabilisce non è un tunnel che inoltra, e la differenza appare nella direzione della risposta.

Quando i peer si connettono ma gli host della LAN no, esamina la rotta di ritorno e l’indirizzo di origine che userà l’host remoto. Un host con due interfacce può rispondere da quella sbagliata, e nessuna modifica del selettore lo ripara. Cattura il traffico su entrambe le estremità prima di modificare gli algoritmi.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Mantieni un percorso di gestione che non dipende dal tunnel mentre lavori. Il rollback è più facile quando l’accesso del gateway non viaggia sulla connessione che stai eseguendo il debug.