Документация NetAMS

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

• 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

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

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 8.00 KByte (default)

— -----------------------------------------------------------

[1948] local 192.168.56.1 port 3027 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[1948] 0.0–1.0 sec 97.8 MBytes 821 Mbits/sec

[1948] 1.0–2.0 sec 96.1 MBytes 807 Mbits/sec

[1948] 2.0–3.0 sec 97.7 MBytes 820 Mbits/sec

[1948] 3.0–4.0 sec 93.0 MBytes 780 Mbits/sec

[1948] 4.0–5.0 sec 93.2 MBytes 782 Mbits/sec

[1948] 5.0–6.0 sec 96.9 MBytes 813 Mbits/sec

[1948] 6.0–7.0 sec 98.4 MBytes 825 Mbits/sec

[1948] 7.0–8.0 sec 97.4 MBytes 817 Mbits/sec

[1948] 8.0–9.0 sec 96.0 MBytes 806 Mbits/sec

[1948] 9.0–10.0 sec 98.2 MBytes 824 Mbits/sec

[1948] 0.0–10.0 sec 965 MBytes 808 Mbits/sec

Как видим, скорость передачи данных через локальный виртуальный интерфейс просто гигантская. Пробуем, как передаются данные между Windows и установленной FreeBSD, через VmWare, безо всяких побочных эффектов (NeTAMS и модуль ядра выключены):

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 51925 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 27.6 MBytes 232 Mbits/sec

[ 3] 1.0–2.0 sec 28.4 MBytes 238 Mbits/sec

[ 3] 2.0–3.0 sec 28.1 MBytes 236 Mbits/sec

[ 3] 3.0–4.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 4.0–5.0 sec 28.4 MBytes 238 Mbits/sec

[ 3] 5.0–6.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 6.0–7.0 sec 28.0 MBytes 235 Mbits/sec

[ 3] 7.0–8.0 sec 28.1 MBytes 236 Mbits/sec

[ 3] 8.0–9.0 sec 28.7 MBytes 240 Mbits/sec

[ 3] 9.0–10.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 0.0–10.0 sec 282 MBytes 237 Mbits/sec

Естественно, медленнее. Теперь запустим NeTAMS и модуль ядра вместе, в режиме divert и убедимся, что это была не подстава: