Ruta per defecte tunelitzada a Cisco ASA: quan s'aplica realment

Un usuari d'accés remot no pot arribar enlloc més enllà de l'ASA mentre el mateix servidor respon als ping des de la LAN interna. El túnel s'aixeca, el client rep una adreça del pool i el paquet encara surt per la ruta per defecte d'internet o desapareix. Aquest patró normalment significa que el trànsit desxifrat no va trobar cap ruta pròpia i va caure a la ruta per defecte ordinària. La solució no és una altra regla NAT; és la ruta per defecte tunelitzada.

Comença pel símptoma, no per la configuració

Mira on va el paquet en lloc d'on esperaves que anés. Una captura a la interfície exterior durant una sessió fallida mostra el paquet desxifrat encaminant-se cap a la passarel·la de l'ISP amb l'adreça del pool encara intacta, o no mostra res perquè la consulta ha fallat. En tots dos casos el túnel no és el problema.

El túnel sembla sa a show vpn-sessiondb, i per això mateix la gent continua depurant IKE.

El que ho separa d'una caiguda d'ACL és la direcció. Una caiguda d'ACL es registra i es compta, mentre que una ruta que falta produeix un error de consulta sense cap entrada coincident. Executa show route per a la destinació del client i llegeix què va seleccionar realment l'ASA, incloent-hi si es va triar una ruta per defecte i quina.

Com difereix la consulta tunelitzada

La guia de Cisco d'encaminament estàtic de l'ASA 9.23 documenta una ruta per defecte separada per al trànsit VPN desxifrat que no té cap ruta estàtica ni apresa. La paraula clau tunneled marca aquesta ruta, de manera que un paquet desxifrat pot recaure en un següent salt diferent del que l'ASA utilitza per al seu propi transport. Les rutes més específiques continuen guanyant, i per això un client pot arribar a 10.0.0.0/8 a través de la passarel·la interna i perdre tota la resta.

Un disseny mínim manté dues rutes per defecte amb següents salts diferents. Una porta el trànsit propi de l'ASA i l'altra porta el trànsit desxifrat que no té cap ruta millor. Tots dos següents salts encara han de ser abastables des de la interfície a la qual els enganxeu.

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

Si les dues rutes per defecte apunten al mateix següent salt, la paraula clau no canvia res i el símptoma no es mourà.

Les restriccions que decideixen si funciona

La mateixa guia només permet una ruta per defecte tunelitzada i indica que ECMP no s'hi admet, així que no podeu repartir la càrrega per aquest camí. També enumera restriccions relacionades amb el seguiment de rutes, la verificació del camí invers i alguns fluxos d'inspecció i gestió. Llegeix-les contra la versió que teniu instal·lada abans de dissenyar al voltant de la funció. Un disseny que les ignora normalment falla en un punt concret i no a tot arreu, i per això el símptoma sembla intermitent.

La verificació del camí invers és la que mossega en dissenys asimètrics. Si la resposta arribés per una interfície diferent de la que l'ASA espera, el paquet es descarta abans que l'encaminament importi. Arregla la topologia o el camí de tornada en lloc de desactivar la verificació per forçar un següent salt.

El seguiment de rutes és una trampa a part: l'objecte seguit normalment protegeix la ruta per defecte ordinària, no la tunelitzada.

Què no fa la paraula clau

No tria l'adreça d'origen que l'ASA utilitza per construir IKE. El punt final exterior del túnel segueix la selecció pròpia d'interfície i d'origen de la plataforma, i la ruta per defecte tunelitzada no hi té cap paper. Canviar-la no repararà una phase 1 que surt de l'adreça equivocada.

Tampoc converteix el següent salt en un proxy. Si la destinació espera un intercanvi HTTP CONNECT, enviar paquets IP en brut a un host proxy només us dona un host que no els encamina. Configureu en el seu lloc el mecanisme de proxy que admet el client.

I no crea reenviament aigües avall. La passarel·la a la qual apunteu encara necessita una ruta de tornada al pool VPN, a més de traducció d'origen on el disseny ho demani.

Verifiqueu el camí d'extrem a extrem

Un cop la ruta és al lloc, comproveu quatre coses en ordre: show route per a una destinació que el pool necessiti, una captura a la interfície cap al nou següent salt, una captura a la mateixa passarel·la i un camí de tornada d'aquesta passarel·la a l'adreça del pool. Les dues primeres proven que l'ASA va triar el camí, i les dues últimes proven que algú hi respon.

Si la passarel·la respon però el client no veu mai cap resposta, mira la traducció d'origen i la ruta de resposta abans de tornar a tocar la taula d'encaminament.

Anota la versió amb què has validat, perquè la llista de restriccions és específica de cada versió i un disseny que funciona en una branca pot necessitar un camí diferent en una altra. Aquesta nota sobreviu al fragment de configuració.