O módulo ASA FirePOWER non ten ningunha ruta de xestión cara a FMC

FMC mostra o módulo como inalcanzable, o rexistro queda pendente e un ping desde dentro do ASA funciona perfectamente. Nun despregamento ASA FirePOWER existente esa combinación é normal. O módulo ten o seu propio enderezo de xestión, a súa propia porta de enlace predeterminada e as súas propias decisións de encamiñamento, e compartir unha conexión física de xestión co ASA nalgunhas plataformas non as fusiona nunha soa pila de rede. Dous dispositivos responden desde dous puntos de vista distintos no mesmo cable.

O seguinte aplícase a módulos que xa están en servizo. Identifique o modelo de chasis, o tipo de módulo e a versión de software admitida antes de aplicar calquera diagrama de portos dunha guía.

Debuxe o módulo como un host separado

Comece o diagrama coa IP de xestión do módulo, a máscara e a porta de enlace predeterminada, a VLAN que transporta realmente esa conexión e o enderezo de FMC ao que debe chegar. Despois, nunha caixa separada, escriba os enderezos de interface do ASA e a súa táboa de encamiñamento completa. Se as dúas caixas acaban compartindo unha subrede con enderezos de propietarios distintos, atopou a parte interesante do problema.

A guía do módulo ASA FirePOWER mostra como varían as disposicións de portos entre plataformas, incluída a cablaxe de xestión compartida onde o ASA e o módulo levan enderezos separados no mesmo segmento. Ese diagrama de hardware é unha entrada do deseño, non unha nota ao pé.

Atope onde se creba o camiño de volta

Tome unha disposición encamiñada polo núcleo. O módulo envía o tráfico destinado a FMC cara a un núcleo Layer 3, o núcleo reenvía o destino de xestión remoto cara á interface interior do ASA e a VPN do sitio lévao ao outro lado. Logo o sitio remoto necesita unha ruta de volta á subrede de xestión do módulo. Cada salto desa cadea pode ser correcto mentres falta esa última ruta, e por iso o fallo tan a miúdo parece un túnel roto.

Lea a visión do propio ASA antes de cambiar nada:

show interface ip brief
show route
show running-config interface

O terceiro comando importa porque un enderezo de interface que esqueceu é exactamente o que fai que o camiño de volta aterre no dispositivo equivocado.

Comprobe que considera conectado o ASA

Se o ASA ten un enderezo na subrede de xestión do módulo, a súa ruta conectada posúe ese prefixo. Unha ruta estática cara ao núcleo non despraza a propiedade da ruta conectada, así que o paquete volve ao ASA e detense alí. O rexistro falla entón nun punto que non ten nada que ver coas credenciais.

Non conclúa que unha comprobación concreta anti-suplantación descartou o paquete a menos que teña diante as observacións do propio dispositivo. Compare en cambio a interface de entrada, a ruta de destino seleccionada e o límite de reenvío entre xestión e datos admitido para esa plataforma. Eses tres feitos adoitan expor o conflito de topoloxía antes de que ninguén comece a restablecer claves de rexistro.

Escolla unha corrección que manteña o módulo conectado

Retirar o enderezo do ASA dese segmento e desactivar fisicamente un porto compartido non son accións equivalentes. Nas plataformas onde o módulo viaxa pola mesma conexión física de xestión, desactivar o porto elimina a única ligazón do módulo — convertería un problema de encamiñamento nun dispositivo morto. Prefira o cambio que reasigna a propiedade do encamiñamento de xestión e prepáreo co propietario da rede presente.

Unha segunda opción admitida é darlle ao camiño administrativo do ASA o seu propio segmento para que a subrede de xestión do módulo teña un único propietario. Iso custa un enderezo e algo de documentación, e elimina a ambigüidade de forma permanente. Escolla o camiño que escolla, confirme despois que o módulo segue chegando tanto a FMC como ás súas fontes DNS ou NTP.

Rexistre só cando o camiño sexa coherente

Unha vez limpo o camiño de volta, planifique a conectividade de xestión e os parámetros de rexistro segundo a guía de versión correspondente de FMC e do módulo. Mantena os segredos de rexistro fóra de notas e tíckets compartidos e resista a tentación de volver rexistrar como paso de diagnóstico: unha clave nova nun camiño crebado só produce o mesmo fallo cunha marca de tempo máis recente.

Acepte o camiño desde a propia pila de xestión do módulo e non desde un ping orixinado polo ASA, porque a fonte da proba é xusto o que está baixo sospeita. Anote o seguinte salto do módulo, a selección de VPN do ASA e a ruta de resposta de FMC, e manteña un método de recuperación independente para ambos os roles de xestión. Ese rexistro é o que separa un transporte reparado dun rexistro correcto.

Cando o módulo apareza por fin en FMC, volva executar os mesmos tres comandos e garde a saída xunto ao diagrama. A próxima persoa que toque ese segmento de xestión necesitará exactamente esa comparación.