El mòdul ASA FirePOWER no té cap ruta de gestió cap a FMC

FMC mostra el mòdul com a inabastable, el registre queda pendent i un ping des de dins de l’ASA funciona perfectament. En un desplegament ASA FirePOWER existent, aquesta combinació és normal. El mòdul té la seva pròpia adreça de gestió, la seva pròpia porta d’enllaç per defecte i les seves pròpies decisions d’encaminament, i compartir una connexió física de gestió amb l’ASA en algunes plataformes no ho fusiona en una sola pila de xarxa. Dos dispositius responen des de dos punts de vista diferents al mateix cable.

El que segueix s’aplica a mòduls que ja estan en servei. Identifiqueu el model de xassís, el tipus de mòdul i la versió de programari admesa abans d’aplicar qualsevol diagrama de ports d’una guia.

Dibuixeu el mòdul com un amfitrió separat

Comenceu el diagrama amb la IP de gestió del mòdul, la màscara i la porta d’enllaç per defecte, la VLAN que porta realment aquesta connexió i l’adreça de FMC a què ha d’arribar. Després, en una caixa separada, escriviu les adreces d’interfície de l’ASA i la seva taula d’encaminament completa. Si les dues caixes acaben compartint una subxarxa amb adreces propietat de caixes diferents, heu trobat la part interessant del problema.

La guia del mòdul ASA FirePOWER mostra com varien les disposicions de ports entre plataformes, incloent-hi el cablejat de gestió compartit on l’ASA i el mòdul porten adreces separades al mateix segment. Aquest diagrama de maquinari és una entrada del disseny, no una nota a peu de pàgina.

Trobeu on es trenca el camí de tornada

Preneu una disposició encaminada pel nucli. El mòdul envia el trànsit destinat a FMC cap a un nucli Layer 3, el nucli reenvia la destinació de gestió remota cap a la interfície interior de l’ASA i la VPN del lloc el transporta a l’altre costat. Llavors el lloc remot necessita una ruta de tornada a la subxarxa de gestió del mòdul. Cada salt d’aquesta cadena pot ser correcte mentre falta aquesta última ruta, i per això la fallada sovint sembla un túnel trencat.

Llegiu la visió pròpia de l’ASA abans de modificar res:

show interface ip brief
show route
show running-config interface

La tercera ordre és important perquè una adreça d’interfície que heu oblidat és exactament el que fa que el camí de tornada aterri al dispositiu equivocat.

Comproveu què considera connectat l’ASA

Si l’ASA té una adreça a la subxarxa de gestió del mòdul, la seva ruta connectada posseeix aquest prefix. Una ruta estàtica cap al nucli no desplaça la propietat de la ruta connectada, així que el paquet torna a l’ASA i s’atura allà. El registre falla llavors en un punt que no té res a veure amb les credencials.

No conclogueu que una comprovació concreta anti-suplantació va descartar el paquet tret que tingueu davant les observacions del propi aparell. Compareu en canvi la interfície d’entrada, la ruta de destinació seleccionada i el límit de reenviament entre gestió i dades admès per a aquesta plataforma. Aquests tres fets solen exposar el conflicte de topologia abans que ningú comenci a reiniciar claus de registre.

Trieu una correcció que mantingui el mòdul connectat

Treure l’adreça de l’ASA d’aquell segment i desactivar físicament un port compartit no són accions equivalents. En plataformes on el mòdul viatja per la mateixa connexió física de gestió, desactivar el port elimina l’únic enllaç del mòdul — haureu convertit un problema d’encaminament en un aparell mort. Preferiu el canvi que reassigna la propietat de l’encaminament de gestió i prepareu-lo amb el propietari de la xarxa present.

Una segona opció admesa és donar al camí administratiu de l’ASA el seu propi segment perquè la subxarxa de gestió del mòdul tingui un sol propietari. Això costa una adreça i una mica de documentació, i elimina l’ambigüitat de manera permanent. Trieu el camí que trieu, confirmeu després que el mòdul encara pot arribar tant a FMC com a les seves fonts de DNS o NTP.

Registreu només quan el camí sigui coherent

Un cop el camí de tornada sigui net, planifiqueu la connectivitat de gestió i els paràmetres de registre segons la guia de versió corresponent de FMC i del mòdul. Manteniu els secrets de registre fora de notes i tiquets compartits i resistiu la temptació de tornar a registrar com a pas de diagnòstic: una clau nova en un camí trencat només produeix la mateixa fallada amb una marca de temps més recent.

Accepteu el camí des de la pròpia pila de gestió del mòdul i no des d’un ping originat per l’ASA, perquè la font de la prova és justament allò que està sota sospita. Anoteu el següent salt del mòdul, la selecció de VPN de l’ASA i la ruta de resposta de FMC, i manteniu un mètode de recuperació independent per als dos rols de gestió. Aquest registre és el que separa un transport reparat d’un registre correcte.

Quan el mòdul finalment aparegui a FMC, torneu a executar les mateixes tres ordres i deseu la sortida al costat del diagrama. La propera persona que toqui aquest segment de gestió necessitarà exactament aquesta comparació.