IPsec ESP: cosa trasporta e come dimostrare che scorre

ESP trasporta il traffico in una VPN IPsec, e il suo runbook inizia con una regola: leggere l’associazione di sicurezza prima di modificare una politica. La maggior parte dei comportamenti inspiegati di ESP risale a un selettore che non corrispondeva, a una modalità presunta invece che letta, o a un contatore che nessuno ha controllato mentre veniva inviato un solo flusso. I tre passi seguenti stabiliscono cosa trasporta cosa, dimostrano che un flusso lo usa e lasciano un ripristino che non dipende dalla memoria. Ogni passo produce un’osservazione che vale la pena annotare.

Conosci i campi prima di leggerli

ESP mette un’intestazione davanti ai dati protetti e una coda dietro. L’intestazione porta un indice dei parametri di sicurezza che identifica quale associazione deve usare il destinatario, un numero di sequenza per rilevare le ripetizioni e, nella coda, un riempimento che mantiene il carico utile allineato per il cifrario. Il campo dell’intestazione successiva nella coda dice qual è il contenuto protetto, ed è così che il destinatario sa cosa ha decapsulato.

La modalità cambia cosa sta dentro quella protezione. In modalità tunnel il materiale protetto è un pacchetto IP interno completo, e una nuova intestazione esterna lo trasporta tra gli estremi. In modalità trasporto la protezione avvolge il carico utile dello strato superiore di un pacchetto esistente, quindi non c’è una seconda intestazione IP da aprire. Quale modalità sia in uso è un fatto di configurazione, non una questione di interpretazione. Leggila dalla voce di stato invece di dedurla da uno schema.

Nessuna delle due modalità nasconde l’indirizzamento esterno che deve consegnare il pacchetto. È una proprietà del progetto e non una mancanza, ed è per questo che un osservatore intermedio può ancora vedere quali due indirizzi stanno parlando anche quando il carico utile è opaco.

Primo passo: leggere lo stato, poi la politica

Le voci di stato contengono le chiavi e i contatori; le voci di politica contengono i selettori che decidono cosa può usarli. Su Linux entrambe sono visibili senza catturare pacchetti, e leggerle in quest’ordine tiene separate le due domande.

ip xfrm state
ip xfrm policy

Nell’output di stato, controllare l’origine e la destinazione dell’associazione, la modalità e se l’incapsulamento mostra porte UDP. Quelle porte significano che è in uso la traversata NAT, il che cambia cosa deve permettere un firewall intermedio, ma non quali selettori o chiavi valgano agli estremi.

Poi leggere i selettori nella politica. Un selettore che nomina un prefisso più stretto del traffico che stai provando è il motivo più comune per cui un tunnel che funziona sembra ignorare un flusso, e un selettore per il protocollo sbagliato produce lo stesso silenzio.

Gli strumenti dei fornitori stampano le stesse informazioni in una forma più comoda. ipsec statusall su strongSwan elenca le associazioni figlie, i loro selettori e i loro contatori di byte, il che è spesso più rapido che leggere l’output xfrm grezzo quando si sa già quale figlia guardare.

Secondo passo: dimostrare che un flusso muove i contatori

I contatori hanno senso solo se sai cosa avrebbe dovuto muoverli, quindi scegli un’origine e una destinazione che il selettore copra sicuramente e invia una richiesta innocua. Poi rileggi la stessa voce e confronta.

ip -s xfrm state
tcpdump -ni any esp

Due letture raccontano storie diverse. I pacchetti che aumentano sul lato in uscita ma mai su quello in entrata indicano un problema di inoltro o di percorso di ritorno, non di chiave, perché il pacchetto è stato incapsulato ed è partito. Se nessun contatore si muove, il traffico non ha mai corrisposto alla politica, e il selettore è il punto da guardare.

La cattura nello stesso passo conferma l’incapsulamento sul filo, compreso se i pacchetti esterni sono ESP o ESP incapsulato in UDP. Mostra anche gli indirizzi che hanno realmente trasportato il flusso, che a volte differiscono da quelli nella configurazione che stavi leggendo.

Terzo passo: cambiare una cosa sola e conservare un ripristino

Annota origine, destinazione, modalità, selettori e contatori dell’associazione prima di modificare qualcosa. Se un cambiamento peggiora le cose, è quella nota che ti permette di ripristinare lo stato precedente invece di ricostruire una configurazione funzionante da una supposizione. Quella nota costa un minuto e ne fa risparmiare un’ora più tardi. È anche l’unico artefatto che sopravvive alla persona che ha fatto il cambiamento.

Cambia un selettore o un parametro, ricaricalo e ripeti il secondo passo sullo stesso flusso. Eliminare un’associazione abbatte ogni flusso che la usa, quindi una modifica mirata e un ricaricamento della figlia sono quasi sempre migliori di uno svuotamento dello stato per vedere cosa succede.

Il ripristino di una modifica al selettore consiste nel ripristinare la politica precedente e ricaricarla, con l’avvertenza che il peer potrebbe aver bisogno di una modifica corrispondente se il selettore è negoziato e non locale. Annota quella dipendenza finché è fresca, perché una coppia ripristinata a metà è più difficile da ragionare di uno qualsiasi dei due stati finali.

Infine, mantieni onesto l’ambito. Un’associazione ESP che scorre dimostra che i due gateway proteggono e consegnano il segmento, e non dice nulla sul fatto che l’applicazione sopra autentichi i suoi utenti o cifri ciò che memorizza. Sono controlli separati con prove separate, e il runbook è finito solo quando la persona successiva può ripeterlo dalle note.