¿Quién responde realmente en la dirección dedicada de la VPN?

Una dirección que queda sin usar en la asignación de la organización no es un oyente, y añadirla a un cortafuegos no crea ninguno. Algo tiene que terminar IKE en esa dirección, y el mecanismo cambia según si la puerta de enlace posee la dirección o si un dispositivo aguas arriba la traduce. La ruta del paquete es lo que distingue los dos casos, y decide qué función de la plataforma necesita antes de que alguien abra una solicitud de cambio. Modele primero la ruta y luego elija.

La ruta del paquete tras la dirección

Un par envía IKE a la dirección que recibió, por UDP 500 o por UDP 4500 cuando hay travesía de NAT. El dispositivo que tenga esa dirección en la ruta o bien recibe el datagrama localmente y responde, o bien lo reenvía a otro lugar. Esas son las dos únicas posibilidades, y todo lo demás en este artículo depende de cuál sea cierta.

Recibir localmente significa que existe un socket en ese dispositivo, vinculado a esa dirección. Reenviar significa que el datagrama se reescribe y se envía a otro extremo, que entonces tiene el socket. Una regla de cortafuegos que permite UDP 500 no le dice nada sobre cuál de las dos cosas ocurre.

Escriba el registro antes de tocar nada: la dirección con la que contactan los pares, cómo la entrega la red aguas arriba, la interfaz local o el extremo lógico que la recibe, y el proceso que responde a IKE. Cuatro líneas, y cada una se puede comprobar. Cuando una de ellas es desconocida, ese desconocimiento es el trabajo de diseño y no un detalle de implementación por resolver después. Rellenarlas tras aprobar la solicitud de cambio es como una regla de traducción acaba en el dispositivo equivocado.

Modelo A: la puerta de enlace posee la dirección

En el primer modelo la puerta de enlace tiene la dirección ella misma, ya sea como dirección secundaria en una interfaz existente, como dirección en una interfaz dedicada o como loopback que la plataforma admite como extremo de túnel. Son tres funciones distintas con tres rutas de configuración distintas, y una plataforma que admite una puede no admitir las demás.

Confirme que la plataforma y la versión admiten exactamente esa disposición antes de diseñar en torno a ella. Un bloque enrutado, una dirección adicional en una interfaz y un extremo loopback no son intercambiables, y la documentación de una versión no promete que la siguiente se comporte igual.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

El socket a la escucha es la prueba. Si nada está vinculado a la dirección, la puerta de enlace no es el terminador diga lo que diga la tabla de rutas, y una captura de paquetes mostrará los datagramas llegando sin nada que los responda.

No ponga una segunda interfaz en una subred que ya existe en otro lugar de la topología y suponga que la plataforma lo resolverá. Las subredes de interfaz solapadas producen una selección de origen ambigua y, en muchas plataformas, una negativa a configurar del todo.

Modelo B: un dispositivo aguas arriba la traduce

En el segundo modelo un cortafuegos aguas arriba tiene la dirección dedicada y reenvía el tráfico a otra puerta de enlace VPN. Eso es una traducción de destino con ruta de retorno, y es un diseño perfectamente válido siempre que se documente como tal.

Lo que no es, es prueba de que el dispositivo aguas arriba haya adquirido un socket VPN local. La traducción reenvía paquetes; no convierte la caja superior en un respondedor IKE. Si se elimina la regla aguas arriba o se rompe su ruta de retorno, la VPN se detiene aunque la puerta de enlace esté sana y sus propios oyentes intactos.

Registre ambas direcciones: la que contactan los pares y la que la puerta de enlace ve realmente. Luego registre el transporte y la ruta de retorno, porque una traducción que funciona para UDP 500 pero no para ESP encapsulado se conectará y después no podrá transportar tráfico, lo cual es un fallo confuso de depurar más adelante.

La identidad no es la dirección exterior

IPsec separa el extremo del túnel del tráfico que protege, y la arquitectura mantiene esas decisiones en lugares distintos. Cambiar la dirección con la que contactan los pares no cambia automáticamente qué prefijos internos se permiten, qué rutas se instalan ni a qué recursos puede llegar la sesión.

La identidad autenticada es de nuevo separada. IKEv2 lleva una carga de identidad y un intercambio de autenticación que no necesitan coincidir con la dirección exterior del paquete, y precisamente por eso un diseño traducido todavía puede autenticarse correctamente.

Esa independencia es útil y también una trampa. Dos nombres DNS que resuelven a un oyente corriente no seleccionan backends VPN distintos, y un certificado que nombra una identidad no satisfará a un par que espera otra. Confirme qué valida el par antes de suponer que la dirección por sí sola lo decide.

Acepte el diseño observando una conexión

Inspeccione dónde se entrega realmente una conexión autorizada nueva, qué identidad responde y qué flujo privado se permite después. Tres observaciones, tres capas distintas, y una consulta pública correcta de la dirección no prueba ninguna de ellas.

Conserve también el caso negativo: un par que no debería aceptarse, o un prefijo interno que no debería ser alcanzable, verificado tras el cambio. El registro que escribió al principio es lo que hace posible esa prueba sin reconstruir el diseño de memoria.

El sentido de todo esto es permitir que el propietario de la red elija un método de asignación admitido en lugar de fiarse de una afirmación general sobre lo que cada cortafuegos puede hacer con una dirección extra. Esa afirmación es exactamente donde estos diseños fallan, porque suena plausible en todas las plataformas y en general no es cierta en ninguna. El registro de cuatro líneas lo resuelve para su plataforma en diez minutos.