Документация NetAMS - страница 41
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 55410 connected with 192.168.56.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0–1.0 sec 2.96 MBytes 24.8 Mbits/sec
[ 3] 1.0–2.0 sec 3.59 MBytes 30.1 Mbits/sec
[ 3] 2.0–3.0 sec 3.73 MBytes 31.3 Mbits/sec
[ 3] 3.0–4.0 sec 3.62 MBytes 30.3 Mbits/sec
[ 3] 4.0–5.0 sec 3.70 MBytes 31.0 Mbits/sec
[ 3] 5.0–6.0 sec 3.69 MBytes 30.9 Mbits/sec
[ 3] 6.0–7.0 sec 3.65 MBytes 30.6 Mbits/sec
[ 3] 7.0–8.0 sec 3.71 MBytes 31.1 Mbits/sec
[ 3] 8.0–9.0 sec 3.71 MBytes 31.1 Mbits/sec
[ 3] 9.0–10.0 sec 3.73 MBytes 31.3 Mbits/sec
[ 3] 0.0–10.0 sec 36.1 MBytes 30.2 Mbits/sec
freebsd–vm:~/netams#ipfw show 10 11
00010 26136 39197956 divert 199 tcp from any to any dst–port 5001
00011 13069 679600 divert 199 tcp from any 5001 to any
В данном случае мы видим потерю производительности на 100*(237–30.2)/237=87.2% или в 8 раз. Выгода налицо!
Заключение
Велосипед мы не изобрели, это понятно. Результаты ожидаемы. Использование модуля ядра более опасно, чем обычного data–source ip–traffic, а уже тем более сбора по libpcap или netflow. В случае ошибок или переполнения буферов зависает ядро вместе со всеми процессами, или блокируются все сокеты. Было проведено тестирование на предмет поддержки «нехороших ситуаций» вроде ping–f или nmap–sS–PS 80–iR 100. Однако стабильность работы не гарантируется, тестируйте модуль со всей осторожностью!
Кто–нибудь особенно умный может спросить: «А собственно зачем вы это делали? Фильтровать можно и в ядре, через тот же ipfw deny, pfctl и прочее. Все будет быстро и надежно.»
Возможно. Однако вам придется как–то синхронизировать таблицу юнитов и политик учета с правилами firewall, фактически городить зоопарк скриптов и дублировать одно и то же дважды. Зачем? Использование NeTAMS позволяет хранить всю информацию о правилах в одном месте, без проблем применяя всякие хитрости вроде break flag, prefix table и срабатывание по времени суток. Совершенно прозрачно работают сервисы квот, системные политики, биллинг, и так далее.
Возможные направления улучшения и развития:
• Создать аналогичный продукт для Linux, видимо на базе ULOG
• Сделать поддержку RAW IP пакетов, PPP и так далее
• Проверить работоспособность в случае нескольких модулей ядра, работающих одновременно
Зачем нужно no–local–pass
Этот параметр при конфигурировании юнита был сделан для того, чтобы предотвратить ненужную маркировку пакета как «локального», если по замыслу он таковым не является. Рассмотрим случай, когда у вас есть некая локальная сеть с непрерывным диапазоном адресов, но вы хотите разрешить пользоваться сервером только тем компьютерам сети, которые определены в конфигурационном файле. При этом хочется считать трафик для всей подсети в целом. Вот типичная конфигурация:
service processor
policy name all–ip target proto ip
restrict all drop local pass
unit net name LAN ip 192.168.1.0 mask 255.255.255.0 acct–policy all–ip
unit host name USER1 ip 192.168.1.10
unit host name USER2 ip 192.168.1.12
unit host name USER3 ip 192.168.1.13
В таком случае, машина из локальной сети с адресом 192.168.1.20 сможет пройти наружу, так как она попадает в сеть LAN (unit net name LAN) и пакеты маркируются локальными (restrict local pass). Вы можете избежать этого, создав группу и пометив все указанные компьютеры из этой подсети как принадлежащие группе, однако есть более красивое решение:
unit net name LAN ip 192.168.1.0
mask 255.255.255.0 no–local–pass acct–policy all–ip
В этом случае пакеты от 192.168.1.20 не будут считаться за локальные и не пропустятся.
OID, их автоматическая генерация и перезагрузки
При создании конфигурационного файла, и при добавлении юнитов вручную oid можно не указывать. При этом значение oid генерируется автоматически, так что если набрать show config, значения oid выставятся каким–то случайным образом. ГАРАНТИРУЕТСЯ уникальность номеров OID. Чтобы после рестарта NeTAMS oid остались теми же (и старая статистика не потерялась), необходимо после редактирования конфига или любых изменений в нем через интерфейс программы набирать save, тогда конфигурационный файл перезапишется на тот, что выполняется в данный момент, вместе со значениями oid, и после рестарта статистика продолжит собираться и суммироваться правильно.