El VPN de sitio a sitio funciona en un solo sentido: dos fallos distintos

El sitio A llega a B, B no llega a A, y el túnel parece correcto en ambos sentidos. Antes de tocar el túnel, decida qué fallo tiene realmente. Una conexión nueva iniciada en B que se rechaza y una respuesta a una conexión iniciada en A que nunca llega producen quejas parecidas y diagnósticos completamente distintos. Uno es un problema de política o de ruta en el camino; el otro es un problema de ruta de retorno o de estado para un tráfico que ya estaba permitido.

Esa distinción decide qué comandos merece la pena ejecutar.

Dos fallos que parecen idénticos

En el primer caso el host de B envía un SYN a A y no vuelve nada. En el segundo el host de A abre una sesión con éxito y la respuesta desaparece a la vuelta. Ambos usuarios dicen que el enlace es unidireccional, y ambos describen un paquete que se desvaneció, así que la descripción por sí sola no puede separarlos.

Pregunte qué lado inició el intento que falló. Ese único dato elimina la mitad de las causas posibles.

Después compruebe que la prueba usó los mismos hosts y el mismo servicio de principio a fin. Un ping desde un lado y una conexión a una carpeta compartida desde el otro prueban dos cosas distintas, y un diagnóstico hecho desde la puerta de enlace puede elegir una dirección de túnel que ningún tráfico de usuario usa.

Caso uno: falta la ruta de retorno

Un servidor remoto que responde por otra puerta de enlace predeterminada puede recibir la petición y encaminar la respuesta a otro sitio. Los cortafuegos con seguimiento de estado descartan entonces la respuesta asimétrica porque no coincide con un flujo establecido, lo que parece exactamente un sentido que nunca funcionó. La traducción añade otra versión: el destino ve un origen traducido y responde a él, así que una regla escrita para la dirección original nunca coincide.

Compruebe la dirección que el destino observa realmente tras la traducción, y la ruta de retorno para esa dirección en lugar de para la subred original.

Caso dos: la política nunca lo permitió

El caso opuesto es más sencillo y más frecuente de lo que parece: una oficina debe consumir un servicio central y nunca iniciar conexiones hacia el centro. Esa asimetría es una decisión de acceso deliberada, y el túnel funciona tal como se diseñó. Lea la política de acceso antes de cambiar cualquier ajuste del túnel. El documento, no la captura de paquetes, indica qué sentido se pretendía. Una captura solo puede mostrar qué ocurrió, no qué estaba autorizado.

Si de verdad hace falta iniciar en ambos sentidos, añada el permiso del servicio concreto mediante el conjunto de reglas compatible de la plataforma. Hacer que todas las subredes confíen entre sí para arreglar una aplicación convierte un requisito estrecho en un permiso amplio, y ese intercambio rara vez se revisa después.

Compare antes y después en los mismos hosts

Observe ambos extremos del mismo intento, no dos intentos separados. Capture en la puerta de enlace del host que inicia y en el destino, y luego compare qué entró, qué salió y qué dirección vio el lado remoto.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Si la captura en el destino muestra la petición con una dirección de origen inesperada, la respuesta está en la traducción o en el enrutamiento, no en la política de seguridad del túnel. Si el destino no muestra ninguna petición, el paquete nunca cruzó la ruta protegida.

Tras una corrección, repita la prueba idéntica desde el host idéntico y confirme que el acceso no relacionado sigue denegado. Un estado de túnel “established” no sostiene ninguna de las dos conclusiones por sí solo.