O módulo ASA FirePOWER não tem rota de gestão para o FMC

O FMC mostra o módulo como inalcançável, o registro fica pendente e um ping de dentro do ASA funciona perfeitamente. Numa implementação ASA FirePOWER existente, essa combinação é normal. O módulo tem o seu próprio endereço de gestão, o seu próprio gateway predefinido e as suas próprias decisões de encaminhamento, e partilhar uma ligação física de gestão com o ASA em algumas plataformas não funde isso numa única pilha de rede. Dois dispositivos respondem de dois pontos de vista diferentes no mesmo cabo.

O seguinte aplica-se a módulos que já estão em serviço. Identifique o modelo do chassis, o tipo de módulo e a versão de software suportada antes de aplicar qualquer diagrama de portas de um guia.

Desenhe o módulo como um host separado

Comece o diagrama com o IP de gestão do módulo, a máscara e o gateway predefinido, a VLAN que transporta realmente essa ligação e o endereço do FMC que é preciso alcançar. Depois, numa caixa separada, escreva os endereços de interface do ASA e a sua tabela de encaminhamento completa. Se as duas caixas acabarem por partilhar uma sub-rede com endereços de proprietários diferentes, encontrou a parte interessante do problema.

O guia do módulo ASA FirePOWER mostra como as disposições de portas variam entre plataformas, incluindo a cablagem de gestão partilhada em que o ASA e o módulo têm endereços separados no mesmo segmento. Esse diagrama de hardware é uma entrada do projeto, não uma nota de rodapé.

Encontre onde o caminho de retorno quebra

Considere uma disposição encaminhada pelo núcleo. O módulo envia o tráfego destinado ao FMC para um núcleo Layer 3, o núcleo encaminha o destino de gestão remoto para a interface interna do ASA e a VPN do local transporta-o para o outro lado. O local remoto precisa então de uma rota de volta para a sub-rede de gestão do módulo. Cada salto dessa cadeia pode estar correto enquanto falta essa última rota, e é por isso que a falha parece tantas vezes um túnel quebrado.

Leia a visão do próprio ASA antes de alterar qualquer coisa:

show interface ip brief
show route
show running-config interface

O terceiro comando importa porque um endereço de interface esquecido é exatamente o que faz o caminho de retorno aterrar no dispositivo errado.

Verifique o que o ASA considera conectado

Se o ASA tiver um endereço na sub-rede de gestão do módulo, a sua rota conectada é proprietária desse prefixo. Uma rota estática para o núcleo não desloca a propriedade da rota conectada, pelo que o pacote regressa ao ASA e aí para. O registro falha então num ponto que nada tem a ver com credenciais.

Não conclua que uma verificação anti-falsificação específica descartou o pacote, a menos que tenha à frente as observações do próprio equipamento. Compare antes a interface de entrada, a rota de destino selecionada e o limite de encaminhamento entre gestão e dados suportado para essa plataforma. Esses três factos costumam expor o conflito de topologia antes de alguém começar a repor chaves de registro.

Escolha uma correção que mantenha o módulo conectado

Remover o endereço do ASA desse segmento e desativar fisicamente uma porta partilhada não são ações equivalentes. Nas plataformas em que o módulo viaja na mesma ligação física de gestão, desativar a porta remove a única ligação do módulo — terá convertido um problema de encaminhamento num equipamento morto. Prefira a alteração que reatribui a propriedade do encaminhamento de gestão e prepare-a com o proprietário da rede presente.

Uma segunda opção suportada é dar ao caminho administrativo do ASA o seu próprio segmento, para que a sub-rede de gestão do módulo tenha um único proprietário. Isso custa um endereço e alguma documentação, e elimina a ambiguidade de forma permanente. Qualquer que seja o caminho escolhido, confirme depois que o módulo continua a alcançar tanto o FMC como as suas fontes de DNS ou NTP.

Registre apenas quando o caminho estiver coerente

Uma vez limpo o caminho de retorno, planeie a conetividade de gestão e os parâmetros de registro a partir do guia de versão correspondente do FMC e do módulo. Mantenha os segredos de registro fora de notas e tickets partilhados e resista à tentação de voltar a registar como passo de diagnóstico: uma chave nova num caminho quebrado só produz a mesma falha com um carimbo temporal mais recente.

Aceite o caminho a partir da própria pilha de gestão do módulo e não de um ping originado no ASA, porque a fonte do teste é precisamente aquilo que está sob suspeita. Anote o próximo salto do módulo, a seleção de VPN do ASA e a rota de resposta do FMC, e mantenha um método de recuperação independente para ambas as funções de gestão. É esse registro que separa um transporte reparado de um registro bem-sucedido.

Quando o módulo aparecer finalmente no FMC, volte a executar os mesmos três comandos e guarde a saída junto ao diagrama. A próxima pessoa que tocar nesse segmento de gestão vai precisar exatamente dessa comparação.