El VPN de sitio a sitio de Sophos está activo pero no pasa tráfico: ¿licencia o ruta?

Establecer una asociación IPsec, ver la ruta en la tabla y aun así sufrir un tiempo de espera agotado desde la sucursal es una combinación habitual en Sophos Firewall. En Sophos Firewall esa combinación tiene al menos dos explicaciones corrientes: una laguna en el reenvío o una condición de la licencia Base que mantiene el túnel activo mientras los datos dejan de pasar. Ambas producen síntomas casi idénticos, así que la única forma de salir es reunir pruebas independientes para cada una. Las dos son lo bastante frecuentes como para que ninguna pueda darse por supuesta.

Un túnel puede estar activo sin datos

Una asociación IPsec es una relación de seguridad, no una promesa de reenviar paquetes. La fase 1 y la fase 2 pueden completarse mientras la política que selecciona el tráfico, la ruta hacia el prefijo remoto o el propio camino de datos son incorrectos. La pantalla del túnel responde una pregunta y deja las otras abiertas.

Empiece por nombrar qué prefijos deben cruzar y en qué dirección. Un túnel sin tráfico interesante se ve igual que un túnel roto en una página de estado.

Qué cubre la licencia Base

Sophos incluye la VPN bajo la licencia Base, separada de Network Protection y Central Orchestration. Un módulo opcional caducado es, por tanto, un problema propio y no una prueba automática de que el IPsec de sitio a sitio necesite un paquete de pago nuevo. Anote el modelo del aparato, la versión, la identidad de registro y el estado de Base Firewall. Después concilie eso con los registros del titular de la cuenta mediante el proceso de licencias admitido, y mantenga los números de serie fuera de las notas públicas.

La plataforma también cambia la regla. Los aparatos en la nube, virtuales y de software obtienen una licencia Base sin fecha de caducidad, mientras que la licencia Base de una unidad de hardware termina al final de su vida útil. Un registro suspendido es un tercer estado entre válido y caducado, y merece las mismas pruebas en lugar de una conjetura.

Demuestre la ruta antes de culpar a la licencia

Demuestre el camino de reenvío de forma independiente. Pregunte al aparato qué ruta usaría para el prefijo remoto y luego confirme que la política de seguridad selecciona ese tráfico y que el camino de respuesta existe al otro lado. Una ruta ausente hacia el prefijo remoto sigue siendo un problema de encaminamiento, por sana que esté la licencia.

ip route get 10.80.20.10

La dirección inversa importa tanto como la directa. Una sucursal que alcanza la central pero no al revés tiene una laguna en la ruta de vuelta o en la política, no un fallo del camino de datos. Capture un flujo permitido en ambas direcciones antes de sacar conclusiones.

Mantenga dos registros para que la próxima reparación sea honesta

Mantenga dos registros separados y féchelos. El primero cubre el derecho: qué mostraba la página de licencias, qué suscripción se aplicaba y cuándo se sincronizó. El segundo cubre el reenvío: prefijos, rutas, asociaciones de seguridad y contadores direccionales para un flujo. Cuando el síntoma cambia tras una reparación, los registros muestran qué explicación era realmente correcta.

ipsec status

Esa disciplina importa porque una reparación de licencia y una reparación de ruta se ven idénticas desde un ping correcto. Si se cambiaron ambas a la vez, ha aprendido que el servicio funciona y nada sobre por qué no lo hacía. Cambie una cosa, vuelva a medir ese mismo flujo, y la guía de caducidad resuelve qué puede explicar el derecho por sí solo.