IPsec dentro de IPsec: qué direcciones debe transportar el túnel exterior

El IPsec anidado es más fácil de razonar cuando las dos capas terminan en máquinas distintas. Cuatro puertas de enlace, dos túneles y una sola pregunta que decide si el diseño funciona: ¿qué ve realmente el túnel exterior cuando el interior ha terminado con el paquete? Responde eso y los selectores, las rutas y el orden de resolución de problemas siguen. Equivócate y pasarás un día depurando un túnel que técnicamente está activo.

El modelo de cuatro puertas de enlace

Las puertas de enlace exteriores A y B construyen el primer túnel entre los dos sitios. Detrás de A está la puerta de enlace interna C con dirección de tránsito 10.60.0.2; detrás de B está la puerta de enlace interna D con dirección de tránsito 10.70.0.2. Las redes de aplicaciones viven detrás de C y D, y cada dirección del ejemplo es deliberadamente no solapada.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Dividir las capas entre cuatro hosts significa que cada máquina impone una frontera. Un solo host que ejecuta ambas capas debe conciliar dos conjuntos de políticas, dos tablas de rutas y dos modos de fallo en una máquina, lo cual es posible y mucho más difícil de observar.

Cada capa elimina solo su propia protección

C cifra un paquete de aplicación para D. El resultado se direcciona de C a D, y eso es lo que llega a A. Todo lo que está aguas abajo depende de esa reescritura.

A lo cifra de nuevo para B. B descifra la capa exterior, ve un paquete de C a D y lo reenvía todavía cifrado. D elimina la protección interior y entrega el paquete de aplicación.

Así que A y B ven los extremos internos y sus metadatos, pero no son las partes que descifran la carga útil de la aplicación. Eso es una propiedad real del diseño y no una afirmación de que C, D o los hosts de aplicaciones sean de confianza.

Los selectores exteriores nombran las puertas de enlace internas

Aquí es donde fallan la mayoría de estas construcciones. Para un túnel exterior basado en políticas, los selectores que negocies deben contener las direcciones que A y B manejan realmente: 10.60.0.2/32 y 10.70.0.2/32, en el orden local y remoto correcto.

Poner las subredes finales de las aplicaciones en los selectores exteriores no funciona, porque cuando un paquete llega a A, la encapsulación interior ya ha reescrito lo que A debe proteger. La política exterior entonces no coincidiría con nada, y el túnel subiría sin transportar datos.

Tampoco restrinjas el permiso exterior a UDP 500. La conexión interior tiene su propia ruta de datos, que usa ESP o encapsulación UDP según lo que haya negociado, y la política exterior debe permitir ese protocolo.

Comprueba el resultado con swanctl --list-sas en cada puerta de enlace y confirma que las asociaciones de seguridad hijas informan las direcciones que pretendías, no las que supusiste. Si la lista muestra las subredes de aplicaciones, la política exterior se escribió para la capa equivocada. Corrige los selectores antes de depurar el enrutamiento, porque el enrutamiento parecerá correcto y los contadores no se moverán.

El reenvío y la trampa de la recursión

Los selectores no sustituyen al enrutamiento. A y B deben reenviar tráfico entre C y D en ambos sentidos, lo que significa reenvío IP habilitado, rutas que apunten al túnel y una ruta de retorno que exista en el otro lado.

Si el túnel exterior usa interfaces XFRM, las rutas seleccionan la interfaz mientras las políticas negociadas siguen limitando lo que transporta. Una interfaz no amplía lo protegido; solo cambia cómo el núcleo recoge el paquete.

La trampa es la recursión. La ruta de A hacia el extremo exterior de B debe seguir la red subyacente, no el túnel que A está estableciendo, o la encapsulación intenta viajar dentro de sí misma y la conexión nunca se completa.

Inspecciona la traducción antes de añadir capas

Mira cualquier NAT de origen en A y B antes de ajustar cualquier otra cosa. Una regla que reescriba la dirección de C antes de que se aplique la política IPsec puede romper los selectores acordados, y también puede cambiar lo que D recibe en el otro lado.

El enmascaramiento amplio no se vuelve más seguro por tener dos capas. Oculta qué dirección ve el extremo remoto, que es exactamente la información que necesitas cuando el túnel está activo y la aplicación no.

Si una regla NAT es realmente necesaria, anota con qué dirección cree cada lado que habla. Esa sola línea resuelve la mayoría de las discusiones sobre si la culpa es del túnel o de la traducción. También le dice al siguiente ingeniero dónde mirar cuando la regla se elimine un año después. Un ping no hará nada de eso.

Demuestra fail-closed y comprueba la MTU

Que una ruta desaparezca no es por sí solo una política fail-closed. Otra tabla, una ruta por defecto o una regla de política pueden proporcionar silenciosamente una alternativa, y la única forma de saberlo es bajar el túnel exterior y observar qué hace el tráfico de aplicaciones. Hazlo a propósito, en una ventana, en lugar de descubrirlo por accidente.

Prueba tres estados: túnel exterior caído, túnel interior caído y recuperación después de que ambos vuelvan. Usa contadores de políticas en cada puerta de enlace, porque dos sesiones IKE establecidas solo demuestran que la negociación del plano de control tuvo éxito.

Presupuesta las dos encapsulaciones. Un IKE que funciona es un resultado de paquetes pequeños, y los paquetes de aplicación de tamaño completo aún pueden fallar cuando se añaden dos cabeceras; prueba con un tamaño de carga útil conocido en la ruta real en lugar de suponer que los números cuadran. La aritmética es fácil; la ruta no.