De sitio a sitio frente a acceso remoto por VPN: qué une cada uno

Ambos diseños se llaman VPN y resuelven problemas distintos. Un túnel de sitio a sitio une dos pasarelas, de modo que cada host detrás de ellas puede alcanzar las direcciones permitidas del otro lado sin instalar nada. Un túnel de acceso remoto une dispositivos individuales a una red, un cliente a la vez. La comparación importa porque la mayoría de los errores de despliegue provienen de configurar un diseño esperando el comportamiento del otro, y el síntoma suele ser un tiempo de espera agotado en un servicio al que el túnel sí llegó.

Dos diseños, dos fronteras

Ninguno de los dos diseños extiende un dominio de difusión LAN. Los dispositivos del lado remoto no aparecen en una lista de descubrimiento local, y esperar que lo hagan es la primera suposición que hay que abandonar. Los nombres DNS privados que publica a propósito son más predecibles que cualquier protocolo de descubrimiento y sobreviven a un cambio de proveedor.

Tome 10.10.0.0/24 en un sitio y 10.20.0.0/24 en el otro. La pasarela A necesita una ruta o un selector de tráfico que envíe el prefijo 10.20.0.0/24 al túnel, y la pasarela B necesita la imagen espejo. Los hosts de ambos lados usan entonces conectividad IP corriente y nunca llegan a saber que existe un túnel. Esa invisibilidad es la característica, y también es la razón por la que los fallos parecen errores de red ordinarios en lugar de errores de túnel.

Basado en política y basado en ruta no son el mismo túnel

En un despliegue de IPsec basado en política, los selectores de tráfico negociados definen exactamente qué pares de origen y destino están protegidos. Si aparece una subred nueva detrás de una pasarela y ningún selector la cubre, el túnel sigue activo y la subred nueva simplemente no se transporta. En un diseño basado en ruta, una interfaz recibe el tráfico y la tabla de enrutamiento decide, lo que hace que añadir un prefijo sea un cambio de enrutamiento y no una renegociación del túnel.

StrongSwan expone ambas vistas directamente, y leerlas juntas es como se averigua qué modelo ha desplegado en realidad.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Una lista de selectores que omite el prefijo que le importa explica el fallo sin ninguna captura de paquetes, y una ruta que apunta a la interfaz equivocada explica el fallo espejo de vuelta. Lea ambas cosas antes de renegociar nada, porque una renovación de clave no añadirá un selector que nunca configuró.

Planifique el direccionamiento antes del túnel

Los rangos solapados son el error de diseño que no se puede corregir con configuración. Si ambos sitios usan 192.168.1.0/24, un host que necesita 192.168.1.50 tiene dos candidatos y ninguna forma de elegir. El túnel se autenticará, las asociaciones de seguridad se establecerán y la decisión de enrutamiento será errónea o ambigua de todos modos.

Elija una de tres opciones honestas: renumerar un sitio, traducir el rango solapado en la pasarela para que cada lado vea un prefijo distinto, o renunciar al enrutamiento directo para esos hosts y publicar el servicio de otra manera. Cada una tiene un coste, y la primera suele ser la más barata en un horizonte de dos años. Decida antes de que exista el túnel, porque después el cambio toca todos los dispositivos que tengan la dirección antigua.

Resuelva también la cuestión de la MTU pronto. Un túnel reduce la carga útil, y un diseño que depende de la fragmentación se comporta de forma distinta a uno que fija la MSS en las pasarelas.

El reenvío y la política quedan fuera del túnel

La pasarela debe estar dispuesta a reenviar paquetes entre la interfaz del túnel y la interfaz LAN, y ambas direcciones necesitan una política que permita el servicio. En Linux son dos ajustes separados, más las reglas del cortafuegos que deciden si el flujo reenviado se permite siquiera.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

El host receptor añade una tercera capa: su propio cortafuegos todavía tiene que aceptar un cliente de la subred remota. Un servidor de archivos que solo permite su /24 local rechazará el tráfico reenviado desde 10.20.0.7, por muy sano que parezca el túnel, y ese rechazo se lee fácilmente como un fallo de enrutamiento.

Pruebe desde un host, no desde la pasarela

Un ping originado por la propia pasarela puede seguir una dirección de origen y una política distintas de las del tráfico de usuario reenviado. Eso lo convierte en una prueba débil y, en ocasiones, engañosa: tiene éxito mientras la aplicación falla, o falla mientras la aplicación funciona.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Use un host real, una dirección de origen real y el protocolo real que utiliza la aplicación. Luego lea el camino de vuelta por separado, porque una dirección de ida que funciona sin ruta de retorno produce un tiempo de espera agotado que parece idéntico al de un servicio bloqueado.

Elija el diseño según la pregunta que responde: ¿está uniendo redes o admitiendo dispositivos? Todo lo demás, incluido qué proveedor configura, se deriva de esa respuesta.