Troubleshooting firewalls

В нескольких предыдущих заметках я рассказывал о различных аспектах настройки firewall устройств Cisco PIX и ASA. Почти всё также относиться к модулю FWSM для 65 серии коммутаторов. Зачастую в заметках просто рассказывалось как настроить какую-либо "фичу", причем в минимальной конфигурации, так как переписывать документацию смысла особого нет, а вот иметь шпаргалочку для быстрого подглядывания например номера порта который необходимо разрешить на firewall для работы HSRP оказалось достаточно удобно.
Сегодня я расскажу о действиях когда что-то идет не так как планировалось. Поскольку последнее время я занимаюсь исключительно с ASA устройствами речь пойдет о них.

Прежде всего необходимо воспользоваться простыми show командами, зачастую с их помощью можно определить источник проблем.
Для поиска проблем при прохождении трафика через firewall крайне полезны команды show xlate и show connection. Первая предназначена для просмотра активных
сетевых трансляций, вторая для просмотра соединений. Почему зачастую для построения соединений нужен NAT и как его правильно настроить модно прочитать в одной из предыдущих заметок. Обращайте внимание на флаги которые появляются при выводе show xlate detail, например можно долго искать проблему в "странно работающем" DNS если не заметить флага "D" при трансляции.

pixasa# sh xlate detail
1 in use, 1 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
r - portmap, s - static
NAT from inside:10.10.11.5 to outside:10.10.11.2 flags sD

Крайне полезная команда show local-host. Показывает не достаточно подробную информацию. Причем не только по соединениям, а по всевозможным лимитам установленным для данного потока. Немного странновая терминилогия, но если верить документации local-host создается для каждого хоста который шлет пакеты на firewall или через него. Что интересно, во втором случае создается два локальных хоста, например как в этом примере. От 10.10.10.2 обращается по telnet к 10.10.11.2, соответственно для каждого могут быть применены свои лимиты. Также команда полезна для просмотра трансляция созданых с помощью Identity NAT.

pixasa# sh local-host
Interface inside: 1 active, 2 maximum active, 0 denied
local host: <10.10.11.2>,
TCP flow count/limit = 1/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 0/unlimited

Conn:
TCP out 10.10.10.2:35803 in 10.10.11.2:23 idle 0:00:00 bytes 73 flags UIOB
Interface outside: 1 active, 1 maximum active, 0 denied
local host: <10.10.10.2>,
TCP flow count/limit = 1/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 0/unlimited

Conn:
TCP out 10.10.10.2:35803 in 10.10.11.2:23 idle 0:00:00 bytes 73 flags UIOB

Команда show asp drop покажет общую статистику о пакетах заблокированных по тем или иными причинам. Например при настройке Unicast Reverse Path Forwarding сколько именно пакетов было заблокировано.
Также крайне полезная информация позволяющая сходу оценить количественные показатели. Сколько было заблокировано ACL (строчка Flow is denied by access rule), а сколько например по причине некорректно установленных опций в пакете (Bad TCP flags).
Примерно как в примере ниже.

pixasa# show asp drop | in Reverse-path

Reverse-path verify failed 15

pixasa# show asp drop | in Bad option length in

Bad option length in TCP 731

Следующая крайне полезная show команда позволить посмотреть насколько интенсивно используется процессор. Вывод очень похож на вывод команды uptime в системах *nix.

pixasa# show cpu usage
CPU utilization for 5 seconds = 9%; 1 minute: 11%; 5 minutes: 7%

Если используются виртуальные firewall, можно посмотреть статистику по конкретному контексту.

pixasa# show cpu context system

CPU utilization for 5 seconds = 6.3%; 1 minute: 7.7%; 5 minutes: 3.8%

show traffic покажет загрузку интерфейсов, может быть задержки происходят просто потому, что не хватает пропускной способности интерфейса?

Следующая show команда будет полезна при анализе причин задержек или дропов на нагруженных устройствах. show block по сути показывает заполненность внутренних буферов. Описание что она конкретно показывает.

Следующая команда проста и универсальна по своей сути. Часто бывает ситуация когда вроде бы всё должно работать, но при этом что-то не работает.
На помощь придет отличный тестировщик любых IP соединений - трассировка пакета.

// Синтаксис достаточно простой. Команда начинается с ключевых слов packet-tracer input
// далее следует указание интерфейса в который будем "инжектить" пакет и необходимые параметры в виде IP адресов и портов.

pixasa# packet-tracer input outside tcp 10.10.10.2 2222 10.10.11.2 23 detailed

Выводом будет пошаговая трассировка пакете через все проверки и лимиты возможные на firewall, проверка NAT если включен nat-control, проверка urpf если включена, конечно же соответствие политике устройства, т.е. access-lists. Приводить здесь вывод я не буду, он достаточно объемен. Лично я не представляю как я раньше без неё обходился, настолько удобным это оказалось.

Что интересно, firewall действительно создает этот пакет запускает его в реальный процессинг, это видно по строчкам лога, в которых можно разглядеть реальные события как
например создание слота трансляции для трассировочного пакета.

Достаточно симпатично packet trace выглядит запущенный в графическом режиме из ASDM.
Если же искусственно запущенный пакет проходит без проблем, а реальные приложения не работают остается только проверенное средство в виде сниффера.
Действительно, может проблема в том, что до firewall пакеты даже не доходят? Есть замечательная команда show capture о которой я уже писал. Повторяться здесь не буду, просто имейте в виду.

Также не следует забывать о существовании просто огромного количества debug команд на все случаи жизни. Здорово облегчить жизнь может использование фильтров для всё тех же команд show.