VPN de sitio a sitio basada en rutas frente a basada en políticas: en qué se diferencian

Ambos diseños protegen el mismo tráfico con la misma maquinaria IPsec, y difieren en qué decide qué paquete entra en el túnel. En una conexión basada en políticas lo hacen los selectores de tráfico negociados; en una basada en rutas lo hace una ruta que apunta a una interfaz de túnel. Confundir ambas produce el habitual hilo de soporte en el que el túnel se declara establecido mientras la aplicación no llega a nada. La distinción importa sobre todo cuando añades una red, ejecutas un protocolo de enrutamiento o depuras una ruta que sale en silencio por la salida equivocada.

Dos formas de decidir qué entra en el túnel

Una VPN basada en políticas crea una política de seguridad que coincide con los prefijos de origen y destino, y luego cifra lo que encaje. El par debe negociar selectores compatibles, así que el alcance efectivo acaba siendo la intersección de lo que propusieron ambos lados. Nada fuera de esa intersección queda protegido, diga lo que diga la tabla de enrutamiento.

Una VPN basada en rutas crea una interfaz que representa el túnel y deja que la tabla de enrutamiento envíe tráfico hacia ella. El demonio IKE sigue instalando el estado y la política por interfaz, que es el detalle que se omite cuando se decide que las rutas han sustituido al cifrado. Ambos diseños cifran con IPsec; solo cambia el mecanismo de selección.

Lee la comparación de abajo como un conjunto de firmas de fallo y no como un marcador, porque ninguna columna gana en abstracto.

Basada en políticas: el selector es el contrato

Los selectores se negocian, no solo se configuran. Propón 10.10.0.0/16 por un lado y 10.10.1.0/24 por el otro, y la asociación cubrirá lo que acordó la negociación mientras todos los demás hosts quedan fuera.

Lee el estado instalado en lugar del archivo de configuración. En un par Linux las propias tablas del kernel son la verdad básica, y muestran qué sobrevivió a la negociación. Una política que nombra los prefijos correctos sin estado coincidente significa que la asociación nunca se levantó. El estado junto a una política del prefijo equivocado es el problema opuesto, y produce el túnel que parece sano mientras una subred no llega a nada.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Compara ambas salidas con los prefijos que crees que proteges. Esa única comparación resuelve la mayoría de los informes de un túnel que funciona con un servidor inalcanzable. También señala qué par hay que cambiar, ya que el desajuste suele verse solo en una dirección.

Basada en rutas: la interfaz es el contrato

Una interfaz XFRM da al túnel un nombre y una identidad, y el tráfico llega a ella porque la tabla de enrutamiento lo dice. Varios prefijos remotos pasan entonces a ser un problema de enrutamiento en vez de un problema de selector, y un protocolo de enrutamiento puede anunciarlos. Esa es la ganancia real, no el cifrado.

La interfaz no elimina la necesidad de política. El demonio instala reglas por interfaz ligadas a la identidad de la interfaz, así que un paquete que llega a la interfaz equivocada sigue fallando. Una dirección de origen que el par no aceptará también falla, incluso con una ruta perfecta. Basada en rutas significa que la ruta decide la entrada, no que la política haya desaparecido.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Vigila los contadores de la interfaz una vez que la ruta esté puesta. Una ruta que existe mientras los contadores siguen a cero significa que nada se está encajando en el túnel, lo que suele apuntar a un estado ausente más que a una ruta ausente.

Dónde divergen realmente los dos diseños

Añadir una red es la prueba más limpia de qué modelo te conviene. Un diseño basado en rutas añade una ruta y como mucho ensancha el selector una vez, mientras que uno basado en políticas edita pares de prefijos en ambos pares y renegocia. Dos subredes estables hacen trivial esa edición, y veinte la convierten en un proyecto.

Ninguno de los modelos sustituye a un firewall, y las comparaciones suelen detenerse antes de este punto. Un selector amplio o una ruta amplia deciden qué se cifra, no qué se permite.

El comportamiento de MTU también difiere en la práctica. La encapsulación reduce la carga útil y una interfaz basada en rutas lleva su propia MTU, así que fijar el MSS en ambas pasarelas evita el síntoma de agujero negro en el que llegan las respuestas pequeñas y las grandes desaparecen. Los túneles basados en políticas chocan con el mismo muro desde el otro lado, porque un selector no dice nada del tamaño del paquete. Fija el valor a propósito en vez de culpar al par.

Migrar sin perder la ruta de vuelta

Registra los pares de prefijos existentes antes de cambiar nada, luego mueve una ruta de aplicación y obsérvala de extremo a extremo. Un túnel que se establece no es un túnel que reenvía, y la diferencia aparece en la dirección de respuesta.

Cuando los pares conectan pero los hosts de la LAN no pueden, inspecciona la ruta de respuesta y la dirección de origen que usará el host remoto. Un host con dos interfaces puede responder por la equivocada, y ningún cambio de selector repara eso. Captura tráfico en ambos extremos antes de editar algoritmos.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Mantén una ruta de gestión que no dependa del túnel mientras trabajas. Revertir es más fácil cuando el propio acceso de la pasarela no viaja sobre la conexión que estás depurando.