VPN anidado: ¿qué túnel transporta la conexión exterior?

Dos clientes VPN en marcha a la vez no producen un túnel anidado; producen dos túneles y una discusión sobre el enrutamiento. Un túnel anidado existe cuando la conexión del cliente interior con su propio servidor está ella misma transportada por el túnel exterior, y eso es un montaje que se construye a propósito. Si sale bien, el servidor interior ve la dirección del servidor exterior; si sale mal, un cliente se reconecta en silencio alrededor del otro. Tres condiciones deciden si el anidamiento es real o accidental.

Tres condiciones deciden el anidamiento

La primera es qué extremo necesita qué ruta. Nombra la dirección del servidor interior, nombra la del servidor exterior y afirma explícitamente que solo se llega al servidor interior por el túnel exterior. Todo lo demás se deriva de esa frase, incluido qué rutas van en qué tabla.

La segunda es si puedes ver la ruta en cada capa. Si no puedes preguntar al núcleo qué ruta usaría un destino concreto, estás deduciendo la cadena a partir de una IP de salida final, y esa es justo la prueba que no puede distinguir un anidamiento de una casualidad.

La tercera es qué ocurre cuando cae el túnel exterior. El túnel interior puede detenerse con él, reconectarse por la red ordinaria o quedarse bloqueado hasta que vuelva la ruta exterior, y las tres son políticas defendibles. No son la misma política, y el comportamiento por defecto de la mayoría de los clientes es el segundo. Un cliente que reconecta su extremo por la red física mientras muestra una conexión sana es la forma más común de que una cadena buscada se convierta en silencio en dos túneles sin relación.

Condición uno: qué extremo necesita qué ruta

ip route get 203.0.113.10 responde a esa pregunta directamente: imprime la ruta, la dirección de origen y la interfaz que el núcleo usaría ahora mismo para ese destino.

Ejecútalo para el servidor interior antes de que arranque el cliente interior y otra vez después, y compara. Si la respuesta cambia de la interfaz física a la interfaz del túnel exterior, el anidamiento es real en ese momento. Si no cambia, el cliente interior se conecta directamente, diga lo que diga el panel. Repite para la dirección del servidor exterior, que todavía debe resolverse por la interfaz física, porque una ruta que captura ambos extremos de forma recursiva es el fallo que deja la máquina fuera de la red por completo.

Condición dos: inspeccionar la ruta en cada capa

La selección de ruta es más que la tabla principal en un cliente moderno. Las reglas de política pueden enviar paquetes marcados a otra tabla, un cliente puede atar su socket a una interfaz, y un contenedor o un espacio de nombres tiene sus propias tablas. ip rule y ip route show table all son la forma de averiguar cuál de esos mecanismos está en juego.

Un cliente que pone SO_MARK en su propio socket, o que está configurado para atarse a un dispositivo concreto, se salta la ruta por defecto que creías haber dispuesto. Eso es una función y no un error, y significa que la única comprobación fiable es la que se ejecuta en el mismo espacio de nombres que el cliente. Si los clientes corren en contenedores, ejecuta las comprobaciones dentro de esos contenedores en lugar de en el anfitrión.

Condición tres: qué ocurre cuando cae el túnel exterior

El comportamiento ante fallos exige una decisión, no un valor por defecto. Escribe qué debe pasarle al túnel interior cuando desaparezca el exterior, y luego haz que los clientes lo cumplan.

Las opciones son concretas. Detener el cliente interior cuando desaparece la ruta exterior da una cadena limpia y una interrupción evidente. Dejarlo reconectarse directamente da disponibilidad y elimina en silencio la propiedad para la que se construyó la cadena. Bloquear hasta que vuelva la ruta exterior es la más estricta y la más molesta de operar, porque cada oscilación del túnel exterior se convierte en un incidente visible.

Prueba las tres con tráfico inocuo y un fallo provocado del túnel exterior, porque leer la configuración no te dirá cuál tienes. Corta el túnel exterior, observa qué hace el cliente interior y vuelve a comprobar la ruta mientras está caído. Después devuelve el túnel exterior y confirma que la cadena se vuelve a formar en lugar de dejar al cliente interior en la ruta directa que eligió mientras tanto.

Lo que la cadena no te da

Las capas extra añaden extremos, claves y modos de fallo; no añaden ninguna garantía de anonimato y no impiden que el operador exterior vea que existe un túnel. Cualquier afirmación sobre qué protege el anidamiento tiene que nombrar al observador contra el que protege.

El entregable es un documento breve en lugar de una conexión que funcione: qué extremo usa qué ruta, qué ocurre ante un fallo exterior y los tres comandos que muestran el estado actual. La documentación de strongSwan sobre reenvío es una referencia útil para saber cómo se reenvía el tráfico de túnel entre interfaces en un anfitrión Linux. Vuelve a ejecutar las comprobaciones después de cada actualización de cliente, porque los valores por defecto que produjeron tu cadena no son un contrato. Un túnel anidado que no puedes inspeccionar es un rumor con una luz de estado.