Por que tcpdump mostra texto plano de IPsec só nunha dirección

Executa tcpdump na interface exterior dunha pasarela IPsec de Linux e ve dúas cousas á vez: tramas ESP entrantes e, xusto despois, os paquetes internos descifrados. Na saída só aparece ESP. A conclusión natural é que as respostas non se envían ou que IPsec cifra unha dirección e esquece a outra. Ningunha das dúas é certa.

O que está a ver é un punto de captura. O núcleo transforma os paquetes saíntes antes de que o camiño de transmisión do dispositivo os entregue ao socket de paquetes, así que o socket nunca ve a forma interna ao saír. Na entrada, o paquete captúrase primeiro como ESP e a copia desencapsulada faise visible cando volve entrar na pila. O mesmo tráfico, dúas ventás de observación distintas.

O punto de captura decide o que ve

Nunha interface normal, un socket AF_PACKET sitúase preto da capa do dispositivo. Os paquetes que saen do host pasan primeiro polo procesamento de saída de IPsec, que converte un segmento TCP interno nun datagrama ESP ou UDP-4500, e só despois chegan a esa capa. Os paquetes que chegan cópianse ao socket mentres saen do cable, aínda cifrados, e o resultado descifrado faise visible máis tarde cando a pila o entrega localmente ou o reenvía.

Esa orde explica a asimetría por completo. Non é proba sobre a dirección, a política nin o comportamento da aplicación, e tratalo como tal fai que a xente persiga unha resposta que se enviou correctamente todo o tempo. É un dos poucos enigmas de rede nos que o instrumento, e non a rede, crea a anomalía.

Axuste o filtro á capa que quere

Unha expresión como tcp port 443 selecciona unha conexión TCP interna. Na saída, esa conexión xa se converteu en ESP cando se consulta o socket, así que o filtro non coincide con nada. Se quere contar tráfico protexido, filtre pola forma externa: protocolo 50 para ESP en bruto ou porto UDP 4500 cando hai travesía de NAT. Ambos os filtros producen un reconto de paquetes que se pode comparar entre os dous pares, que adoita ser o motivo para contar. Ningún dos dous lle di se a petición interna recibiu resposta.

Non trate un reconto de UDP 4500 como un reconto de paquetes ESP. IKE tamén usa ese porto para os keepalives de NAT-T e para o intercambio encapsulado, así que o número inclúe tráfico que non son os datos que quería medir. O intercambio IKE inicial en UDP 500 necesita o seu propio filtro se esa é a pregunta. Un número que mestura tráfico de control con datos tamén fai que calquera estimación de ancho de banda sexa incorrecta nunha marxe descoñecida. Recontos separados responden preguntas separadas.

Escriba o filtro xunto á pregunta que responde. «Canto ESP saíu da caixa» e «saíu a petición web da caixa» son medicións distintas con filtros distintos, e unha soa captura non pode resolver as dúas. Sen esa nota, dúas persoas compararán números que nunca contaban o mesmo.

Observe antes da transformación, non despois

Se necesita ver o texto plano saínte, mova o punto de observación máis atrás, antes do procesamento de saída de IPsec. NFLOG dálle un gancho de Netfilter onde unha regra pode copiar paquetes seleccionados a un socket de espazo de usuario, que tcpdump pode ler. A guía de volcado de tráfico de strongSwan documenta este enfoque exactamente por ese motivo.

A coincidencia de política limita a regra ao tráfico que está a piques de entrar nun túnel. -m policy --pol ipsec --dir out é o que fai específica a regra en lugar de rexistrar cada paquete que envía a caixa. Despois lea o grupo de rexistro cunha captura limitada: un reconto pequeno de instantáneas e un límite de tamaño evitan que o diagnóstico se converta nun arquivo de tráfico. Unha captura limitada tamén é máis fácil de entregar a un revisor sen arrastrar carga inútil. Decida o reconto antes de comezar, non despois de ver canto chegou.

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'

Escolla o gancho que corresponda ao fluxo. OUTPUT cobre o tráfico que xera a propia pasarela; o tránsito dun cliente LAN pasa pola cadea FORWARD e unha regra en OUTPUT nunca o verá. O enderezo e o porto de arriba son marcadores de posición para un destino de proba aprobado.

Que demostra a observación

NFLOG é un destino de rexistro, non unha decisión de aceptación. Un paquete que aparece alí mostra que chegou ao gancho e coincidiu coa regra. Non mostra que un filtro posterior o permitise, que o dispositivo o transmitise ou que o par recibise algo.

Un rexistro baleiro é igual de ambiguo. Comprobe o contador de paquetes da regra, confirme a dirección, confirme que o fluxo coincidiu realmente cunha política IPsec e confirme o destino. Só un contador coincidente en ambos os pares converte unha observación en conclusión. Despois compare os contadores da asociación de seguridade en ambos os pares para o mesmo intento controlado, porque os contadores SA son o rexistro autoritativo do que se protexeu e se enviou.

Outra trampa: «texto plano» neste contexto significa fóra da capa de cifrado de IPsec. Unha sesión HTTPS interna segue tendo o seu propio TLS. Capturar o paquete desencapsulado non descifra o TLS da aplicación, e ver HTTP lexible alí significa que a aplicación nunca usou HTTPS.

Limpe e compare os dous extremos

Elimine a regra exacta que inseriu, polo seu propietario, en canto remate a observación. Deixar unha regra de rexistro no seu sitio custa CPU en cada paquete coincidente e crea silenciosamente un problema de retención de datos. Bórrea repetindo a regra con -D no canto de baleirar unha cadea que non lle pertence.

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 o despregue usa IPsec en espazo de usuario, unha interface XFRM ou descarga por hardware, os puntos de observación móvense e esta receita pode non aplicarse en absoluto. Con libipsec, o lugar documentado para observar o tráfico interno é o dispositivo TUN. Identifique primeiro o camiño, despois escolla o punto que responde a pregunta, e espere que as dúas direccións parezan distintas só cando mira o lado equivocado da transformación.