Модуль ASA FirePOWER не має маршруту керування до FMC

FMC показує модуль як недосяжний, реєстрація залишається в очікуванні, а ping зсередини ASA працює бездоганно. У наявному розгортанні ASA FirePOWER така комбінація є нормальною. Модуль має власну адресу керування, власний шлюз за замовчуванням і власні рішення щодо маршрутизації, і спільне використання фізичного з’єднання керування з ASA на деяких платформах не зливає це в один мережевий стек. Два пристрої відповідають із двох різних точок зору на тому самому дроті.

Далі йдеться про модулі, які вже в експлуатації. Визначте модель шасі, тип модуля та підтримувану версію програмного забезпечення, перш ніж застосовувати будь-яку схему портів із посібника.

Намалюйте модуль як окремий хост

Почніть схему з IP-адреси керування модуля, маски та шлюзу за замовчуванням, VLAN, який фактично несе це з’єднання, і адреси FMC, якої треба досягти. Далі в окремому прямокутнику запишіть адреси інтерфейсів ASA і повну таблицю маршрутизації. Якщо два прямокутники зрештою поділяють підмережу з адресами різних власників, ви знайшли цікаву частину проблеми.

Посібник із модуля ASA FirePOWER показує, як схеми портів різняться між платформами, зокрема спільну проводку керування, де ASA й модуль мають окремі адреси в одному сегменті. Ця апаратна схема є вхідними даними для проєктування, а не виноскою.

Знайдіть, де рветься зворотний шлях

Візьміть схему з маршрутизацією через ядро. Модуль надсилає трафік до FMC в ядро Layer 3, ядро пересилає віддалену адресу керування на внутрішній інтерфейс ASA, а VPN майданчика переносить його на інший бік. Потім віддаленому майданчику потрібен маршрут назад у підмережу керування модуля. Кожен крок у цьому ланцюгу може бути правильним, поки цього останнього маршруту бракує, і тому збій так часто виглядає як обірваний тунель.

Прочитайте власний погляд ASA, перш ніж щось змінювати:

show interface ip brief
show route
show running-config interface

Третя команда важлива, бо забута адреса інтерфейсу — це саме те, через що зворотний шлях потрапляє на неправильний пристрій.

Перевірте, що ASA вважає підключеним

Якщо ASA має адресу в підмережі керування модуля, його підключений маршрут володіє цим префіксом. Статичний маршрут у бік ядра не витісняє власність підключеного маршруту, тому пакет повертається до ASA і зупиняється там. Реєстрація потім зривається в точці, яка не має нічого спільного з обліковими даними.

Не робіть висновку, що пакет відкинула конкретна перевірка захисту від підміни, якщо перед вами немає власних спостережень пристрою. Натомість порівняйте вхідний інтерфейс, вибраний маршрут до призначення та підтримувану межу пересилання між керуванням і даними для цієї платформи. Ці три факти зазвичай виявляють конфлікт топології раніше, ніж хтось почне скидати ключі реєстрації.

Виберіть виправлення, яке залишить модуль підключеним

Вилучення адреси ASA з цього сегмента й фізичне вимкнення спільного порту не є рівнозначними діями. На платформах, де модуль іде тим самим фізичним з’єднанням керування, вимкнення порту позбавляє модуль єдиного зв’язку — ви перетворите проблему маршрутизації на мертвий пристрій. Віддайте перевагу зміні, яка перерозподіляє власність маршрутизації керування, і підготуйте її в присутності власника мережі.

Другий підтримуваний варіант — дати адміністративному шляху ASA власний сегмент, щоб у підмережі керування модуля був один власник. Це коштує однієї адреси й трохи документації та назавжди усуває неоднозначність. Який би шлях ви не обрали, після цього підтвердьте, що модуль досі досягає і FMC, і своїх джерел DNS або NTP.

Реєструйте лише після узгодження шляху

Коли зворотний шлях чистий, сплануйте з’єднання керування та параметри реєстрації за відповідним посібником випуску FMC і модуля. Тримайте секрети реєстрації поза спільними нотатками та заявками й опирайтеся спокусі перереєструватися як діагностичному кроку: свіжий ключ на зламаному шляху дає лише той самий збій із новішою позначкою часу.

Приймайте шлях із власного стеку керування модуля, а не з ping, ініційованого ASA, бо джерело тесту — це саме те, що під підозрою. Запишіть наступний крок модуля, вибір VPN на ASA і маршрут відповіді FMC, а для обох ролей керування тримайте незалежний спосіб відновлення. Саме цей запис відокремлює відремонтований транспорт від успішної реєстрації.

Коли модуль нарешті з’явиться у FMC, повторіть ті самі три команди й збережіть вивід поруч зі схемою. Наступній людині, яка торкнеться цього сегмента керування, знадобиться саме це порівняння.