Cómo funciona IPsec basado en rutas con una interfaz XFRM

IPsec basado en rutas entrega a la tabla de enrutamiento una decisión que antes tomaban los selectores de política. En Linux, la pieza que lo hace posible es la interfaz XFRM: un dispositivo virtual cuyo tráfico se empareja con el estado de IPsec mediante un identificador de interfaz en lugar de un selector. Crear una requiere un solo comando y no demuestra nada sobre si existe un túnel. El dispositivo es un gancho entre el enrutamiento y la política de seguridad, y ambos lados de ese gancho deben configurarse antes de que algo quede protegido.

Qué es el dispositivo y qué no es

Una interfaz XFRM es un asa de enrutamiento. Los paquetes enrutados hacia ella se emparejan con políticas XFRM que hacen referencia al mismo identificador de interfaz, y si existen una política y un estado, se encapsulan. Sin ellos, la interfaz existe, los contadores no se mueven y el tráfico va a un lugar inútil.

Esa es la primera división diagnóstica. Una ruta hacia el dispositivo es un hecho de enrutamiento, un estado instalado es un hecho de seguridad, y un contador que sube en el dispositivo no es ni una cosa ni la otra. Cuando la gente dice que el túnel está arriba porque la interfaz muestra UP, está describiendo los indicadores de enlace de un dispositivo virtual que no tiene par propio. El indicador solo significa que el dispositivo se creó y se habilitó, nada más.

Otra frontera: el identificador de interfaz no es un nombre. Dos dispositivos con nombres parecidos e identificadores distintos no comparten estado, y una conexión configurada con el identificador equivocado instala un estado que ninguna ruta usará jamás.

Construya uno en el orden correcto

Empiece por el dispositivo exterior y un número que también pondrá en la configuración del demonio. El ejemplo usa eth0 como interfaz exterior y 42 como identificador, direcciones que debería sustituir por las suyas.

Suba el dispositivo y luego confirme el identificador que el núcleo registró antes de tocar la configuración de VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Ahora configure la conexión en strongSwan con el mismo identificador, ya que el demonio debe instalar políticas y estados que lo referencian. Fije los selectores de tráfico local y remoto al rango que pretende enrutar y después enrute ese rango hacia el dispositivo. La configuración del demonio y la tabla de enrutamiento deben coincidir tanto en el identificador como en los destinos, y ninguna de las dos aporta la otra.

Mantenga IKE y ESP fuera de la ruta del túnel

Una ruta por defecto apuntada hacia el dispositivo XFRM captura los paquetes encapsulados y también el tráfico que transportan. El resultado es un bucle: la puerta de enlace intenta enviar su propio ESP por el túnel que se supone que ESP debe construir.

La solución es una ruta más específica para la dirección exterior del par a través de la interfaz física, que gana a la ruta por defecto porque coincide en más bits. El enrutamiento basado en marcas hace el mismo trabajo cuando varios túneles comparten una tabla, y strongSwan documenta ambos enfoques para despliegues basados en rutas.

Elija lo que elija, verifique que el paquete exterior sale sin encapsular. Una comprobación rápida es hacer ping a la dirección exterior del par una vez que el túnel está arriba; si falla mientras la interfaz está arriba, sospeche de captura y no de alcanzabilidad. El mismo razonamiento se aplica al puerto IKE, porque el tráfico UDP del propio demonio no debe enrutarse hacia el dispositivo que intenta establecer.

Compruebe los contadores en dos sitios antes de culpar al cifrado

Los contadores de interfaz y los contadores de estado miden etapas distintas. Los paquetes enrutados hacia el dispositivo incrementan el dispositivo incluso cuando ningún estado coincide, mientras que los contadores de estado solo se mueven para el tráfico que realmente se encapsuló.

Lea ambos y luego lea la visión del demonio sobre la asociación hija:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Contadores del dispositivo que suben con una salida de estado vacía significan que el enrutamiento funciona y la política no coincide, normalmente un error de identificador o de selector. Contadores de estado que suben mientras el lado remoto no informa de nada significan que los paquetes salen pero no llegan o fallan la autenticación, lo que apunta al camino o a la configuración del par. Una asociación hija listada con cero tráfico es un problema de selector en un extremo, no un cifrador roto.

Decida quién instala las rutas

Dos dueños para una tabla de enrutamiento son la fuente habitual de oscilación. Si el demonio instala rutas automáticamente, su gestor de red no debe instalar también una ruta por defecto por el mismo dispositivo, y una ruta manual añadida por un script de arranque se eliminará la próxima vez que el demonio se reconfigure.

Elija un dueño y anótelo. Cuando el demonio posee las rutas, mantenga el script de arranque fuera de la tabla y deje que la definición de la conexión describa los selectores de tráfico. Cuando las posee el gestor de red, desactive la instalación automática y acepte que el demonio no reparará una ruta que falte al reconectar.

Las reglas de reenvío y de cortafuegos son una decisión aparte por encima, porque una puerta de enlace que deja pasar el tráfico de otros equipos necesita ambas. IPsec basado en rutas hace que ese tráfico sea fácil de expresar con herramientas de enrutamiento corrientes; no hace que la capa de política sea opcional.