— -----------------------------------------------------------
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 и убедимся, что это была не подстава:
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 56639 connected with 192.168.56.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0–1.0 sec 20.9 MBytes 175 Mbits/sec
[ 3] 1.0–2.0 sec 23.4 MBytes 196 Mbits/sec
[ 3] 2.0–3.0 sec 23.5 MBytes 197 Mbits/sec
[ 3] 3.0–4.0 sec 23.5 MBytes 197 Mbits/sec
[ 3] 4.0–5.0 sec 23.6 MBytes 198 Mbits/sec
[ 3] 5.0–6.0 sec 23.6 MBytes 198 Mbits/sec
[ 3] 6.0–7.0 sec 23.4 MBytes 196 Mbits/sec
[ 3] 7.0–8.0 sec 23.8 MBytes 200 Mbits/sec
[ 3] 8.0–9.0 sec 23.6 MBytes 198 Mbits/sec
[ 3] 9.0–10.0 sec 23.3 MBytes 196 Mbits/sec
[ 3] 0.0–10.0 sec 233 MBytes 195 Mbits/sec
freebsd–vm:~/netams#ngctl msg netams: info
Rec'd response «info» (1) from «[3c5]:':
Args: { packets/in=85515 packets/out=169244 mode=2
debug=1 active_flows=4 total_flows=4 default_policy=2 }
Налицо падение производительности на 100*(237–195)/237=17.7% или в 1.2 раза. Теперь заменим фильтрование через модуль ядра на стандартное, через ipfw divert и data–source ip–traffic:
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 и прочее. Все будет быстро и надежно.»
