Документация NetAMS - [31]

• если соответствующего потока не найдено, т.е. рассматриваемый пакет–первый в потоке данных (начало соединения), то для данного потока создается очередь. пакет помещается в конец очереди. создается запрос вида FWREQUEST, содержащий заголовки пакета, и передается через контрольный сокет демону netams. заметим, что в этот момент оригинальный IP пакет никуда не передается, он «застревает» в модуле. потоку присваивается статус QUEUED.

• если поток найден, то проверяется его статус:

• QUEUED — рассматриваемый пакет добавляется в конец цепочки пакетов данного потока. при этом делаются проверки на ряд ограничений по количеству потоков/пакетов/байт/очередей, для предотвращения атаки DoS

• PASS — пакет передается дальше

• DROP — пакет уничтожается

Возникает вопрос, что же происходит с пакетами в очереди, и откуда берутся статусы PASS и DROP?

Статус DROP является единственно возможным для режима работы TEE.

Когда демон получает запрос FWREQUEST из модуля ядра, происходит разбор заголовков и полный анализ возможности блокировки пакета с использованием таблиц юнитов, политик, системных политик, словом всего обычного набора действий. По окончании проверки, формируется решение по данному потоку: PASS или DROP, и оно передается обратно в ядро через сообщение FWREPLY. За время такой обработки в ядре уже может накопиться несколько пакетов в очереди для данного потока. По получении ответа от демона, модуль ядра во–первых ставит соответствующий флаг для данного потока, а затем пытается или отправить все пакеты из очереди, или очистить очередь.

Если по каким–то причинам демон недоступен, то по истечении некоторого таймаута (сейчас это NG_NETAMS_DEFAULT_TIMEOUT равный 2 секундам) производится принудительная очистка очереди для потока и принятие «решения по умолчанию» (сейчас: пропускать). Таким образом предотвращается залипание потока и выедание памяти у ядра (что может быть очень опасным!)

В режиме divert, как и в tee, проводится периодическое устаревание потоков и отправка их на учет «наверх», демону.

Рассмотренный механизм работает, по сути, аналогично Multilayer Switching, реализованному в Cisco Catalyst 6000 и подобных ящиках. Там «быстрый» Switch Engine направляет первый пакет потока «медленному» Route Processor, который определяет, куда маршрутизировать пакет, и проводит проверку правил доступа (access lists). Все последующие после ответа пакеты идут через SE напрямую, и только через некоторое время «наверх» передается статистика о прошедшем потоке. В нашем случае решения о маршрутизации принимать не нужно, в роли «быстрого» движка выступает ядро с его механизмом форвардинга пакетов, в роли «медленного» решателя — демон NeTAMS.

Как настроить

Для начала, вам надо скомпилировать netams, как обычно. Получившийся модуль src/ng_netams.ko необходимо переписать в /boot/kernel/

В дистрибутиве есть скрипт addon/netams–netgraph.sh, который устанавливает в ядро сам модуль ng_netams.ko, устанавливает его режим работы (TEE или DIVERT), вывод отладочной информации, производит подключения к другим нодам NETGRAPH (интерфейсу и ng_tee, если надо)

Запускается этот скрипт через

./netams–netgraph.sh start

останавливается через

./netams–netgraph.sh stop

Для настройки самого NeTAMS необходимо добавить соответствующий сервис в /usr/local/etc/netams.cfg:

service data–source 1

type netgraph

source netams: divert

При этом 'netams:' - это имя модуля NETGRAPH, совпадающее с тем, что написано в скрипте netams–netgraph.sh. Не забываем про двоеточие!

Модуль ядра должен быть запущен ДО демона. В противном случае демон не заработает, как следует. Однако, в процессе работы допускается останавливать и запускать демон NeTAMS, равно как и выгружать и загружать снова модуль ядра (при этом будет 20–секундная задержка в приеме статистики).

Как проверить

Если что–то будет идти совсем не так, упадет ядро :) или блокируется весь трафик!

Работу демона netams можно проверить через просмотр состояния сервиса data–source:

netamsctl show ds

Data–source ID=1 type NETGRAPH source netams::9 loop 0 average 0 mcsec

Perf: average skew delay 0 mcsec, PPS: 0, BPS: 0

IP tree: 7 nodes [12] + 4 dlinks [1024] + 4 unodes [24] = 4276 bytes

Flows: 0/0 act/inact entries (0 bytes), 3 flows sent

HASH: size=65536, 0 flows hashed, 0 nodes used, max chain= 0

FIFO: 0/2 used/ready messages, each 108, total 216 bytes

ds_netgraph data messages: 3

netams: mode=2, pkt_rx=201, pkt_tx=169

flows: active(now)=3, queued(now)=0, blocked(total)=0, total=4

Работа модуля ядра видна через ngctl:

ngctl msg netams: info

Rec'd response «info» (1) from «[3bb]:":

Args: { packets/in=254 packets/out=202 mode=2 debug=1 active_flows=3 total_flows=9 default_policy=2 }

При включенной отладке модуля (через ngctl msg netams: debug 1) на консоли и в dmesg видно много подобных строк:

info/1109893460: sent to daemon [961] with error=0

callout/1109893461+ active 1, checked 1, queued=0, flushed 0

callout/1109893462+ active 1, checked 1, queued=0, flushed 0

callout/1109893463+ active 1, checked 1, queued=0, flushed 0

callout/1109893464+ active 1, checked 1, queued=0, flushed 0