Modulul ASA FirePOWER nu are rută de administrare către FMC

FMC afișează modulul ca inaccesibil, înregistrarea rămâne în așteptare, iar un ping din interiorul ASA funcționează impecabil. Într-o implementare ASA FirePOWER existentă, această combinație este normală. Modulul are propria adresă de administrare, propriul gateway implicit și propriile decizii de rutare, iar partajarea unei conexiuni fizice de administrare cu ASA pe unele platforme nu le contopește într-o singură stivă de rețea. Două dispozitive răspund din două perspective diferite pe același cablu.

Cele ce urmează se aplică modulelor deja în exploatare. Identificați modelul șasiului, tipul modulului și versiunea de software acceptată înainte de a aplica orice schemă de porturi dintr-un ghid.

Desenați modulul ca un host separat

Începeți schema cu IP-ul de administrare al modulului, masca și gateway-ul implicit, VLAN-ul care transportă efectiv acea conexiune și adresa FMC care trebuie atinsă. Apoi, într-o casetă separată, scrieți adresele interfețelor ASA și tabela sa completă de rutare. Dacă cele două casete ajung să partajeze o subrețea cu adrese deținute de proprietari diferiți, ați găsit partea interesantă a problemei.

Ghidul modulului ASA FirePOWER arată cum diferă dispunerea porturilor între platforme, inclusiv cablarea de administrare partajată în care ASA și modulul au adrese separate în același segment. Acea schemă hardware este o intrare pentru proiectare, nu o notă de subsol.

Găsiți unde se rupe calea de întoarcere

Luați o configurație rutată prin nucleu. Modulul trimite traficul către FMC într-un nucleu Layer 3, nucleul redirecționează destinația de administrare la distanță către interfața interioară a ASA, iar VPN-ul sitului îl transportă pe cealaltă parte. Situl la distanță are apoi nevoie de o rută înapoi către subrețeaua de administrare a modulului. Fiecare salt din acel lanț poate fi corect în timp ce ruta finală lipsește, și de aceea defecțiunea arată atât de des ca un tunel rupt.

Citiți viziunea proprie a ASA înainte de a modifica ceva:

show interface ip brief
show route
show running-config interface

A treia comandă contează deoarece o adresă de interfață uitată este exact ceea ce face calea de întoarcere să ajungă pe dispozitivul greșit.

Verificați ce consideră ASA drept conectat

Dacă ASA are o adresă în subrețeaua de administrare a modulului, ruta sa conectată deține acel prefix. O rută statică spre nucleu nu înlătură proprietatea rutei conectate, așa că pachetul se întoarce la ASA și se oprește acolo. Înregistrarea eșuează apoi într-un punct care nu are nimic de-a face cu acreditările.

Nu concluzionați că o verificare anti-falsificare anume a eliminat pachetul decât dacă aveți în față observațiile dispozitivului însuși. Comparați în schimb interfața de intrare, ruta de destinație selectată și limita de forwarding între administrare și date acceptată pentru acea platformă. Aceste trei fapte expun de obicei conflictul de topologie înainte ca cineva să înceapă resetarea cheilor de înregistrare.

Alegeți o corectare care ține modulul conectat

Eliminarea adresei ASA din acel segment și dezactivarea fizică a unui port partajat nu sunt acțiuni echivalente. Pe platformele unde modulul merge pe aceeași conexiune fizică de administrare, dezactivarea portului elimină singura legătură a modulului — ați transforma o problemă de rutare într-un echipament mort. Preferați schimbarea care redistribuie proprietatea rutării de administrare și pregătiți-o cu proprietarul rețelei prezent.

O a doua opțiune acceptată este să oferiți căii administrative a ASA propriul segment, astfel încât subrețeaua de administrare a modulului să aibă un singur proprietar. Costă o adresă și puțină documentație și înlătură definitiv ambiguitatea. Indiferent de calea aleasă, confirmați apoi că modulul ajunge în continuare atât la FMC, cât și la sursele sale DNS sau NTP.

Înregistrați doar după ce calea este coerentă

După ce calea de întoarcere este curată, planificați conectivitatea de administrare și parametrii de înregistrare conform ghidului de versiune corespunzător pentru FMC și modul. Țineți secretele de înregistrare în afara notițelor și tichetelor partajate și rezistați tentației de a reînregistra ca pas de diagnostic: o cheie nouă pe o cale ruptă produce doar aceeași eroare cu o marcă de timp mai recentă.

Acceptați calea din stiva de administrare a modulului însuși, nu dintr-un ping originat de ASA, deoarece sursa testului este exact ceea ce este suspectat. Notați următorul salt al modulului, selecția VPN a ASA și ruta de răspuns a FMC și păstrați o metodă independentă de recuperare pentru ambele roluri de administrare. Acea înregistrare este cea care separă un transport reparat de o înregistrare reușită.

Când modulul apare în sfârșit în FMC, rulați din nou aceleași trei comenzi și salvați rezultatul lângă schemă. Următoarea persoană care atinge acel segment de administrare va avea nevoie exact de acea comparație.