Cisco ASA a Azure VPN: pares de prefixos dos selectores de tráfico

O túnel sóbese, IKE parece san e non pasa nada por el. Esa é a forma habitual dun problema de selectores de ASA a Azure, e por iso escribo o contrato antes de tocar calquera das dúas consolas. O contrato son catro cousas: os obxectos que identifican cada par, o modelo de conexión, os pares de prefixos exactos e a verificación que demostra cada par. Se se equivoca niso, cada comando posterior depura unha configuración que non debería ter construído. Este runbook é a orde que uso, cos comandos que mostran que obxecto está realmente mal.

Anote os catro obxectos antes de configurar

Comece pola versión e a plataforma de ASA, o extremo público, o tipo e o SKU da pasarela de Azure VPN, e a pasarela de rede local que representa o seu lado. Eses catro nomes son o vocabulario de todo o que segue, e cada un ten un propietario distinto cando algo se rompe.

Se dous deles aínda son suposicións, detéñase. Unha lista de prefixos incorrecta na pasarela de rede local non é un problema de axuste.

Escolla un modelo de conexión e deixe de mesturar modelos de configuración

Un deseño con crypto map e un deseño con tunnel interface son configuracións distintas, e un modelo para un non se volve válido para o outro editando o enderezo do par. Anote cal está construíndo antes de pegar nada, porque a discrepancia aparece máis tarde como un problema de selectores e non como un erro de configuración. A guía de interoperabilidade de ASA de Microsoft cobre os dous patróns e indica que modelo de pasarela de Azure supón cada un. Se as súas notas non nomean o modelo, aínda non ten un deseño.

Unha pasarela de Azure baseada en rutas con selectores de tráfico baseados en políticas é unha opción documentada específica, non a predeterminada. Se o seu deseño depende dela, o deseño debe dicilo, porque o modelo de selectores predeterminado baseado en rutas compórtase de forma distinta no lado de Azure.

Os límites de versión tamén forman parte do contrato. Un informe de campo antigo sobre un tope nos dominios de cifrado é un dato sobre versións concretas, non unha propiedade permanente de cada ASA.

Enumere os pares de prefixos, non os agregados

Escriba a matriz. A e B locais cara X e Y de Azure son catro pares, e cada un necesita cobertura ou unha exclusión explícita. Colapsar A e B nun só agregado tamén inclúe todo o que hai entre eles, e así é como un deseño queda silenciosamente cun burato.

Comprobe que negociaron os pares, non que gardou. A lista de redes locais e remotas no ASA é a intención; os CHILD SA son o resultado.

Cando falta un par, a corrección adoita ser unha liña de access-list ou unha entrada de selector, non un túnel novo.

Verifique con comandos que nomean o obxecto

No ASA, confirme a sesión IKE, despois os SA de IPsec e despois os pares de selectores. Cada comando responde a unha pregunta distinta, e executar só o primeiro é como a afirmación de que o túnel está arriba se converte nunha conclusión falsa. Lea a saída do par que realmente configurou, non do SA que casualmente sexa o primeiro da lista. O lado de Azure responde ás mesmas tres preguntas desde o seu 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

Despois pregunte a Azure polo estado da conexión con az network vpn-connection show --name <connection> --query connectionStatus. Connected con cero bytes na ruta de datos é un problema de selectores, non de encamiñamento.

Probe un fluxo permitido por par, inspeccione o enderezo de orixe visto no outro lado e probe un recurso que debería ser denegado. Esa última proba é a única que demostra que o límite segue existindo.

Manteña o alcance do cifrado separado do permiso de acceso

Un selector amplo non é un permiso. Se o deseño admitido é máis amplo que a política da aplicación, manteña os servizos estreitos nas regras da devasa e deixe o alcance do cifrado onde debe estar.

As rutas de carga de traballo de Azure e as rutas de retorno locais revísanse por separado. Os anuncios BGP, o alcance de rede estático e as rutas definidas polo usuario deben describir todos a mesma ruta, e ningún deles pode capturar recursivamente o transporte do par.

Reversión e a proba de que funcionou

Garde a configuración en execución anterior antes de cambiar os selectores, e saiba o único comando que a devolve. No ASA iso significa unha copia gardada e a ruta de restauración correspondente, non un recordo do que editou. Escriba o comando de restauración no tícket de cambio mentres o cambio aínda é hipotético. Despois volva executar as mesmas tres comprobacións: estado de IKE, pares de IPsec SA e un fluxo permitido por par.

Se un par segue fallando despois da restauración, o cambio non era a causa, e acaba de aforrarse unha segunda caída.