A VPN entre sites funciona, mas os logs da ASA não chegam: verifique o endereço de origem

Os hosts internos alcançam o coletor remoto e as suas linhas syslog aparecem. As mensagens da própria ASA sobre essas mesmas sessões nunca chegam. Não há nada de errado com o coletor nem com o túnel, e é essa a parte confusa. A firewall envia os seus logs de uma origem para a qual o túnel nunca foi construído.

O que chega e o que não chega

Comece por separar dois fluxos que num painel parecem idênticos. O tráfego reencaminhado atravessa a ASA: um host LAN envia ao coletor, a ASA compara-o com a política do túnel, cifra-o, e o coletor vê o endereço do host. O tráfego gerado começa na própria ASA: o equipamento constrói um pacote syslog, escolhe uma interface de saída e uma origem e só depois pergunta se alguma política de túnel corresponde. O primeiro fluxo prova que o túnel funciona, e não diz nada sobre o segundo.

Um evento em memória no equipamento também não é prova de entrega remota, porque o log pode existir localmente e nunca ter sido transmitido. Verifique os contadores de receção do coletor antes de culpar o túnel, porque um contador vazio é uma constatação diferente de um que cresce.

Uma mensagem gerada não é tráfego reencaminhado

Quando a ASA origina um pacote, não está a fazer de proxy de um host LAN. A origem vem da interface de saída ou de uma definição de origem explícita, e o pacote entra na mesma pesquisa de rota e nas mesmas verificações de política que tudo o resto que o equipamento envia. Isso significa que o seletor da VPN tem de incluir o endereço que a ASA usa realmente, e esse é frequentemente a sua interface exterior e não uma sub-rede interna.

Se a política protege 10.20.0.0/24 e a ASA usa o seu endereço exterior como origem, o pacote de log ou sai em texto simples para um coletor que não consegue alcançar, ou é descartado. Ambos os resultados parecem idênticos do lado do coletor. O mesmo raciocínio aplica-se ao tráfego de gestão, e é por isso que management-access é uma decisão de projeto separada.

Que origem a ASA coloca na rede

Encontre a origem empiricamente, não por suposição. Uma captura na interface de saída durante uma mensagem de teste mostra a origem e o destino reais, e custa menos tempo do que ler três secções de configuração. Compare esse endereço com o seletor local do túnel.

Algumas versões permitem fixar a origem dos logs a uma interface, e a referência de comandos da sua versão é a autoridade sobre se essa opção existe e o que altera. Um comando source-interface de outra plataforma Cisco não é automaticamente válido numa ASA.

Se alterar a origem, faça-o deliberadamente e registe-o, porque as ACL do coletor e qualquer correlação baseada em syslog dependem dela.

Alinhe o seletor com o fluxo de logs

Depois de a origem ser conhecida, verifique três coisas por ordem: a ACL de cifra ou o seletor baseado em política que decide que tráfego é interessante, a rota que decide para onde vai o pacote e qualquer regra NAT que possa reescrever a origem antes da cifra. Um pacote que corresponde à rota mas não ao seletor não é tunelizado, e um pacote reescrito por NAT pode não corresponder a nenhum dos dois.

O lado do coletor tem requisitos próprios: uma ACL que permita a origem da ASA, uma rota de retorno e um serviço à escuta na porta que configurou. O transporte também conta aqui, porque o registo por TCP e TLS comporta-se de forma diferente do UDP num caminho parcialmente bloqueado. Altere um elemento de cada vez, ou a próxima captura não lhe dirá que alteração importou.

Verifique no coletor e depois registe a origem

Confirme que a mensagem chega e depois anote o endereço de origem que a ASA usou, o seletor que a transportou e a gravidade com que testou.

Esse registo transforma a próxima alteração de ACL no coletor ou a edição do seletor numa verificação de dois minutos em vez de uma redescoberta. Também documenta qual dos dois fluxos foi alguma vez validado, e é essa a parte que a maioria dos runbooks omite. Se a mensagem continuar a não chegar, baixe temporariamente o limite de gravidade e teste contra um único destino.

As FAQ de registo da ASA da Cisco documentam um caso com origem externa que exige a definição correspondente de tráfego protegido, e o exemplo com origem interna inclui tanto um host de registo no interior como management-access no interior. Trate a combinação documentada e o contexto do software em conjunto, em vez de assumir que uma linha copiada serve para qualquer configuração.

Um túnel que transporta tráfego LAN não é um túnel que transporta a voz própria da firewall.