IPsec sobre unha WAN privada: límites de política no SRX que hai que revisar

Unha WAN privada pode transportar os paquetes externos dun túnel IPsec, así que os enderezos do par non teñen que ser enderezos públicos de internet. O que cambia é a ruta que seguen eses paquetes externos e os permisos na interface que os recibe. Nun SRX, a ruta de control externa, a vinculación da interface de túnel e a política de tráfico reenviado son tres obxectos separados. Diagnosticar un mentres os outros dous están mal é a causa habitual de que un túnel quede caído.

Anote primeiro a ruta IKE externa

Anote catro valores antes de tocar a política: o enderezo do par, a interface local que recibe IKE, o contexto de enrutamento que chega ao par e a ruta que selecciona esa interface. Os paquetes IKE diríxense ao propio SRX, así que necesitan permiso host-inbound na zona de recepción, non unha política de tráfico reenviado. Un enderezo WAN privado non elimina ese requisito, porque o paquete segue terminando no dispositivo.

Comprobe o estado instalado con show security ike sa e a configuración con show configuration security ike. A primeira indica se existe a fase 1; a segunda indica que cre o dispositivo que debería facer.

Vincule a interface de túnel á política correcta

Unha VPN baseada en rutas vincula unha interface de túnel a un obxecto VPN, e os prefixos protexidos enrútanse cara a esa interface. Anote que interface, que ruta e que política permiten as aplicacións entre as zonas correspondentes. Unha zona chamada trust é un contedor de políticas, e o nome non demostra que os paquetes de control ou de datos necesarios estean permitidos.

Lea as vinculacións reais en lugar dun diagrama antigo: show configuration security ipsec vpn para o axuste de vinculación á interface e show configuration security policies para as regras que fan referencia á zona do túnel.

Se a ruta protexida apunta a outro lugar, o túnel pode estar activo mentres o tráfico nunca entra nel. É un problema de enrutamento disfrazado de IPsec.

Manteña a ruta do par no underlay

A ruta cara ao par externo debe resolverse a través do underlay, non de forma recursiva a través do túnel que establece. Se a ruta do par apunta á interface de túnel, os paquetes IKE perseguen o seu propio túnel e a fase 1 nunca se completa. A ruta de resposta do tráfico protexido necesita a súa propia ruta e política correctas, e adoita ser a metade que falta cando unha dirección funciona. Lea a entrada da táboa de rutas para o enderezo do par e confirme que a interface de saída é a interface WAN.

Compruébeo con show route 198.51.100.10, substituíndo o enderezo real do par, e confirme que o seguinte salto non é unha interface de túnel.

Verifique control e servizo por orde

Avance de abaixo cara arriba: estado da fase 1, estado da fase 2 e despois un fluxo real de aplicación. show security ipsec sa enumera as asociacións de seguridade, e show security flow session destination-prefix 10.60.0.0/16 mostra se se están creando sesións reenviadas para a rede protexida.

Unha relación de control san e unha ruta de datos funcional son dous resultados distintos, e superar a fase 2 non di nada sobre se a política permite a aplicación. Probe un fluxo permitido e outro que a política debería rexeitar, para que a diferenza sexa visible.

Anote xuntos a ruta do par, o permiso host-inbound, a vinculación do túnel, a ruta interna e a política da aplicación. Eses cinco rexistros mostran que capa é responsable dun fallo futuro sen depender da etiqueta dun porto.