Il modulo ASA FirePOWER non ha una rotta di gestione verso FMC

FMC mostra il modulo come irraggiungibile, la registrazione resta in attesa e un ping dall’interno dell’ASA funziona perfettamente. In un deployment ASA FirePOWER esistente questa combinazione è normale. Il modulo ha il proprio indirizzo di gestione, il proprio gateway predefinito e le proprie decisioni di routing, e condividere una connessione di gestione fisica con l’ASA su alcune piattaforme non li fonde in un unico stack di rete. Due dispositivi rispondono da due punti di vista diversi sullo stesso cavo.

Quanto segue vale per moduli già in servizio. Identificate il modello di chassis, il tipo di modulo e la versione software supportata prima di applicare qualsiasi schema delle porte tratto da una guida.

Disegnate il modulo come un host separato

Iniziate lo schema con l’IP di gestione del modulo, la maschera e il gateway predefinito, la VLAN che trasporta davvero quella connessione e l’indirizzo FMC da raggiungere. Poi, in un riquadro separato, scrivete gli indirizzi delle interfacce dell’ASA e la sua tabella di routing completa. Se i due riquadri finiscono per condividere una sottorete con indirizzi di proprietari diversi, avete trovato la parte interessante del problema.

La guida del modulo ASA FirePOWER mostra come le disposizioni delle porte variano tra le piattaforme, incluso il cablaggio di gestione condiviso in cui l’ASA e il modulo hanno indirizzi separati sullo stesso segmento. Quel diagramma hardware è un input della progettazione, non una nota a piè di pagina.

Trovate dove si interrompe il percorso di ritorno

Prendete una disposizione instradata attraverso il core. Il modulo invia il traffico diretto a FMC verso un core Layer 3, il core inoltra la destinazione di gestione remota verso l’interfaccia interna dell’ASA e la VPN del sito la porta dall’altra parte. Il sito remoto ha poi bisogno di una rotta di ritorno verso la sottorete di gestione del modulo. Ogni salto di quella catena può essere corretto mentre manca quell’ultima rotta, ed è per questo che il guasto sembra così spesso un tunnel rotto.

Leggete la visione dell’ASA stesso prima di modificare qualsiasi cosa:

show interface ip brief
show route
show running-config interface

Il terzo comando conta perché un indirizzo di interfaccia dimenticato è esattamente ciò che fa atterrare il percorso di ritorno sul dispositivo sbagliato.

Controllate cosa l’ASA considera connesso

Se l’ASA ha un indirizzo sulla sottorete di gestione del modulo, la sua rotta connessa possiede quel prefisso. Una rotta statica verso il core non sposta la proprietà della rotta connessa, quindi il pacchetto torna all’ASA e si ferma lì. La registrazione fallisce allora in un punto che non ha nulla a che vedere con le credenziali.

Non concludete che un controllo anti-spoofing specifico abbia scartato il pacchetto se non avete davanti le osservazioni dell’apparecchio stesso. Confrontate invece l’interfaccia di ingresso, la rotta di destinazione selezionata e il limite di inoltro tra gestione e dati supportato per quella piattaforma. Quei tre fatti di solito smascherano il conflitto di topologia prima che qualcuno inizi a reimpostare le chiavi di registrazione.

Scegliete una correzione che mantenga il modulo connesso

Rimuovere l’indirizzo dell’ASA da quel segmento e disabilitare fisicamente una porta condivisa non sono azioni equivalenti. Sulle piattaforme in cui il modulo viaggia sulla stessa connessione di gestione fisica, disabilitare la porta elimina l’unico collegamento del modulo: avreste trasformato un problema di routing in un apparato morto. Preferite la modifica che riassegna la proprietà del routing di gestione e preparatela con il proprietario della rete presente.

Una seconda opzione supportata è dare al percorso amministrativo dell’ASA un proprio segmento, così che la sottorete di gestione del modulo abbia un solo proprietario. Costa un indirizzo e un po’ di documentazione, e rimuove definitivamente l’ambiguità. Qualunque percorso scegliate, confermate poi che il modulo riesca ancora a raggiungere sia FMC sia le sue fonti DNS o NTP.

Registrate solo quando il percorso è coerente

Una volta che il percorso di ritorno è pulito, pianificate la connettività di gestione e i parametri di registrazione dalla guida di versione corrispondente di FMC e del modulo. Tenete i segreti di registrazione fuori da note e ticket condivisi e resistete alla tentazione di registrare di nuovo come passo diagnostico: una chiave nuova su un percorso rotto produce solo lo stesso guasto con un timestamp più recente.

Accettate il percorso dallo stack di gestione del modulo stesso e non da un ping originato dall’ASA, perché la fonte del test è proprio ciò che è sotto sospetto. Annotate il salto successivo del modulo, la selezione VPN dell’ASA e la rotta di risposta di FMC, e mantenete un metodo di ripristino indipendente per entrambi i ruoli di gestione. È quella registrazione a separare un trasporto riparato da una registrazione riuscita.

Quando il modulo compare finalmente in FMC, rieseguite gli stessi tre comandi e salvate l’output accanto allo schema. La prossima persona che toccherà quel segmento di gestione avrà bisogno esattamente di quel confronto.