La respuesta de la VPN de sitio a sitio no atraviesa el túnel
Una respuesta que se salta el túnel es una decisión de enrutamiento del lado remoto. Revise la tabla de hosts, los selectores y rp_filter, y luego elija ruta o NAT.
Pasé una mañana con un túnel que se levantaba limpio y movía tráfico exactamente en una dirección: la sucursal llegaba al servidor de archivos de la sede, y cada conexión abierta desde la sede hacia la sucursal moría en el primer SYN. Las SA estaban activas, los contadores del túnel subían y el handshake nunca fue el problema. La respuesta se enrutaba hacia algún lugar que el túnel no cubre, y esa elección pertenece al lado remoto. Una VPN de sitio a sitio solo transporta los paquetes que un host entrega a la puerta de enlace, y cada host toma esa elección por separado, en cada dirección, desde su propia tabla de enrutamiento.
Ambas direcciones se enrutan por separado
IP no guarda memoria de la dirección de una conversación. Cada host que envía un paquete ejecuta su propia búsqueda del prefijo más largo, elige un único salto siguiente y olvida la decisión. La petición y la respuesta son dos paquetes sin relación que casualmente pertenecen a la misma conexión, y el túnel es un salto que cualquiera de los dos puede usar o no. Nada del intercambio IKE le enseña al servidor remoto cómo llegar a su subred; la negociación solo acuerda qué prefijos pueden cifrarse.
Ese acuerdo es la segunda puerta. En strongSwan los selectores de tráfico son leftsubnet y rightsubnet, y un paquete cuyo origen o destino queda fuera del par negociado no se cifra, diga lo que diga la tabla de enrutamiento. Un prefijo que se enruta hacia el túnel pero falta en los selectores es un fallo silencioso de un solo sentido: la ruta parece correcta, el paquete sale igualmente en claro o se descarta, y solo el registro de charon se queja.
El host remoto no sabe nada de su túnel
Dentro de la LAN remota la respuesta es un paquete normal dirigido a su cliente. El host de destino no ve ninguna cabecera IPsec y no tiene motivo para preferir la puerta de enlace VPN; busca su prefijo, no encuentra nada más específico que su ruta por defecto y la sigue. Si la ruta por defecto apunta a un cortafuegos central, el cortafuegos tiene o no tiene una ruta de vuelta al túnel. Cuando no la tiene, obtiene un descarte silencioso, un ICMP unreachable o una respuesta que sale por la interfaz orientada a internet y muere.
Una segunda interfaz basta para romper esto incluso cuando existe una ruta. Un NAS con un enlace de gestión en otra VLAN, un servidor con un uplink de respaldo, una regla de política que envía un rango de origen a una segunda tabla: cualquiera de estas cosas puede capturar la respuesta. En Linux, ip rule show y ip route show table all muestran reglas y tablas que el listado por defecto oculta.
Lea la decisión en la máquina que envía la respuesta
Pregunte al núcleo antes de cambiar nada, y dele la dirección de origen, porque las reglas que dependen del origen cambian la respuesta.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"La salida nombra la interfaz de salida y el salto siguiente. Si la interfaz no es la que mira a la puerta de enlace VPN, ha encontrado el defecto, y el trabajo restante es elegir dónde debe ir la ruta. Un ping desde la puerta de enlace demuestra poco aquí: responde con una dirección que el host remoto puede situar, no con la dirección de su portátil.
En Windows los equivalentes son Find-NetRoute -RemoteIPAddress 10.10.5.10 para la decisión y Get-NetRoute para la tabla. Una ruta añadida con New-NetRoute que lleva una métrica más alta que la ruta por defecto pierde en silencio, así que lea la columna de métrica, no la entrada. Luego confirme con paquetes: tcpdump -ni any "host 10.10.5.10 and tcp port 445" en la interfaz LAN remota muestra la petición, y el mismo filtro en el lado del túnel muestra si volvió una respuesta. Petición visible sin respuesta significa que la respuesta se enrutó a otro sitio o se descartó; una respuesta en la interfaz equivocada le da el culpable antes de tocar una ruta.
Cuando la puerta de enlace del servidor no es el extremo de la VPN
Muchos sitios colocan un cortafuegos entre los servidores y el concentrador. Ese cortafuegos reenvía la respuesta, así que necesita una ruta para el prefijo de su cliente apuntando a la puerta de enlace VPN, y política de reenvío en ambas direcciones. Los dispositivos con estado lo empeoran: la petición cruzó el cortafuegos desde un host LAN que permitió, la respuesta ahora llega desde otra dirección y la entrada de seguimiento de conexiones ya no coincide, así que el paquete se descarta como no válido en lugar de denegado. Por eso el registro de políticas parece vacío mientras el tráfico desaparece.
La puerta de enlace tiene su propio segundo filtro. El filtrado de ruta inversa de Linux descarta paquetes cuyo origen no es alcanzable por la interfaz por la que llegaron, que es exactamente la forma de un camino de vuelta asimétrico legítimo. la guía de reenvío de strongSwan pide net.ipv4.ip_forward y un net.ipv4.conf.all.rp_filter relajado por ese motivo. Un valor estricto de 1 en cualquiera de las dos puertas de enlace rompe en silencio una ruta correcta, y nstat -az muestra los descartes si sabe dónde mirar.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Enrute o traduzca, y luego verifique en ambas direcciones
Las dos reparaciones no son equivalentes. Añadir una ruta mantiene intacta la dirección del cliente, así que las reglas basadas en el origen, los registros de auditoría y las aplicaciones que anotan quién llama siguen funcionando; el precio es que cada salto que toma la decisión necesita la ruta, que son más lugares donde equivocarse. Enmascaramiento en la puerta de enlace remota reduce el camino de vuelta a un solo salto, porque la respuesta ahora se dirige a la propia puerta de enlace, y oculta qué cliente hizo qué.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEElíjalo a conciencia: en cuanto los clientes aparecen como la dirección de la puerta de enlace, las ACL basadas en el origen dejan de distinguirlos, y conntrack tiene que mantener la correspondencia para que la respuesta se reescriba de vuelta al túnel. Si los selectores siguen excluyendo el prefijo del cliente, NAT no cambia nada, porque la petición nunca entró en el túnel.
Antes de darlo por arreglado, confirme cuatro cosas en orden: la ruta en el host que envía la respuesta, la ruta en cada salto que la reenvía, los selectores que cubren ambos prefijos y una captura que muestre la respuesta entrando en el túnel con el origen que espera. Después repita la prueba desde el otro sitio. Una dirección que pasa es un diseño entreabierto, y la segunda dirección suele fallar por un motivo distinto del que acaba de reparar.