A VPN entre sedes funciona, pero os rexistros da ASA non chegan: revise a dirección de orixe

Os equipos internos chegan ao colector remoto e as súas liñas syslog aparecen. As mensaxes propias da ASA sobre esas mesmas sesións nunca chegan. Non hai nada mal co colector nin co túnel, e esa é a parte confusa. A devasa envía os seus rexistros desde unha orixe para a que o túnel nunca se construíu.

Que chega e que non

Comece separando dous fluxos que nun panel parecen idénticos. O tráfico reenviado atravesa a ASA: un equipo LAN envía ao colector, a ASA compárao coa política do túnel, cífrao e o colector ve a dirección do equipo. O tráfico xerado nace na propia ASA: o equipo constrúe un paquete syslog, escolle unha interface de saída e unha orixe e só entón pregunta se encaixa algunha política de túnel. O primeiro fluxo demostra que o túnel funciona e non di nada do segundo.

Un evento en búfer no dispositivo tampouco é proba de entrega remota, porque o rexistro pode existir localmente e non se ter transmitido nunca. Revise os contadores de recepción do colector antes de culpar o túnel, porque un contador baleiro é un achado distinto dun que medra.

Unha mensaxe xerada non é tráfico reenviado

Cando a ASA orixina un paquete, non actúa como proxy dun equipo LAN. A orixe procede da interface de saída ou dun axuste de orixe explícito, e o paquete entra na mesma busca de ruta e nas mesmas comprobacións de política que calquera outra cousa que envíe o dispositivo. Iso significa que o selector da VPN debe incluír a dirección que a ASA usa realmente, que con frecuencia é a súa interface exterior e non unha subrede interna.

Se a política protexe 10.20.0.0/24 e a ASA usa a súa dirección exterior como orixe, o paquete de rexistro ou sae en texto claro cara a un colector ao que non pode chegar, ou descártase. Ambos os resultados vense idénticos desde o lado do colector. O mesmo razoamento se aplica ao tráfico de xestión, por iso management-access é unha decisión de deseño aparte.

Que orixe pon a ASA na rede

Atope a orixe empiricamente, non por suposición. Unha captura na interface de saída durante unha mensaxe de proba mostra a orixe e o destino reais, e custa menos tempo que ler tres seccións de configuración. Compare esa dirección co selector local do túnel.

Algunhas versións permiten fixar a orixe do rexistro a unha interface, e a referencia de comandos da súa versión é a autoridade sobre se esa opción existe e que cambia. Un comando source-interface doutra plataforma Cisco non é automaticamente válido nunha ASA.

Se cambia a orixe, fágao deliberadamente e anóteo, porque as ACL do colector e calquera correlación baseada en syslog dependen del.

Axuste o selector ao fluxo de rexistro

Unha vez coñecida a orixe, revise tres cousas por orde: a ACL de cifrado ou o selector baseado en política que decide que tráfico é interesante, a ruta que decide a onde vai o paquete e calquera regra NAT que poida reescribir a orixe antes do cifrado. Un paquete que coincide coa ruta pero non co selector non pasa polo túnel, e un paquete reescrito por NAT pode non coincidir con ningún dos dous.

O lado do colector ten requisitos propios: unha ACL que permita a orixe da ASA, unha ruta de retorno e un servizo á escoita no porto que configurou. O transporte tamén importa aquí, porque o rexistro por TCP e TLS compórtase distinto do UDP nunha ruta parcialmente bloqueada. Cambie un elemento cada vez, ou a próxima captura non lle dirá que cambio importou.

Verifique no colector e despois anote a orixe

Confirme que a mensaxe chega e despois anote a dirección de orixe que usou a ASA, o selector que a transportou e a gravidade coa que probou.

Ese rexistro converte o próximo cambio de ACL do colector ou a edición do selector nunha comprobación de dous minutos en lugar dun redescubrimento. Tamén documenta cal dos dous fluxos se validou algunha vez, que é a parte que omiten case todos os runbooks. Se a mensaxe segue sen chegar, baixe temporalmente o limiar de gravidade e probe contra un único destino.

As preguntas frecuentes de rexistro da ASA de Cisco documentan un caso con orixe externa que necesita a definición correspondente de tráfico protexido, e o seu exemplo con orixe interna inclúe tanto un equipo de rexistro no interior como management-access no interior. Trate a combinación documentada e o contexto do software xuntos, en lugar de supor que unha liña copiada encaixa en calquera configuración.

Un túnel que transporta tráfico LAN non é un túnel que transporta a voz propia da devasa.