Por qué tcpdump muestra texto plano de IPsec solo en una dirección

Ejecuta tcpdump en la interfaz exterior de una puerta de enlace IPsec de Linux y ve dos cosas a la vez: tramas ESP entrantes y, justo después, los paquetes internos descifrados. A la salida solo aparece ESP. La conclusión natural es que no se envían respuestas o que IPsec cifra una dirección y olvida la otra. Ninguna de las dos es cierta.

Lo que está viendo es un punto de captura. El núcleo transforma los paquetes salientes antes de que la ruta de transmisión del dispositivo los entregue al socket de paquetes, así que el socket nunca ve la forma interna al salir. A la entrada, el paquete se captura primero como ESP y la copia desencapsulada se hace visible cuando vuelve a entrar en la pila. El mismo tráfico, dos ventanas de observación distintas.

El punto de captura decide lo que ve

En una interfaz normal, un socket AF_PACKET se sitúa cerca de la capa del dispositivo. Los paquetes que salen del host pasan primero por el procesamiento de salida de IPsec, que convierte un segmento TCP interno en un datagrama ESP o UDP-4500, y solo después llegan a esa capa. Los paquetes que llegan se copian al socket a medida que salen del cable, todavía cifrados, y el resultado descifrado se hace visible más tarde cuando la pila lo entrega localmente o lo reenvía.

Ese orden explica la asimetría por completo. No es prueba sobre la dirección, la política ni el comportamiento de la aplicación, y tratarlo como tal envía a la gente a perseguir una respuesta que se envió correctamente todo el tiempo. Es uno de los pocos rompecabezas de red en los que el instrumento, y no la red, crea la anomalía.

Ajuste el filtro a la capa que quiere

Una expresión como tcp port 443 selecciona una conexión TCP interna. A la salida, esa conexión ya se ha convertido en ESP cuando se consulta el socket, así que el filtro no coincide con nada. Si quiere contar tráfico protegido, filtre por la forma externa: protocolo 50 para ESP en bruto o puerto UDP 4500 cuando hay cruce de NAT. Ambos filtros producen un recuento de paquetes que se puede comparar entre los dos pares, que suele ser el motivo para contar. Ninguno de los dos le dice si la petición interna recibió respuesta.

No trate un recuento de UDP 4500 como un recuento de paquetes ESP. IKE también usa ese puerto para los keepalives de NAT-T y para el intercambio encapsulado, así que el número incluye tráfico que no son los datos que quería medir. El intercambio IKE inicial en UDP 500 necesita su propio filtro si esa es la pregunta. Un número que mezcla tráfico de control con datos también hace que cualquier estimación de ancho de banda sea errónea en un margen desconocido. Recuentos separados responden preguntas separadas.

Escriba el filtro junto a la pregunta que responde. «Cuánto ESP salió de la caja» y «salió la petición web de la caja» son mediciones distintas con filtros distintos, y una sola captura no puede resolver ambas. Sin esa nota, dos personas compararán números que nunca contaban lo mismo.

Observe antes de la transformación, no después

Si necesita ver el texto plano saliente, mueva el punto de observación más atrás, antes del procesamiento de salida de IPsec. NFLOG le da un gancho de Netfilter donde una regla puede copiar paquetes seleccionados a un socket de espacio de usuario, que tcpdump puede leer. La guía de volcado de tráfico de strongSwan documenta este enfoque exactamente por ese motivo.

La coincidencia de política limita la regla al tráfico que está a punto de entrar en un túnel. -m policy --pol ipsec --dir out es lo que hace específica la regla en lugar de registrar cada paquete que envía la caja. Después lea el grupo de registro con una captura acotada: un recuento pequeño de instantáneas y un límite de tamaño evitan que el diagnóstico se convierta en un archivo de tráfico. Una captura acotada también es más fácil de entregar a un revisor sin arrastrar carga inútil. Decida el recuento antes de empezar, no después de ver cuánto ha llegado.

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'

Elija el gancho que corresponda al flujo. OUTPUT cubre el tráfico que genera la propia puerta de enlace; el tránsito de un cliente LAN pasa por la cadena FORWARD y una regla en OUTPUT nunca lo verá. La dirección y el puerto de arriba son marcadores de posición para un destino de prueba aprobado.

Qué demuestra la observación

NFLOG es un destino de registro, no una decisión de aceptación. Un paquete que aparece ahí muestra que llegó al gancho y coincidió con la regla. No muestra que un filtro posterior lo permitiera, que el dispositivo lo transmitiera o que el par recibiera algo.

Un registro vacío es igual de ambiguo. Compruebe el contador de paquetes de la regla, confirme la dirección, confirme que el flujo coincidió realmente con una política IPsec y confirme el destino. Solo un contador coincidente en ambos pares convierte una observación en conclusión. Después compare los contadores de la asociación de seguridad en ambos pares para el mismo intento controlado, porque los contadores SA son el registro autoritativo de lo que se protegió y se envió.

Otra trampa: «texto plano» en este contexto significa fuera de la capa de cifrado de IPsec. Una sesión HTTPS interna sigue teniendo su propio TLS. Capturar el paquete desencapsulado no descifra el TLS de la aplicación, y ver HTTP legible ahí significa que la aplicación nunca usó HTTPS.

Limpie y compare ambos extremos

Elimine la regla exacta que insertó, por su propietario, en cuanto termine la observación. Dejar una regla de registro en su sitio cuesta CPU en cada paquete coincidente y crea en silencio un problema de retención de datos. Bórrela repitiendo la regla con -D en lugar de vaciar una cadena que no le pertenece.

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

Si el despliegue usa IPsec en espacio de usuario, una interfaz XFRM o descarga por hardware, los puntos de observación se mueven y esta receta puede no aplicarse en absoluto. Con libipsec, el lugar documentado para observar el tráfico interno es el dispositivo TUN. Identifique primero la ruta, luego elija el punto que responde a la pregunta, y espere que las dos direcciones se vean distintas solo cuando mira el lado equivocado de la transformación.