Monitorare un’interfaccia di tunnel IPsec: che cosa leggere

Un progetto IPsec basato su route installa un’interfaccia virtuale, e quell’interfaccia offre al monitoraggio un oggetto concreto: qualcosa con un nome, dei contatori e una route collegata. Non è di per sé un segnale di salute. L’interfaccia può esistere mentre non è installata alcuna associazione utilizzabile, e un’associazione può essere sana mentre nessuna route le manda il traffico interessante. È leggere quattro stati insieme che trasforma un conteggio di pacchetti in una diagnosi.

Esaminali in ordine e fermati al primo che fallisce.

Che cosa aggiunge l’interfaccia al quadro

Con un progetto basato su policy, la selezione vive nella tabella delle policy IPsec e il kernel decide che cosa viene protetto in base ai traffic selector. Un progetto basato su route aggiunge un’interfaccia e una route, così tcpdump e i contatori dell’interfaccia vedono un solo confine invece di un insieme di selettori. È un guadagno reale per la diagnosi e per i protocolli di routing che hanno bisogno di un’interfaccia su cui fare peering.

Il guadagno è amministrativo, non crittografico. L’interfaccia riporta il traffico che trasporta e non dice nulla sulla utilizzabilità attuale della protezione del peer.

Leggere i quattro stati prima di dare la colpa al tunnel

Comincia dall’interfaccia e dalla route, poi dall’associazione, poi dall’applicazione. Ognuna ha il proprio comando e la propria firma di guasto. Un risultato pulito a un livello non è un risultato pulito al livello successivo. Esegui tutti e quattro prima di trarre una conclusione. Una riga verde raramente risolve qualcosa.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Un’interfaccia con un contatore che sale ma senza una voce di stato corrispondente descrive traffico che entra in un percorso dove nulla lo protegge, il che è peggio di un tunnel semplicemente inattivo. Una voce di stato senza una route che selezioni l’interfaccia significa che la crittografia è pronta e inutilizzata.

Il test applicativo arriva per ultimo e di proposito: un ping riuscito verso il lato opposto del tunnel non dimostra che il servizio dietro accetti connessioni.

Confrontare i contatori interni con quelli esterni

I contatori sull’interfaccia di tunnel misurano il traffico interno; i contatori e le catture sull’interfaccia fisica mostrano lo scambio incapsulato. I due non coincideranno uno a uno, perché l’incapsulamento aggiunge intestazioni, le ritrasmissioni duplicano alcuni pacchetti e la contabilità dell’implementazione segue regole proprie. Aspettati un rapporto, non un’uguaglianza.

La posizione della cattura decide anche quali dati privati raccogli, quindi usa filtri ristretti e un indirizzo di test innocuo invece di una cattura completa del traffico di produzione.

Se i conteggi interni salgono e quelli esterni no, il passaggio mancante è di solito la route o la policy che manda i pacchetti nel tunnel, non il tunnel stesso.

Osservarlo attraverso rekey e failover

Osserva un rekey, un evento di rilevamento del peer morto e un failover di collegamento mentre tieni d’occhio gli stessi quattro stati. Un’interfaccia può restare presente durante un rekey che non si completa mai, e un failover può lasciare una voce di stato che punta a un indirizzo del peer non più raggiungibile.

Avvisa sul percorso di servizio da cui dipendi davvero, con lo stato dell’associazione come contesto, invece che su un singolo indicatore su o giù. Mantieni il nome dell’interfaccia, l’indirizzo del peer e la route nel payload dell’avviso, così chi risponde non deve ricostruirli.

strongSwan documenta il proprio modello di interfaccia XFRM, e altre piattaforme nominano e implementano diversamente l’oggetto equivalente. Leggi il confronto basato su route per il dispositivo che hai davanti prima di trasferire ipotesi da un’altra implementazione. Un modello di monitoraggio adatto ai contatori di un fornitore ingannerà silenziosamente su un altro.