IPsec per una WAN privada: límits de política a l’SRX que cal comprovar

Una WAN privada pot transportar els paquets exteriors d’un túnel IPsec, de manera que les adreces del parell no han de ser adreces públiques d’internet. El que canvia és el camí que segueixen aquests paquets exteriors i els permisos de la interfície que els rep. En un SRX, el camí de control exterior, l’enllaç de la interfície de túnel i la política de trànsit reenviat són tres objectes separats. Diagnosticar-ne un mentre els altres dos són incorrectes és la causa habitual que un túnel quedi aturat.

Anoteu primer el camí IKE exterior

Anoteu quatre valors abans de tocar la política: l’adreça del parell, la interfície local que rep IKE, el context d’encaminament que arriba al parell i la ruta que selecciona aquesta interfície. Els paquets IKE s’adrecen a l’SRX mateix, de manera que necessiten permís host-inbound a la zona de recepció, no una política de trànsit reenviat. Una adreça WAN privada no elimina aquest requisit, perquè el paquet encara acaba al dispositiu.

Comproveu l’estat instal·lat amb show security ike sa i la configuració amb show configuration security ike. La primera indica si existeix la fase 1; la segona indica què creu el dispositiu que hauria de fer.

Enllaceu la interfície de túnel a la política correcta

Una VPN basada en encaminament enllaça una interfície de túnel amb un objecte VPN, i els prefixos protegits s’encaminen cap a aquesta interfície. Anoteu quina interfície, quina ruta i quina política permet les aplicacions entre les zones corresponents. Una zona anomenada trust és un contenidor de polítiques, i el nom no demostra que els paquets de control o de dades necessaris estiguin permesos.

Llegiu els enllaços reals en lloc d’un diagrama antic: show configuration security ipsec vpn per a l’ajust d’enllaç a la interfície i show configuration security policies per a les regles que fan referència a la zona del túnel.

Si la ruta protegida apunta a un altre lloc, el túnel pot estar actiu mentre el trànsit no hi entra mai. És un problema d’encaminament disfressat d’IPsec.

Mantingueu la ruta del parell a l’underlay

La ruta cap al parell extern s’ha de resoldre a través de l’underlay, no de manera recursiva a través del túnel que estableix. Si la ruta del parell apunta a la interfície de túnel, els paquets IKE persegueixen el seu propi túnel i la fase 1 no s’acaba mai. El camí de resposta del trànsit protegit necessita la seva pròpia ruta i política correctes, i normalment és la meitat que falta quan una direcció funciona. Llegiu l’entrada de la taula d’encaminament per a l’adreça del parell i confirmeu que la interfície de sortida és la interfície WAN.

Comproveu-ho amb show route 198.51.100.10, substituint l’adreça real del parell, i confirmeu que el següent salt no és una interfície de túnel.

Verifiqueu el control i el servei per ordre

Avalueu de baix a dalt: estat de la fase 1, estat de la fase 2 i després un flux real d’aplicació. show security ipsec sa llista les associacions de seguretat, i show security flow session destination-prefix 10.60.0.0/16 mostra si s’estan creant sessions reenviades per a la xarxa protegida.

Una relació de control sana i un camí de dades funcional són dos resultats diferents, i superar la fase 2 no diu res sobre si la política permet l’aplicació. Proveu un flux permès i un que la política hauria de rebutjar, perquè la diferència sigui visible.

Anoteu alhora la ruta del parell, el permís host-inbound, l’enllaç del túnel, la ruta interna i la política de l’aplicació. Aquests cinc registres mostren quin nivell serà responsable d’una fallada futura sense dependre de l’etiqueta d’un port.