Cisco ASA a Azure VPN: pares de prefijos de los selectores de tráfico

El túnel se levanta, IKE parece sano y no pasa nada por él. Esa es la forma habitual de un problema de selectores de ASA a Azure, y por eso escribo el contrato antes de tocar cualquiera de las dos consolas. El contrato son cuatro cosas: los objetos que identifican a cada par, el modelo de conexión, los pares de prefijos exactos y la verificación que demuestra cada par. Si se equivoca en eso, cada comando posterior depura una configuración que no debería haber construido. Este runbook es el orden que uso, con los comandos que muestran qué objeto está realmente mal.

Anote los cuatro objetos antes de configurar

Empiece por la versión y la plataforma de ASA, el extremo público, el tipo y el SKU de la puerta de enlace de Azure VPN, y la puerta de enlace de red local que representa su lado. Esos cuatro nombres son el vocabulario de todo lo que sigue, y cada uno tiene un propietario distinto cuando algo se rompe.

Si dos de ellos siguen siendo suposiciones, deténgase. Una lista de prefijos incorrecta en la puerta de enlace de red local no es un problema de ajuste.

Elija un modelo de conexión y deje de mezclar plantillas

Un diseño con crypto map y un diseño con tunnel interface son configuraciones distintas, y una plantilla para uno no se vuelve válida para el otro editando la dirección del par. Anote cuál está construyendo antes de pegar nada, porque la discrepancia aparece más tarde como un problema de selectores y no como un error de configuración. La guía de interoperabilidad de ASA de Microsoft cubre ambos patrones e indica qué modelo de puerta de enlace de Azure supone cada uno. Si sus notas no nombran el modelo, todavía no tiene un diseño.

Una puerta de enlace de Azure basada en rutas con selectores de tráfico basados en directivas es una opción documentada específica, no la predeterminada. Si su diseño depende de ella, el diseño debe decirlo, porque el modelo de selectores predeterminado basado en rutas se comporta de forma distinta en el lado de Azure.

Los límites de versión también forman parte del contrato. Un informe de campo antiguo sobre un tope en los dominios de cifrado es un dato sobre versiones concretas, no una propiedad permanente de cada ASA.

Enumere los pares de prefijos, no los agregados

Escriba la matriz. A y B locales hacia X e Y de Azure son cuatro pares, y cada uno necesita cobertura o una exclusión explícita. Colapsar A y B en un solo agregado también incluye todo lo que hay entre ellos, y así es como un diseño se queda silenciosamente con un agujero.

Compruebe qué han negociado los pares, no qué ha guardado. La lista de redes locales y remotas en el ASA es la intención; los CHILD SA son el resultado.

Cuando falta un par, la corrección suele ser una línea de access-list o una entrada de selector, no un túnel nuevo.

Verifique con comandos que nombran el objeto

En el ASA, confirme la sesión IKE, después los SA de IPsec y después los pares de selectores. Cada comando responde a una pregunta distinta, y ejecutar solo el primero es como la afirmación de que el túnel está levantado se convierte en una conclusión falsa. Lea la salida del par que realmente configuró, no del SA que casualmente sea el primero de la lista. El lado de Azure responde a las mismas tres preguntas desde su propio punto de vista.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

Después pregunte a Azure por el estado de la conexión con az network vpn-connection show --name <connection> --query connectionStatus. Connected con cero bytes en la ruta de datos es un problema de selectores, no de enrutamiento.

Pruebe un flujo permitido por par, inspeccione la dirección de origen vista en el otro lado y pruebe un recurso que debería ser denegado. Esa última prueba es la única que demuestra que el límite sigue existiendo.

Mantenga el alcance del cifrado separado del permiso de acceso

Un selector amplio no es un permiso. Si el diseño admitido es más amplio que la política de la aplicación, mantenga los servicios estrechos en las reglas del cortafuegos y deje el alcance del cifrado donde debe estar.

Las rutas de carga de trabajo de Azure y las rutas de retorno locales se revisan por separado. Los anuncios BGP, el alcance de red estático y las rutas definidas por el usuario deben describir todos la misma ruta, y ninguno de ellos puede capturar recursivamente el transporte del par.

Reversión y la prueba de que funcionó

Guarde la configuración en ejecución anterior antes de cambiar los selectores, y sepa el único comando que la devuelve. En el ASA eso significa una copia guardada y la ruta de restauración correspondiente, no un recuerdo de lo que editó. Escriba el comando de restauración en el ticket de cambio mientras el cambio aún es hipotético. Después vuelva a ejecutar las mismas tres comprobaciones: estado de IKE, pares de IPsec SA y un flujo permitido por par.

Si un par sigue fallando después de la restauración, el cambio no era la causa, y acaba de ahorrarse una segunda caída.