Moduł ASA FirePOWER nie ma trasy zarządzania do FMC

FMC pokazuje moduł jako nieosiągalny, rejestracja pozostaje w zawieszeniu, a ping z wnętrza ASA działa bez zarzutu. W istniejącym wdrożeniu ASA FirePOWER ta kombinacja jest normalna. Moduł ma własny adres zarządzania, własną bramę domyślną i własne decyzje routingu, a współdzielenie fizycznego połączenia zarządzania z ASA na niektórych platformach nie scala tego w jeden stos sieciowy. Dwa urządzenia odpowiadają z dwóch różnych punktów widzenia na tym samym kablu.

Poniższe dotyczy modułów już eksploatowanych. Przed zastosowaniem jakiegokolwiek schematu portów z przewodnika ustal model obudowy, typ modułu i obsługiwaną wersję oprogramowania.

Narysuj moduł jako osobny host

Zacznij schemat od adresu IP zarządzania modułu, maski i bramy domyślnej, sieci VLAN, która faktycznie przenosi to połączenie, oraz adresu FMC, do którego trzeba dotrzeć. Następnie w osobnym prostokącie zapisz adresy interfejsów ASA i jego pełną tablicę routingu. Jeśli oba prostokąty ostatecznie dzielą podsieć z adresami różnych właścicieli, znalazłeś interesującą część problemu.

Przewodnik modułu ASA FirePOWER pokazuje, jak układy portów różnią się między platformami, w tym wspólne okablowanie zarządzania, w którym ASA i moduł mają osobne adresy w tym samym segmencie. Ten schemat sprzętowy jest daną wejściową projektu, nie przypisem.

Znajdź miejsce przerwania trasy powrotnej

Weź układ routowany przez rdzeń. Moduł wysyła ruch do FMC do rdzenia Layer 3, rdzeń przekazuje zdalny cel zarządzania do interfejsu wewnętrznego ASA, a VPN oddziału przenosi go na drugą stronę. Zdalna lokalizacja potrzebuje wtedy trasy powrotnej do podsieci zarządzania modułu. Każdy skok w tym łańcuchu może być poprawny, podczas gdy brakuje tej ostatniej trasy, i dlatego awaria tak często wygląda jak zerwany tunel.

Przeczytaj własny widok ASA, zanim cokolwiek zmienisz:

show interface ip brief
show route
show running-config interface

Trzecie polecenie ma znaczenie, ponieważ zapomniany adres interfejsu jest dokładnie tym, co sprawia, że trasa powrotna ląduje na niewłaściwym urządzeniu.

Sprawdź, co ASA uznaje za podłączone

Jeśli ASA ma adres w podsieci zarządzania modułu, jego podłączona trasa jest właścicielem tego prefiksu. Trasa statyczna w stronę rdzenia nie wypiera własności trasy podłączonej, więc pakiet wraca do ASA i tam się zatrzymuje. Rejestracja zawodzi wtedy w punkcie, który nie ma nic wspólnego z poświadczeniami.

Nie zakładaj, że konkretne sprawdzenie anty-spoofingowe odrzuciło pakiet, jeśli nie masz przed sobą własnych obserwacji urządzenia. Porównaj zamiast tego interfejs wejściowy, wybraną trasę do celu i obsługiwaną granicę przekazywania między zarządzaniem a danymi dla tej platformy. Te trzy fakty zwykle ujawniają konflikt topologii, zanim ktokolwiek zacznie resetować klucze rejestracji.

Wybierz poprawkę, która utrzyma moduł połączony

Usunięcie adresu ASA z tego segmentu i fizyczne wyłączenie wspólnego portu nie są równoważnymi działaniami. Na platformach, gdzie moduł jedzie po tym samym fizycznym połączeniu zarządzania, wyłączenie portu usuwa jedyne łącze modułu — zamieniłbyś problem routingu w martwe urządzenie. Preferuj zmianę, która przydziela na nowo własność routingu zarządzania, i przygotuj ją w obecności właściciela sieci.

Drugą obsługiwaną opcją jest danie ścieżce administracyjnej ASA własnego segmentu, aby podsieć zarządzania modułu miała jednego właściciela. Kosztuje to jeden adres i trochę dokumentacji, i na stałe usuwa niejednoznaczność. Niezależnie od wybranej drogi potwierdź potem, że moduł nadal dociera zarówno do FMC, jak i do swoich źródeł DNS lub NTP.

Rejestruj dopiero po uzgodnieniu trasy

Gdy trasa powrotna jest czysta, zaplanuj łączność zarządzania i parametry rejestracji zgodnie z odpowiednim przewodnikiem wydania FMC i modułu. Trzymaj sekrety rejestracji poza współdzielonymi notatkami i zgłoszeniami i oprzyj się pokusie ponownej rejestracji jako kroku diagnostycznego: świeży klucz na zerwanej trasie daje tylko tę samą awarię z nowszą sygnaturą czasu.

Przyjmuj trasę ze stosu zarządzania samego modułu, a nie z pingu inicjowanego przez ASA, ponieważ źródło testu jest właśnie tym, co budzi podejrzenia. Zanotuj następny skok modułu, wybór VPN w ASA i trasę odpowiedzi FMC, i utrzymuj niezależną metodę odzyskiwania dla obu ról zarządzania. To właśnie ten zapis oddziela naprawiony transport od udanej rejestracji.

Gdy moduł w końcu pojawi się w FMC, uruchom ponownie te same trzy polecenia i zapisz wynik obok schematu. Następna osoba, która dotknie tego segmentu zarządzania, będzie potrzebować dokładnie tego porównania.