доступ к управлению с напрямую подключенного клиента Anyconnect 9.18+

[Stuart Patton]

Здравствуйте, У меня есть FTD2140 с ASA, и я использую management0/0 для доступа к брандмауэру по SSH и HTTP, как локально, так и удаленно. В версии 9.12 мы можем управлять тем же брандмауэром, на который мы подключаемся, с помощью «management-access management». После обновления до версии 9.18 это перестало работать. ChatGPT предполагает, что есть несоответствия при использовании 0.0.0.0 в качестве ACL управления, поэтому я добавил дополнительные правила для диапазонов клиентов Anyconnect (безрезультатно). Он также предполагает, что для трафика плоскости управления требуется идентификационный NAT (хотя наши диапазоны VPN-клиентов в любом случае маршрутизируются в пределах нашего GRT), но это также не дало результата. В другой сессии ChatGPT теперь предполагается, что в версии 9.16 произошли изменения в поведении, которые рассматривают management0/0 как полностью OOB, и трафик плоскости данных просто не может достичь mangement0/0, однако он не может привести никаких примечаний к выпуску или полевых уведомлений, которые бы это подтверждали. Такое же поведение наблюдается и в версии 9.20. Кто-нибудь смог это заставить работать, или нам придется настраивать ACL управления для внутреннего интерфейса специально для удаленной работы? Спасибо

[Stuart Patton]

Хорошо, я нашел обходной путь, который подходит для моей среды. ASA 9.18(2) позволяет создавать интерфейсы loopback, поэтому я создал /32 lo0 и добавил правила ACL управления, которые разрешают доступ из диапазона VPN-клиентов. Его даже не нужно объявлять во внутренней таблице маршрутизации, за исключением, конечно, того, что вам нужно знать, на какой брандмауэр вы попадаете, чтобы знать, использовать ли IP управления или IP loopback. Я полагаю, что мы перейдем на обратную связь для повседневного доступа администратора и оставим управление в качестве запасного варианта для особых случаев, например, если мы меняем конфигурацию OSPF внутри или перезагружаем нижестоящий коммутатор, где находится сосед OSPF.

[Ben Weber]

Привет
[, @Stuart Patton] Cisco реализовала собственный стек SSH (стек CiscoSSH) в версии 9.17. Стек CiscoSSH не поддерживает SSH к другому интерфейсу через VPN (management-access). Стек CiscoSSH стал стандартным в версии 9.19(1). Если вы хотите продолжить использовать эту функцию, выполните команду no ssh stack ciscossh, чтобы отключить службу CiscoSSH и вернуться к стеку ASA SSH по умолчанию. - BW
Пожалуйста, оценивайте посты, если они были полезны.

[Stuart Patton]

Привет, Бен, Стек CiscoSSH не работает и не работал. Это также влияет на HTTPS (ASDM).