Perché tcpdump mostra il testo in chiaro di IPsec solo in una direzione

Esegui tcpdump sull'interfaccia esterna di un gateway IPsec Linux e vedi due cose insieme: frame ESP in ingresso e, subito dopo, i pacchetti interni decifrati. In uscita appare solo ESP. La conclusione naturale è che le risposte non vengono inviate o che IPsec cifra una direzione e dimentica l'altra. Nessuna delle due è vera.

Quello che stai guardando è un punto di cattura. Il kernel trasforma i pacchetti in uscita prima che il percorso di trasmissione del dispositivo li consegni al socket dei pacchetti, quindi il socket non vede mai la forma interna in uscita. In ingresso, il pacchetto viene catturato prima come ESP e la copia decapsulata diventa visibile quando rientra nello stack. Stesso traffico, due finestre di osservazione diverse.

Il punto di cattura decide cosa vedi

Su un'interfaccia normale, un socket AF_PACKET si trova vicino allo strato del dispositivo. I pacchetti che lasciano l'host passano prima per l'elaborazione di uscita di IPsec, che trasforma un segmento TCP interno in un datagramma ESP o UDP-4500, e solo dopo raggiungono quello strato. I pacchetti in arrivo vengono copiati nel socket mentre escono dal cavo, ancora cifrati, e il risultato decifrato diventa visibile più tardi quando lo stack lo consegna localmente o lo inoltra.

Questo ordine spiega completamente l'asimmetria. Non è una prova su direzione, policy o comportamento dell'applicazione, e trattarlo come tale manda le persone a inseguire una risposta che era stata inviata correttamente per tutto il tempo. È uno dei pochi enigmi di rete in cui lo strumento, non la rete, crea l'anomalia.

Fai corrispondere il filtro allo strato che intendi

Un'espressione come tcp port 443 seleziona una connessione TCP interna. In uscita, quella connessione è già diventata ESP quando il socket viene interrogato, quindi il filtro non corrisponde a nulla. Se vuoi contare il traffico protetto, filtra sulla forma esterna: protocollo 50 per ESP grezzo, o porta UDP 4500 quando è in gioco la traversata NAT. Entrambi i filtri producono un conteggio di pacchetti confrontabile tra i due peer, che di solito è il motivo per contare. Nessuno dei due ti dice se la richiesta interna ha ricevuto risposta.

Non trattare un conteggio UDP 4500 come un conteggio di pacchetti ESP. IKE usa quella porta anche per i keepalive NAT-T e per lo scambio incapsulato, quindi il numero include traffico che non sono i dati che volevi misurare. Lo scambio IKE iniziale su UDP 500 richiede un filtro proprio se è questa la domanda. Un numero che mescola traffico di controllo e dati rende anche qualsiasi stima di banda errata di un margine sconosciuto. Conteggi separati rispondono a domande separate.

Scrivi il filtro accanto alla domanda a cui risponde. «Quanto ESP ha lasciato la macchina» e «la richiesta web ha lasciato la macchina» sono misure diverse con filtri diversi, e una sola cattura non può risolvere entrambe. Senza quella nota, due persone confronteranno numeri che non contavano mai la stessa cosa.

Osserva prima della trasformazione, non dopo

Se devi vedere il testo in chiaro in uscita, sposta il punto di osservazione più indietro, prima dell'elaborazione di uscita di IPsec. NFLOG ti dà un hook di Netfilter dove una regola può copiare pacchetti selezionati verso un socket in spazio utente, che tcpdump può leggere. La guida al dump del traffico di strongSwan documenta questo approccio proprio per questo motivo.

La corrispondenza della policy limita la regola al traffico che sta per entrare in un tunnel. -m policy --pol ipsec --dir out è ciò che rende la regola specifica invece di registrare ogni pacchetto che la macchina invia. Poi leggi il gruppo di log con una cattura limitata: un piccolo numero di snapshot e un limite di dimensione impediscono alla diagnostica di diventare un archivio di traffico. Una cattura limitata è anche più facile da consegnare a un revisore senza trascinare carichi inutili. Decidi il numero prima di iniziare, non dopo aver visto quanto è arrivato.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Scegli l'hook adatto al flusso. OUTPUT copre il traffico generato dal gateway stesso; il transito da un client LAN passa invece per la catena FORWARD, e una regola su OUTPUT non lo vedrà mai. L'indirizzo e la porta sopra sono segnaposto per una destinazione di test approvata.

Cosa dimostra l'osservazione

NFLOG è una destinazione di registrazione, non una decisione di accettazione. Un pacchetto che appare lì mostra che ha raggiunto l'hook e corrispondeva alla regola. Non mostra che un filtro successivo lo abbia permesso, che il dispositivo lo abbia trasmesso o che il peer abbia ricevuto qualcosa.

Un log vuoto è altrettanto ambiguo. Controlla il contatore di pacchetti della regola, conferma la direzione, conferma che il flusso corrispondeva davvero a una policy IPsec e conferma la destinazione. Solo un contatore concordante su entrambi i peer trasforma un'osservazione in conclusione. Poi confronta i contatori dell'associazione di sicurezza su entrambi i peer per lo stesso tentativo controllato, perché i contatori SA sono il registro autorevole di ciò che è stato protetto e inviato.

Un'altra trappola: «testo in chiaro» in questo contesto significa fuori dallo strato di cifratura IPsec. Una sessione HTTPS interna ha comunque il proprio TLS. Catturare il pacchetto decapsulato non decifra il TLS dell'applicazione, e vedere HTTP leggibile lì significa che l'applicazione non usava affatto HTTPS.

Pulisci e confronta entrambi i capi

Rimuovi la regola esatta che hai inserito, in base al suo proprietario, appena l'osservazione è finita. Lasciare in piedi una regola di registrazione costa CPU su ogni pacchetto corrispondente e crea silenziosamente un problema di conservazione dei dati. Eliminala ripetendo la regola con -D invece di svuotare una catena che non possiedi.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Se la distribuzione usa IPsec in spazio utente, un'interfaccia XFRM o l'offload hardware, i punti di osservazione si spostano e questa ricetta potrebbe non applicarsi affatto. Con libipsec, il punto documentato per osservare il traffico interno è il dispositivo TUN. Individua prima il percorso, poi scegli il punto che risponde alla domanda, e aspettati che le due direzioni appaiano diverse solo quando guardi il lato sbagliato della trasformazione.