Ruta predeterminada tunelizada en Cisco ASA: cando se aplica realmente

Un usuario de acceso remoto non alcanza nada máis alén do ASA mentres o mesmo servidor responde aos ping desde a LAN interna. O túnel lévantase, o cliente recibe un enderezo do pool e o paquete segue saíndo pola ruta predeterminada de internet ou desaparece. Ese patrón adoita significar que o tráfico descifrado non atopou unha ruta propia e caeu á ruta predeterminada ordinaria. A solución non é outra regra NAT; é a ruta predeterminada tunelizada.

Empeza polo síntoma, non pola configuración

Observa a onde vai o paquete en lugar de a onde esperabas que fose. Unha captura na interface exterior durante unha sesión fallida mostra o paquete descifrado dirixíndose á pasarela do ISP co enderezo do pool aínda intacto, ou non mostra nada porque a busca fallou. En ambos os casos o túnel non é o problema.

O túnel parece san en show vpn-sessiondb, e por iso mesmo a xente segue depurando IKE.

O que separa isto dunha caída de ACL é a dirección. Unha caída de ACL rexístrase e cóntase, mentres que unha ruta ausente produce un fallo de busca sen ningunha entrada coincidente. Executa show route para o destino do cliente e le o que seleccionou realmente o ASA, incluído se se escolleu unha ruta predeterminada e cal.

En que difire a busca tunelizada

A guía de Cisco de enrutamento estático no ASA 9.23 documenta unha ruta predeterminada aparte para o tráfico VPN descifrado que non ten ruta estática nin aprendida. A palabra clave tunneled marca esa ruta, de xeito que un paquete descifrado pode recaer nun seguinte salto distinto do que o ASA usa para o seu propio transporte. As rutas máis específicas seguen gañando, e por iso un cliente pode chegar a 10.0.0.0/8 a través da pasarela interna e perder todo o demais.

Un deseño mínimo mantén dúas rutas predeterminadas con seguintes saltos distintos. Unha leva o tráfico propio do ASA e a outra leva o tráfico descifrado que non ten unha ruta mellor. Ambos os seguintes saltos deben seguir sendo alcanzables desde a interface á que os conectas.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Se as dúas rutas predeterminadas apuntan ao mesmo seguinte salto, a palabra clave non cambia nada e o síntoma non se moverá.

As restricións que deciden se funciona

A mesma guía só permite unha ruta predeterminada tunelizada e indica que ECMP non está soportado para ela, así que non podes repartir a carga por ese camiño. Tamén enumera restricións relacionadas co seguimento de rutas, a verificación da ruta inversa e algúns fluxos de inspección e xestión. Léaas fronte á versión que ten instalada antes de deseñar arredor da función. Un deseño que as ignora adoita fallar nun punto concreto e non en todas partes, e por iso o síntoma parece intermitente.

A verificación da ruta inversa é a que morde nos deseños asimétricos. Se a resposta chegase por unha interface distinta da que o ASA espera, o paquete descártase antes de que o enrutamento importe. Corrixe a topoloxía ou o camiño de volta en lugar de desactivar a verificación para forzar un seguinte salto.

O seguimento de rutas é unha trampa á parte: o obxecto seguido adoita protexer a ruta predeterminada ordinaria, non a tunelizada.

Que non fai a palabra clave

Non escolle o enderezo de orixe que o ASA usa para construír IKE. O extremo exterior do túnel segue a propia selección de interface e orixe da plataforma, e a ruta predeterminada tunelizada non ten parte nesa decisión. Cambiala non reparará unha phase 1 que sae do enderezo equivocado.

Tampouco converte o seguinte salto nun proxy. Se o destino espera un intercambio HTTP CONNECT, enviar paquetes IP en bruto a un host proxy só che dá un host que non os enruta. Configura no seu lugar o mecanismo de proxy que admite o cliente.

E non crea reenvío augas abaixo. A pasarela á que apuntas segue necesitando unha ruta de volta ao pool VPN, ademais de tradución de orixe onde o deseño o requira.

Verifica o camiño de extremo a extremo

Unha vez que a ruta está no seu sitio, comproba catro cousas en orde: show route para un destino que o pool necesite, unha captura na interface cara ao novo seguinte salto, unha captura na propia pasarela e un camiño de volta desde esa pasarela ao enderezo do pool. As dúas primeiras proban que o ASA escolleu o camiño, e as dúas últimas que alguén responde nel.

Se a pasarela responde pero o cliente nunca ve unha resposta, mira a tradución de orixe e a ruta de resposta antes de tocar de novo a táboa de enrutamento.

Anota a versión coa que validaches, porque a lista de restricións é específica de cada versión e un deseño que funciona nunha rama pode necesitar un camiño distinto noutra. Esa nota sobrevive ao fragmento de configuración.