Por que os pedidos TACACS+ da própria ASA ignoram o túnel VPN da sua filial

O túnel da filial está ativo, os utilizadores autenticam-se no servidor TACACS+ remoto, e o login da própria firewall continua a expirar. A causa não é um defeito no túnel: um túnel LAN-to-LAN transporta o tráfego que corresponde aos seus seletores, e o tráfego de gestão que a ASA gera sobre si mesma é um fluxo separado com o seu próprio endereço de origem. A maioria das equipas descobre isto durante uma janela de alterações, quando a única conta de administrador é a que falha. Trate a sessão AAA iniciada pela ASA como um fluxo que tem de projetar, não como um efeito secundário de uma conectividade que já funciona.

A ASA é o cliente, e o seu próprio tráfego precisa do seu próprio caminho

Quando a firewall contacta um servidor TACACS+, a firewall é um cliente como qualquer outro, exceto que ninguém lhe configurou uma rota deliberadamente. Os seus pacotes partem de um endereço de interface no equipamento, são gerados localmente em vez de encaminhados, e têm de ser encaminhados, traduzidos e protegidos por política tal como o tráfego dos utilizadores. Um túnel site-to-site que protege uma sub-rede de utilizadores não protege automaticamente essa origem de gestão, porque a seleção de tráfego se baseia em endereços e não em intenções.

Anote o endereço que espera que o servidor veja. Se não o consegue dizer numa linha, ainda não tem um desenho.

A interface na linha aaa-server não é decoração

Na ASA, a entrada de anfitrião aaa-server aceita uma associação de interface entre parênteses, e a referência de comandos de anfitrião AAA da Cisco descreve-a como a interface onde reside o servidor de autenticação. É essa associação que liga o pedido a uma interface e à política que essa interface aplica. Escolhê-la pela interface que dá para a internet, ou deixar o que restou da última migração, produz um endereço de origem para o qual o servidor remoto e o túnel nunca foram construídos.

inside só é a resposta correta quando a interface indicada tem o endereço que o seu desenho pretende usar como origem. Num equipamento de filial é frequentemente o caso; num equipamento com vários segmentos privados pode não ser.

Alterar a associação significa recriar a entrada

A mesma referência de comandos documenta uma restrição de edição que apanha as pessoas durante as migrações: alterar a interface num anfitrião existente exige remover e recriar a entrada de anfitrião. Uma configuração que parece editada pode não ter entrado em vigor, e a tentativa de login seguinte continua a sair do endereço antigo. Planeie isso como uma eliminação e adição com uma cópia da entrada original à frente, não como um ajuste no local.

Se houver vários servidores definidos, altere um e teste-o antes de tocar nos restantes, para que um erro não bloqueie todos os caminhos administrativos de uma vez.

Verifique seletores, tradução e caminho de retorno em conjunto

Três coisas têm de coincidir para que o pedido chegue. Os seletores de tráfego do túnel, ou a proteção da interface de túnel se usar uma, têm de incluir a origem própria da ASA e o endereço do servidor; uma lista de seletores feita para sub-redes de utilizadores normalmente não o fará. Qualquer regra NAT no caminho tem de traduzir essa origem de forma consistente, porque o servidor autoriza uma identidade de equipamento de rede que inclui o endereço que vê. E o caminho de retorno tem de existir, o que num túnel baseado em políticas significa que o extremo remoto tem um seletor correspondente no sentido oposto.

Do lado do servidor, confirme separadamente a identidade do equipamento, o segredo partilhado e a política administrativa. O TACACS+ mantém a autenticação, a autorização e a contabilidade como operações distintas, por isso uma recusa que chega depois de uma troca concluída é uma resposta de política, não uma falha de transporte. Lê-la como um problema de rede leva-o a procurar no sítio errado.

Mantenha o segredo fora de capturas, bilhetes e transcrições enquanto depura, e lembre-se de que o endereço de origem que o servidor registra é o que o seu desenho tem de explicar.

Faça a alteração sem se trancar fora

Use uma consola ou um caminho de gestão independente enquanto altera a autenticação administrativa remota, e mantenha uma alternativa local aprovada até o novo caminho ter transportado um login real. Depois valide de forma estreita: um servidor, um equipamento, uma autenticação bem-sucedida com o endereço de origem observado nas duas pontas.

Registe o fluxo numa página própria: interface e endereço de origem, servidor remoto, caminho protegido e a pessoa responsável pela política de autorização. Uma alteração posterior de interface ou de túnel pode então ser avaliada sem adivinhar qual dos dois fluxos afeta.