ASA REST-API

Reply to ASA REST-API on Mon, 02 Mar 2026 12:02:30 GMT

ngkin2010 — Mon, 02 Mar 2026 12:02:30 GMT

![before.PNG] ![a.PNG] ![after.PNG] Я провел быстрое тестирование, и у меня все работает нормально. Использую запрос PATCH для обмена позициями, как показано на рисунке.

Reply to ASA REST-API on Mon, 02 Mar 2026 12:02:29 GMT

ngkin2010 — Mon, 02 Mar 2026 12:02:29 GMT

Не могли бы вы опубликовать свои данные JSON POST? Например, какой JSON вы отправили в REST API для перемещения позиции ACE?

Reply to ASA REST-API on Mon, 02 Mar 2026 12:02:28 GMT

Denis Orlov — Mon, 02 Mar 2026 12:02:28 GMT

Вот пример существующей структуры ACE JSON: { "kind":"object#ExtendedACE", "selfLink":"
https://x.x.x.x/api/access/in/TP/rules/556116732
", "permit":true, "sourceAddress":{ "kind":"objectRef#NetworkObj", «refLink»: «
https://x.x.x.x/api/objects/networkobjects/MA_TP
», "objectId":"MA_TP" }, «destinationAddress»:{ "kind":"objectRef#NetworkObjGroup", «refLink»: «
https://x.x.x.x/api/objects/networkobjectgroups/ma-vnc
», "objectId":"ma-vnc" }, «sourceService»:{ "kind":"NetworkProtocol", "value":"ip" }, "destinationService":{ "kind":"objectRef#TcpUdpServiceObj", «refLink»: «
https://x.x.x.x/api/objects/networkservices/tcp-1024-65535
», «objectId»: «tcp-1024-65535» }, «active»:true, "remarks":[], «ruleLogging»:{ "logStatus":"По умолчанию", «logInterval»:300 }, «position»:2, «isAccessRule»: true, "objectId":"556116732" } Теперь я пытаюсь PATCH этот ACE, чтобы перенумеровать его. И здесь я получаю следующее: ![Error when PATCH]
Ошибка при PATCH @ngkin2010
Можете ли вы воспроизвести эту ошибку?

Reply to ASA REST-API on Mon, 02 Mar 2026 12:02:27 GMT

Denis Orlov — Mon, 02 Mar 2026 12:02:27 GMT

Да, сейчас я пытаюсь создать дубликат ACE с помощью CLI и получаю следующее сообщение: «ПРЕДУПРЕЖДЕНИЕ: обнаружен дубликат элемента» Таким образом, с помощью CLI я также не могу создать копию существующего ACE в том же ACL. Теперь я попробую объяснить, почему это так важно для меня. Я разрабатываю веб-приложение для нашей команды безопасности, чтобы наши специалисты по безопасности могли управлять ACL без глубоких знаний о том, как это делать в ASA CLI. Команда безопасности попросила меня разработать функцию, которая позволила бы им переупорядочивать ACE в ACL с помощью веб-интерфейса. Итак, в документации Cisco ASA REST-API есть метод «PATCH» для «/api/objects/extendedacls/{aclName}/aces», и в примерах документации говорится, что я могу изменить «позицию» существующего ACE в ACL. Мы начали использовать этот метод для переупорядочения ACE, но столкнулись со следующей проблемой: если ACE имеет разные исходные и конечные службы (здесь я должен отметить, что при создании ACE я всегда определяю только конечную службу), то при попытке использовать метод «PATCH» для изменения позиции ACE я получаю следующую ошибку: string(155) "{"messages":[{"level":"Error","code":"ACCESS-SRC-DST-SERVICE-SAME-TYPE","details":"Destination Service and Source Service should have the same protocol"}]}" Почему Cisco
ввела такое ограничение на API? И есть ли какой-нибудь обходной путь? P.S. Почему это сообщение было помечено как спам? Я написал о вещах, которые хочу понять. И я не пишу неправду.

Reply to ASA REST-API on Mon, 02 Mar 2026 12:02:26 GMT

ngkin2010 — Mon, 02 Mar 2026 12:02:26 GMT

С помощью ASDM я могу успешно создать копию ACE в ACL, то есть я могу создать в ACL два абсолютно одинаковых ACE. Здравствуйте, вы уверены, что смогли создать дубликат ACE? Поскольку это не должно быть разрешено в командной строке. Я предполагаю, что ASDM делал это путем создания разных групп объектов; например: группа объектов сеть DM_INLINE_NETWORK_1 сеть 8.8.8.8 255.255.255.255 группа объектов сеть DM_INLINE_NETWORK_2 сеть 8.8.8.8 255.255.255.255 список доступа ACL разрешить ip расширенный хост 192.168.0.2 группа объектов DM_INLINE_NETWORK_1 список доступа ACL разрешить ip расширенный хост 192.168.0.2 группа объектов DM_INLINE_NETWORK_2 Вы можете следовать той же логике, чтобы сделать это через REST API.

Reply to ASA REST-API on Mon, 02 Mar 2026 12:02:25 GMT

Denis Orlov — Mon, 02 Mar 2026 12:02:25 GMT

Да, вы абсолютно правы. Также необходимо отметить следующее: 1) Если я создаю такой ACE (как в моем примере) с помощью ASDM, то ACE создается с «IP» в качестве SourceService. 2) Но если я создаю тот же ACE с помощью API, то ACE создается с «TCP» в качестве SourceService ![:grinning_face_with_big_eyes:] Таким образом, вы можете столкнуться с этой ошибкой только в том случае, если вы создали ACE в ASDM или CLI, а затем пытаетесь исправить его с помощью API. Если вы создали ACE с помощью API, все будет в порядке, потому что с помощью API ASA модифицирует sourceService соответствующим образом.

Reply to ASA REST-API on Mon, 02 Mar 2026 12:02:24 GMT

ngkin2010 — Mon, 02 Mar 2026 12:02:24 GMT

Я пытаюсь воспроизвести вашу ошибку с помощью следующего ACE (в формате командной строки). ![cli.PNG] и проверяю результат GET, чтобы увидеть, похож ли он на ваш. ![before.PNG] Он похож! Поэтому я продолжаю воспроизводить вашу проблему: ![error.PNG] Теперь я понял вашу проблему. Похоже, это
БАГ
. Потому что, если вы используете «
расширенные группы объектов» (обертывание служб в группу объектов), sourceService будет установлен на «
ip
», а destination — на
objectRef#TcpUdpServiceObj
. Несоответствие протоколов вызвало сообщение об ошибке. Таким образом, если ваша группа объектов (например, tcp-1024-65535) содержит только службу TCP, вы можете использовать следующий метод в качестве обходного пути. Вы также указываете значение протокола в первый раз. ![after.PNG] Тогда все будет работать. ![after2.PNG] Если ваш объект содержит несколько протоколов (например, UDP + TCP), вы все равно
можете
установить PATCH, как показано ниже, даже если он содержит как TCP, так и UDP. {
"position": 2,
"sourceService": {
"value": "tcp"
}
} Рекомендуется открыть заявку TAC, чтобы сообщить об этой ошибке для ее исправления.