IPsec ESP: qué transporta y cómo demostrar que fluye

ESP transporta el tráfico en una VPN IPsec, y su runbook empieza con una regla: lea la asociación de seguridad antes de cambiar una política. La mayor parte del comportamiento inexplicado de ESP se remonta a un selector que no coincidía, un modo que se supuso en lugar de leerse, o un contador que nadie comprobó mientras se enviaba un único flujo. Los tres pasos siguientes establecen qué transporta qué, demuestran que un flujo lo usa y dejan una reversión que no depende de la memoria. Cada paso produce una observación que merece anotarse.

Conozca los campos antes de leerlos

ESP coloca una cabecera delante de los datos protegidos y un tráiler detrás. La cabecera lleva un índice de parámetros de seguridad que identifica qué asociación debe usar el receptor, un número de secuencia para detectar repeticiones y un relleno en el tráiler que mantiene la carga útil alineada para el cifrado. El campo de cabecera siguiente del tráiler dice cuál es el contenido protegido, y así es como el receptor sabe qué ha desencapsulado.

El modo cambia qué hay dentro de esa protección. En modo túnel el material protegido es un paquete IP interno completo, y una cabecera externa nueva lo transporta entre los extremos. En modo transporte la protección envuelve la carga útil de la capa superior de un paquete existente, así que no hay una segunda cabecera IP que abrir. Qué modo se usa es un hecho de configuración, no una cuestión de interpretación. Léalo en la entrada de estado en lugar de inferirlo de un diagrama.

Ninguno de los dos modos oculta el direccionamiento externo que debe entregar el paquete. Eso es una propiedad del diseño y no una carencia, y por eso un observador intermedio todavía puede ver qué dos direcciones hablan incluso cuando la carga útil es opaca.

Paso uno: lea el estado y luego la política

Las entradas de estado guardan las claves y los contadores; las entradas de política guardan los selectores que deciden qué puede usarlas. En Linux ambas son visibles sin capturar paquetes, y leerlas en ese orden mantiene separadas las dos preguntas.

ip xfrm state
ip xfrm policy

En la salida de estado, compruebe el origen y el destino de la asociación, el modo y si la encapsulación muestra puertos UDP. Esos puertos significan que se usa la travesía de NAT, lo que cambia qué debe permitir un cortafuegos intermedio, pero no qué selectores o claves se aplican en los extremos.

Después lea los selectores de la política. Un selector que nombra un prefijo más estrecho que el tráfico que prueba es el motivo más habitual de que un túnel que funciona parezca ignorar un flujo, y un selector para el protocolo equivocado produce el mismo silencio.

Las herramientas de los fabricantes muestran la misma información en una forma más cómoda. ipsec statusall en strongSwan lista las asociaciones hijas, sus selectores y sus contadores de bytes, lo que a menudo es más rápido que leer la salida xfrm en bruto cuando ya sabe qué hija mirar.

Paso dos: demuestre que un flujo mueve los contadores

Los contadores solo tienen sentido si sabe qué debería haberlos movido, así que elija un origen y un destino que el selector cubra con seguridad y envíe una petición inofensiva. Luego vuelva a leer la misma entrada y compare.

ip -s xfrm state
tcpdump -ni any esp

Dos lecturas cuentan historias distintas. Los paquetes que aumentan en el lado de salida pero nunca en el de entrada apuntan a un problema de reenvío o de camino de vuelta, no a un problema de clave, porque el paquete se encapsuló y se fue. Que no se mueva ningún contador significa que el tráfico nunca coincidió con la política, y el selector es donde hay que mirar.

La captura del mismo paso confirma la encapsulación en el cable, incluido si los paquetes externos son ESP o ESP encapsulado en UDP. También le muestra las direcciones que realmente transportaron el flujo, que a veces difieren de las de la configuración que estaba leyendo.

Paso tres: cambie una cosa y conserve una reversión

Anote el origen, el destino, el modo, los selectores y los contadores de la asociación antes de editar nada. Si un cambio empeora las cosas, ese registro es lo que le permite restaurar el estado anterior en lugar de reconstruir una configuración que funciona a partir de una conjetura. Ese registro cuesta un minuto de escribir y ahorra una hora más tarde. También es el único artefacto que sobrevive a la persona que hizo el cambio.

Cambie un selector o un parámetro, vuelva a cargarlo y repita el paso dos sobre el mismo flujo. Borrar una asociación derriba todos los flujos que la usan, así que una edición dirigida y una recarga de la hija casi siempre son mejores que vaciar el estado para ver qué pasa.

La reversión de una edición de selector es restaurar la política anterior y volver a cargarla, con la advertencia de que el par puede necesitar un cambio correspondiente si el selector se negocia en lugar de ser local. Anote esa dependencia mientras está fresca, porque un par medio restaurado es más difícil de razonar que cualquiera de los dos estados finales.

Por último, mantenga el alcance honesto. Una asociación ESP que fluye demuestra que las dos pasarelas protegen y entregan el segmento, y no dice nada sobre si la aplicación de arriba autentica a sus usuarios o cifra lo que almacena. Son controles separados con pruebas separadas, y el runbook solo termina cuando la siguiente persona puede repetirlo a partir de las notas.