IPsec sobre una WAN privada: límites de política en el SRX que conviene revisar

Una WAN privada puede transportar los paquetes externos de un túnel IPsec, así que las direcciones del par no tienen que ser direcciones públicas de internet. Lo que cambia es la ruta que siguen esos paquetes externos y los permisos en la interfaz que los recibe. En un SRX, la ruta de control externa, la vinculación de la interfaz de túnel y la política de tráfico reenviado son tres objetos separados. Diagnosticar uno mientras los otros dos están mal es la causa habitual de que un túnel se quede caído.

Anote primero la ruta IKE externa

Anote cuatro valores antes de tocar la política: la dirección del par, la interfaz local que recibe IKE, el contexto de enrutamiento que llega al par y la ruta que selecciona esa interfaz. Los paquetes IKE se dirigen al propio SRX, así que necesitan permiso host-inbound en la zona de recepción, no una política de tráfico reenviado. Una dirección WAN privada no elimina ese requisito, porque el paquete sigue terminando en el dispositivo.

Compruebe el estado instalado con show security ike sa y la configuración con show configuration security ike. La primera indica si existe la fase 1; la segunda indica qué cree el dispositivo que debería hacer.

Vincule la interfaz de túnel a la política correcta

Una VPN basada en rutas vincula una interfaz de túnel a un objeto VPN, y los prefijos protegidos se enrutan hacia esa interfaz. Anote qué interfaz, qué ruta y qué política permiten las aplicaciones entre las zonas correspondientes. Una zona llamada trust es un contenedor de políticas, y el nombre no demuestra que los paquetes de control o de datos necesarios estén permitidos.

Lea las vinculaciones reales en lugar de un diagrama antiguo: show configuration security ipsec vpn para el ajuste de vinculación a la interfaz y show configuration security policies para las reglas que hacen referencia a la zona del túnel.

Si la ruta protegida apunta a otro lugar, el túnel puede estar activo mientras el tráfico nunca entra en él. Es un problema de enrutamiento disfrazado de IPsec.

Mantenga la ruta del par en el underlay

La ruta hacia el par externo debe resolverse a través del underlay, no de forma recursiva a través del túnel que establece. Si la ruta del par apunta a la interfaz de túnel, los paquetes IKE persiguen su propio túnel y la fase 1 nunca se completa. La ruta de respuesta del tráfico protegido necesita su propia ruta y política correctas, y suele ser la mitad que falta cuando una dirección funciona. Lea la entrada de la tabla de rutas para la dirección del par y confirme que la interfaz de salida es la interfaz WAN.

Compruébelo con show route 198.51.100.10, sustituyendo la dirección real del par, y confirme que el siguiente salto no es una interfaz de túnel.

Verifique control y servicio en orden

Avance de abajo hacia arriba: estado de la fase 1, estado de la fase 2 y luego un flujo real de aplicación. show security ipsec sa enumera las asociaciones de seguridad, y show security flow session destination-prefix 10.60.0.0/16 muestra si se están creando sesiones reenviadas para la red protegida.

Una relación de control sana y una ruta de datos funcional son dos resultados distintos, y superar la fase 2 no dice nada sobre si la política permite la aplicación. Pruebe un flujo permitido y otro que la política debería rechazar, para que la diferencia sea visible.

Anote juntos la ruta del par, el permiso host-inbound, la vinculación del túnel, la ruta interna y la política de la aplicación. Esos cinco registros muestran qué capa es responsable de un fallo futuro sin depender de la etiqueta de un puerto.