Команда packet-tracer позволяет проверить как ASA обработает пакет не генерируя при этом реальный трафик с соответствующих хостов. ASA сама создает пакет и пропускает его через себя. Вывод команды аналогичен выводу команды show capture с параметром trace (при создании правила capture тоже должен быть указан параметр trace).
В результате выполнения команды будет отображен порядок обработки указанного пакета внутри ASA и результат обработки.
Примечание: Не стоит путать утилиту с одноименным симулятором сети Cisco Packet Tracer.
В этой статье описывается утилита ASA packet-tracer. Команда появилась в версии 7.2(1) и доступна на PIX и ASA.
Capture позволяет перехватить трафик проходящий через ASA. Однако, при тестировании настроек или поиске неисправностей не всегда есть возможность или не всегда удобно для проверки генерировать соответствующий трафик через ASA.
При поиске неисправностей packet tracer один из самых удобных инструментов. Он не разрешит ситуации с какими-то неправильными настройками на других устройствах, но, по крайней мере, позволяет проверить пройдет ли пакет через ASA и, если нет, то почему он был отброшен.
Так как packet-tracer генерирует указанный пакет, то информацию о нём можно посмотреть в различной статистике, счётчиках, таблицах трансляции. Например, если необходимо проверить работу ACL, то packet-tracer покажет прошел трафик или нет и, кроме того, в соответствующем правиле изменятся счетчики ACL в команде show access-list.
Кроме того, команда packet-tracer может использоваться в связке с capture. Даже если при перехвате трафика не использовался параметр trace, с помощью packet-tracer можно получить аналогичный вывод для реального пакета.
Примечание: Утилита packet tracer доступна и в веб-интерфейсе ASDM.
Синтаксис команды
Синтаксис команды немного меняется в зависимости от того пакет какого протокола надо сгенерировать. Тут описаны общие параметры, а в следующих разделах синтаксис команды для соответствующих протоколов.
ASA1# packet-tracer input <intf-name> <protocol> <sIP> <protocol-param> <dIP> [detailed|xml]
Общие параметры команды packet-tracer:
- intf-name — имя интерфейса ASA через который входит пакет,
- protocol — протокол, который будет использоваться:
- TCP,
- UDP,
- RAW IP,
- ICMP,
- protocol-param — параметры, которые зависят от того какой протокол был выбран. Описаны далее в соответствующих разделах,
- sIP — IP-адрес отправителя,
- dIP — IP-адрес получателя,
- detailed — более подробный вывод команды,
- xml — вывод результата в формате xml.
Для TCP/UDP
ASA1# packet-tracer input <intf-name> <tcp|udp> <sIP> <sport> <dIP> <dport> [detailed|xml]
Параметры для TCP/UDP:
- tcp|udp — соответственно протокол TCP или UDP,
- sport — TCP или UDP порт отправителя,
- sport — TCP или UDP порт получателя.
Для RAW IP
ASA1# packet-tracer input <intf-name> rawip <sIP> <protocol-id> <dIP> [detailed|xml]
Параметры для rawip:
- rawip — пакет RAW IP,
- protocol-id — номер протокола в IP-пакете.
Для ICMP
ASA1# packet-tracer input <intf-name> icmp <sIP> <type> <code> [identifier] <dIP> [detailed|xml]
Параметры для ICMP:
- type — тип сообщения ICMP,
- code — код сообщения ICMP,
- identifier — идентификатор сообщения ICMP (опциональный параметр, который может быть полезен, если существует перехваченный трафик и есть необходимость проверить прохождение конкретного пакета).
Примеры использования (пакет прошел через ASA)
Вывод команды может отличаться не только в зависимости от настроек ASA, то и в зависимости от того существует ли пакет указанный в packet-tracer в capture, существует ли такая сессия через ASA.
Packet tracer в первую очередь всегда проверяет не перехвачен ли пакет capture и нет ли существующей активной сессии. Если реального пакета нет, то он сам генерирует пакет.
Примечание: Синтаксис команды достаточно простой и интуитивно понятный. В большинстве случаев достаточно просто попробовать её пару раз и использовать в дальнейшей работе.
Далее подробно расписаны варианты вывода команды packet-tracer, в зависимости от различных условий. В случае если вывод команды отличается от ожидаемого (например, есть только указание о том, что трафик разрешен и не показаны детальные шаги), тут можно найти объяснение такого поведения команды.
Реального пакета нет (базовые настройка ASA)
Packet tracer позволяет проверить как ASA обработает определенный пакет не генерируя реальный трафик. Необходимо просто задать параметры пакета в packet-tracer.
Например, необходимо проверить пропустит ли ASA HTTP-соединение с хоста inhost на outhost:
ASA1# packet-tracer input inside tcp 192.168.1.10 60000 192.168.3.10 80 detailed Phase: 1 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found no matching flow, creating a new flow Phase: 2 Type: ROUTE-LOOKUP Subtype: input Result: ALLOW Config: Additional Information: in 192.168.3.0 255.255.255.0 outside Phase: 3 Type: CONN-SETTINGS Subtype: Result: ALLOW Config: class-map any match any policy-map global_policy ASA1# packet-tracer input inside tcp 192.168.1.10 40000 192.168.3.10 80 detail$ Phase: 1 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found no matching flow, creating a new flow Phase: 2 Type: ROUTE-LOOKUP Subtype: input Result: ALLOW Config: Additional Information: in 192.168.3.0 255.255.255.0 outside Phase: 3 Type: CONN-SETTINGS Subtype: Result: ALLOW Config: class-map any match any policy-map global_policy class any set connection decrement-ttl service-policy global_policy global Additional Information: Forward Flow based lookup yields rule: in id=0xcce73c98, priority=7, domain=conn-set, deny=false hits=141, user_data=0xcce73288, cs_id=0x0, flags=0x0, protocol=0 src ip=0.0.0.0, mask=0.0.0.0, port=0 dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0 Phase: 4 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Forward Flow based lookup yields rule: in id=0xcc832798, priority=0, domain=permit-ip-option, deny=true hits=141, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0 src ip=0.0.0.0, mask=0.0.0.0, port=0 dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0 Phase: 5 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Reverse Flow based lookup yields rule: in id=0xcc8b92d8, priority=0, domain=permit-ip-option, deny=true hits=5, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0 src ip=0.0.0.0, mask=0.0.0.0, port=0 dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0 Phase: 6 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 141, packet dispatched to next module Module information for forward flow ... snp_fp_tracer_drop snp_fp_inspect_ip_options snp_fp_tcp_normalizer snp_fp_translate snp_fp_adjacency snp_fp_fragment snp_ifc_stat Module information for reverse flow ... snp_fp_tracer_drop snp_fp_inspect_ip_options snp_fp_translate snp_fp_tcp_normalizer snp_fp_adjacency snp_fp_fragment snp_ifc_stat Result: input-interface: inside input-status: up input-line-status: up output-interface: outside output-status: up output-line-status: up Action: allow
Реального пакета нет (настроен ACL на интерфейсе inside, NAT, статический маршрут)
Например, на ASA выполнены такие настройки:
access-list permit_web extended permit tcp 192.168.1.0 255.255.255.0 any eq www access-group permit_web in interface inside nat (inside) 1 0.0.0.0 0.0.0.0 global (outside) 1 interface route outside 192.168.100.0 255.255.255.0 192.168.3.10
Например, необходимо проверить пропустит ли ASA HTTP-соединение с хоста inhost на хост 192.168.100.10:
ASA1(config)# packet-tracer input inside tcp 192.168.1.10 40000 192.168.100.10 80 Phase: 1 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found no matching flow, creating a new flow Phase: 2 Type: ROUTE-LOOKUP Subtype: input Result: ALLOW Config: Additional Information: in 192.168.100.0 255.255.255.0 outside Phase: 3 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group permit_web in interface inside access-list permit_web extended permit tcp 192.168.1.0 255.255.255.0 any eq www Additional Information: Phase: 4 Type: CONN-SETTINGS Subtype: Result: ALLOW Config: class-map any match any policy-map global_policy class any set connection decrement-ttl service-policy global_policy global Additional Information: Phase: 5 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Phase: 6 Type: NAT Subtype: Result: ALLOW Config: nat (inside) 1 0.0.0.0 0.0.0.0 match ip inside any outside any dynamic translation to pool 1 (192.168.3.1 [Interface PAT]) translate_hits = 2, untranslate_hits = 0 Additional Information: Dynamic translate inhost/40000 to 192.168.3.1/51495 using netmask 255.255.255.255 Phase: 7 Type: NAT Subtype: host-limits Result: ALLOW Config: nat (inside) 1 0.0.0.0 0.0.0.0 match ip inside any inside any dynamic translation to pool 1 (No matching global) translate_hits = 0, untranslate_hits = 0 Additional Information: Phase: 8 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Phase: 9 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 143, packet dispatched to next module Result: input-interface: inside input-status: up input-line-status: up output-interface: outside output-status: up output-line-status: up Action: allow
Так как ASA пропустила пакет через себя, то в ней остается информация о нём. В данном примере информация будет в:
- таблице трансляций,
- таблице соединений,
- счетчиках ACL.
Таблица трансляций:
ASA1(config)# sh xlate 1 in use, 1 most used PAT Global 192.168.3.1(60927) Local inhost(40000)
Таблица соединений:
ASA1(config)# sh conn 1 in use, 9 most used TCP outside 192.168.100.10:80 inside inhost:40000, idle 0:00:06, bytes 0, flags E
Статистика ACL (команда packet-tracer выполнялась один раз):
ASA1(config)# sh access-list permit_web access-list permit_web; 1 elements; name hash: 0xdf51b9bc access-list permit_web line 1 extended permit tcp 192.168.1.0 255.255.255.0 any eq www (hitcnt=1) 0x68878a0f
Существует активная сессия
Если через ASA установлена сессия и в packet-tracer задаются параметры совпадающие с ней, то вывод будет указывать только на то, что такая сессия существует, а путь пакета через ASA отображен не будет. В данном примере правил capture нет.
Существующие сессии через ASA (параметры существующей сессии будут использоваться в правиле packet-tracer):
ASA1# sh conn 8 in use, 9 most used TCP dmz dmzhost:80 inside inhost:58827, idle 0:00:00, bytes 1270, flags UIO
Вывод packet-tracer:
ASA1# packet-tracer input inside tcp 192.168.1.10 58827 192.168.2.10 80 Phase: 1 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 76, using existing flow Result: input-interface: inside input-status: up input-line-status: up Action: allow
Пакет перехвачен capture
В данном примере через ASA была установлена сессия и её вывод был перехвачен capture. Существующие сессии очищены для того чтобы продемонстрировать вывод packet-tracer в этом случае. Вывод указывает на то, что пакет обнаружен в capture (Type: CAPTURE) и показывает каким образом ASA обрабатывала пакет.
Проверка того, что информация перехвачена capture:
ASA1# sh capture capture web_cap type raw-data access-list web interface inside [Capturing - 49546 bytes]
Очистка сессий:
ASA1# clear conn 6 connection(s) deleted.
Просмотр первого пакета сессии (параметры перехваченной сессии будут затем использоваться в правиле packet-tracer):
ASA1# sh capture web_cap count 1 176 packets captured 1: 10:54:35.317061 192.168.1.10.58831 > 192.168.2.10.80: S 1880536908:1880536908(0) win 65535 <mss 1460,nop,wsca
Вывод packet-tracer:
ASA1# packet-tracer input inside tcp 192.168.1.10 58831 192.168.2.10 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found no matching flow, creating a new flow Phase: 4 Type: ROUTE-LOOKUP Subtype: input Result: ALLOW Config: Additional Information: in 192.168.2.0 255.255.255.0 dmz Phase: 5 Type: CONN-SETTINGS Subtype: Result: ALLOW Config: class-map any match any policy-map global_policy class any set connection decrement-ttl service-policy global_policy global Additional Information: Phase: 6 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Phase: 7 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: Phase: 8 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Phase: 9 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: Phase: 10 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 85, packet dispatched to next module Result: input-interface: inside input-status: up input-line-status: up output-interface: dmz output-status: up output-line-status: up Action: allow
Существует активная сессия и пакет перехвачен capture
В данном примере через ASA была установлена сессия и её вывод был перехвачен capture. Отображены существующие сессии. Вывод packet-tracer указывает на то, что пакет обнаружен в capture (Type: CAPTURE).
Проверка того, что информация перехвачена capture:
ASA1# sh capture capture web_cap type raw-data access-list web interface inside [Capturing - 48613 bytes]
Просмотр существующих сессий:
ASA1# sh conn 7 in use, 7 most used TCP dmz dmzhost:80 inside inhost:58811, idle 0:00:04, bytes 1649, flags UIO
Просмотр первого пакета сессии (параметры перехваченной сессии будут затем использоваться в правиле packet-tracer):
ASA1# sh capture web_cap count 1 173 packets captured 1: 10:49:48.527728 192.168.1.10.58811 > 192.168.2.10.80: S 2703056722:2703056722(0) win 65535 <mss 1460,nop,wsca
Вывод packet-tracer:
ASA1# packet-tracer input inside tcp 192.168.1.10 58811 192.168.2.10 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 60, using existing flow Phase: 4 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Result: input-interface: inside input-status: up input-line-status: up Action: allow
Примеры использования (пакет не прошел через ASA)
Как правило, в тех случаях когда пакет не проходит через ASA, по выводу packet-tracer можно определить в чём проблема. Однако, не всегда вывод очевиден.
Если вывод packet-tracer не очевиден, то можно посмотреть в последней строке вывода причину по которой был отброшен трафик и почитать описание этих причин для команды show asp drop:
Drop-reason: (acl-drop) Flow is denied by configured rule
Чаще всего, более информативный вывод будет в описании той стадии где packet-tracer отбросил пакет.
Так, например, для приведенного примера финальной причины в виде acl-drop, на промежуточной стадии обработки пакета причина более очевидна. На ASA включен nat-control, а для интерфейса dmz нет соответствующего правила трансляции:
Phase: 8 Type: NAT Subtype: rpf-check Result: DROP Config: nat (dmz) 0 0.0.0.0 0.0.0.0 nat-control match ip dmz any outside any no translation group, implicit deny policy_hits = 0 Additional Information:
Implicit Rule
Если в выводе packet-tracer указано, что причина по которой отброшен трафик Implicit Rule, то это значит, что сработало какое-то «невидимое» правило или правило по умолчанию. Например, это может быть ситуация, когда трафик идёт с более безопасного интерфейса на менее безопасный и не настроены соответствующие ACL на внешнем интерфейсе, которые бы пропускали трафик.
Вывод может быть, например, такой:
Phase: 4 Type: ACCESS-LIST Subtype: Result: DROP Config: Implicit Rule Additional Information:
Эта же причина может встречаться в случае, если на интерфейсе настроен ACL, который запрещает трафик и в конце ACL не указано правило deny ip any any.
Например, на интерфейсе outside настроен такой ACL:
access-list ICMP extended permit icmp any any access-group ICMP in interface outside
Если теперь указать в packet-tracer пакет, который запрещён ACL, то вывод будет таким:
ASA1(config)# packet-tracer input outside udp 192.168.3.10 50000 192.168.1.10 22 Phase: 1 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found no matching flow, creating a new flow Phase: 2 Type: ROUTE-LOOKUP Subtype: input Result: ALLOW Config: Additional Information: in 192.168.1.0 255.255.255.0 inside Phase: 3 Type: ACCESS-LIST Subtype: Result: DROP Config: Implicit Rule Additional Information: Result: input-interface: outside input-status: up input-line-status: up output-interface: inside output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
Если изменить ACL и добавить в конце правило deny ip any any, то в выводе будет явно видно на каком ACL был отброшен трафик.
Измененный ACL на интерфейсе outside:
access-list ICMP extended permit icmp any any access-list ICMP extended deny ip any any access-group ICMP in interface outside
Вывод packet-tracer:
ASA1(config)# packet-tracer input outside udp 192.168.3.10 50000 192.168.1.10 22 Phase: 1 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found no matching flow, creating a new flow Phase: 2 Type: ROUTE-LOOKUP Subtype: input Result: ALLOW Config: Additional Information: in 192.168.1.0 255.255.255.0 inside Phase: 3 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group ICMP in interface outside access-list ICMP extended deny ip any any Additional Information: Result: input-interface: outside input-status: up input-line-status: up output-interface: inside output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
Метки: ASA, packet-tracer, troubleshooting
Опубликовано: Безопасность cisco
Ух, какая полезная штука. Спасибо за статью, даже жаль, что нет ASA под рукой чтобы пощупать.
Да, штука хорошая 🙂
Жаль, что в IOS такого нет.