анализ возможности блокировки пакета с использованием таблиц юнитов, политик, системных политик, словом всего обычного набора действий. По окончании проверки, формируется решение по данному потоку: 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
callout/1109893465+ active 1, checked 1, queued=0, flushed 0
callout/1109893466+ active 1, checked 1, queued=0, flushed 0
callout/1109893467+ active 1, checked 1, queued=0, flushed 0
callout/1109893468+ active 1, checked 1, queued=0, flushed 0
callout/1109893469+ active 1, checked 1, queued=0, flushed 0
netams: created flow record id=14, hash=00766, time=1109893469, proto=6
netams: created queue 0xc1a15250 for id=14, hash=00766
netams fwreply for entry id=14, flags=0, queue 1/102
netams: flush queue for entry id=14, hash=766, size=1, action=1
netams: created flow record id=15, hash=00254, time=1109893469, proto=6
netams: created queue 0xc1355240 for id=15, hash=00254
netams fwreply for entry id=15, flags=0, queue 1/102
netams: flush queue for entry id=15, hash=254, size=1, action=1
Результаты испытаний
Зачем все это нужно? Чтобы быстрее работало! Ниже приведены результаты небольших стендовых испытаний.
Все работы проводились с ОС FreeBSD 5.3–RELEASE, которая работала внутри виртуальной машины VmWare 4.5.2. Сама виртуальная машина работала на компьютере DUAL P4 Xeon 3.4GHz, 4Gb RAM под управлением Windows Server 2003. Виртуальная машина и хост–машина связаны через виртуальный адаптер vnmat (хотя в тестах трансляции адресов не было).
Скорость передачи данных измерялась при помощи iperf 1.7.0
На самой машине с Windows Server 2003 запущен сервер iperf, там же запускаем клиента:
C:>iperf.exe–c 192.168.56.1–t 10–i 1
