У модуля 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, повторно выполните те же три команды и сохраните вывод рядом со схемой. Следующему человеку, который коснётся этого сегмента управления, понадобится ровно это сравнение.