aabc
Странные цифры...
Использование nat, bond и вланов поверх них, приводит к "странным" цифрам и дублирующимся записям. Для примера, скачивание файла размером в 107.47M с kernel.org в один поток:
# hash a t dev:i,o proto src:ip,port dst:ip,port nexthop tos,tcpflags,options,tcpoptions packets bytes ts:first,last
3 4f70d 0 4 12,10 6 x.x.x.138,45674 151.101.1.176,443 0.0.0.0 40,4,0,0 6 240 347,347
7 6c119 0 0 8,-1 6 172.16.250.2,45674 151.101.1.176,443 0.0.0.0 0,1b,0,f1000000 9690 504706 1306,358
8 09a19 0 0 3,-1 6 151.101.1.176,443 x.x.x.138,45674 0.0.0.0 40,1b,0,f1000000 7484 113291344 1296,347
16 3bf41 0 0 10,-1 6 151.101.1.176,443 x.x.x.138,45674 0.0.0.0 40,1b,0,f1000000 7484 113291344 1296,347
20 4f75d 0 0 8,-1 6 172.16.250.2,45674 151.101.1.176,443 0.0.0.0 40,4,0,0 2 80 347,347
24 55666 0 0 12,-1 6 172.16.250.2,45674 151.101.1.176,443 0.0.0.0 40,4,0,0 2 80 347,347
25 4e97b 0 4 10,12 6 151.101.1.176,443 172.16.250.2,45674 0.0.0.0 40,1b,0,f1000000 122280 345065088 1296,347
28 90c80 0 0 2,-1 6 172.16.250.2,45674 151.101.1.176,443 0.0.0.0 40,4,0,0 2 80 347,347
30 68f9f 0 0 8,-1 6 151.101.1.176,443 x.x.x.138,45674 0.0.0.0 40,1b,0,f1000000 7484 113291344 1296,347
32 526bc 0 4 12,10 6 x.x.x.138,45674 151.101.1.176,443 0.0.0.0 0,1b,0,f1000000 29070 1514118 1306,358
39 1dcfb 0 0 2,-1 6 172.16.250.2,45674 151.101.1.176,443 0.0.0.0 0,1b,0,f1000000 9690 504706 1306,358
40 162fe 0 0 12,-1 6 172.16.250.2,45674 151.101.1.176,443 0.0.0.0 0,1b,0,f1000000 9690 504706 1306,358
Для x.x.x.138(внешний IP после ната) цифры похожи на правду:
16 3bf41 0 0 10,-1 6 151.101.1.176,443 x.x.x.138,45674 0.0.0.0 40,1b,0,f1000000 7484 113291344 1296,347
А для приватного IP кол-во байт и пакетов странные:
25 4e97b 0 4 10,12 6 151.101.1.176,443 172.16.250.2,45674 0.0.0.0 40,1b,0,f1000000 122280 345065088 1296,347
Да, многократное дублирование возможно. Интересно, что у вас количество пакетов увеличилось в 16 раз, а объем трафика всего в 3.
Сейчас пакеты учитываются через тот-же интерфейс ядра, который работает при tcpdump -i any. И я видел очень большое дублирование пакетов в этом случае (в случае бриджей). Например, сделайте tcpdump -i any -e -n -p host 7.7.7.7 и ping -c1 7.7.7.7 - сколько появится строк?
Я, думаю, может стоит сделать возможность привязывать учет пакетов к списку интерфейсов через опцию модуля. Тогда можно будет ставить учет на eth0,eth1 и всё остальное будет игнорироваться.
Вот люди хотят аналогичное https://github.com/aabc/pkt-netflow/issues/2 А вот хотят фильтрацию по маске подсети https://github.com/aabc/ipt-netflow/issues/140
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
15:30:40.179148 In ce:30:49:f3:6f:c8 ethertype 802.1Q (0x8100), length 104: vlan 41, p 0, ethertype IPv4, 172.16.250.2 > 7.7.7.7: ICMP echo request, id 12122, seq 1, length 64
15:30:40.179148 In ce:30:49:f3:6f:c8 ethertype 802.1Q (0x8100), length 104: vlan 41, p 0, ethertype IPv4, 172.16.250.2 > 7.7.7.7: ICMP echo request, id 12122, seq 1, length 64
15:30:40.179148 In ce:30:49:f3:6f:c8 ethertype IPv4 (0x0800), length 100: 172.16.250.2 > 7.7.7.7: ICMP echo request, id 12122, seq 1, length 64
15:30:40.179184 Out 3c:fd:fe:ed:0c:a8 ethertype IPv4 (0x0800), length 100: x.x.x138 > 7.7.7.7: ICMP echo request, id 12122, seq 1, length 64
15:30:40.179188 Out 3c:fd:fe:ed:0c:a8 ethertype 802.1Q (0x8100), length 104: vlan 40, p 0, ethertype IPv4, x.x.x138 > 7.7.7.7: ICMP echo request, id 12122, seq 1, length 64
15:30:40.179192 Out 3c:fd:fe:ed:0c:a8 ethertype 802.1Q (0x8100), length 104: vlan 40, p 0, ethertype IPv4, x.x.x138 > 7.7.7.7: ICMP echo request, id 12122, seq 1, length 64
Но сейчас там другая версия ядра. Попробую сегодня ближе к вечеру откатиться на старую и проверить ещё раз.
Я вижу тут только двухкратное дублирование. Возможно, у any, на каждый вилан, бридж и форвардинг будет дублирование. Если поддержка виланов не включена (в модуле), то пакеты с виланом и без будут сливаться в 1 поток. Остальное, я надеялся будет различимо как разные потоки.
Linux nat-4 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 (2020-06-07) x86_64 GNU/Linux
auto bond0
iface bond0 inet manual
up ifconfig bond0 up
slaves enp4s0f0 enp4s0f1
bond_mode 4
bond_xmit_hash_policy 1
auto bond0.40
iface bond0.40 inet static
address x.x.x.138
netmask 255.255.255.252
gateway x.x.x.137
vlan-raw-device bond0
auto bond0.41
iface bond0.41 inet static
address 172.16.250.1
netmask 255.255.255.252
vlan-raw-device bond0
tcpdump -ni any host 1.1.1.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:05:53.174344 ethertype IPv4, IP 172.16.250.2 > 1.1.1.1: ICMP echo request, id 12445, seq 1, length 64
16:05:53.174344 ethertype IPv4, IP 172.16.250.2 > 1.1.1.1: ICMP echo request, id 12445, seq 1, length 64
16:05:53.174344 IP 172.16.250.2 > 1.1.1.1: ICMP echo request, id 12445, seq 1, length 64
16:05:53.174385 IP x.x.x.138 > 1.1.1.1: ICMP echo request, id 12445, seq 1, length 64
16:05:53.174389 ethertype IPv4, IP x.x.x.138 > 1.1.1.1: ICMP echo request, id 12445, seq 1, length 64
16:05:53.174392 ethertype IPv4, IP x.x.x.138 > 1.1.1.1: ICMP echo request, id 12445, seq 1, length 64
16:05:53.183989 ethertype IPv4, IP 1.1.1.1 > x.x.x.138: ICMP echo reply, id 12445, seq 1, length 64
16:05:53.183989 ethertype IPv4, IP 1.1.1.1 > x.x.x.138: ICMP echo reply, id 12445, seq 1, length 64
16:05:53.183989 IP 1.1.1.1 > x.x.x.138: ICMP echo reply, id 12445, seq 1, length 64
16:05:53.184015 IP 1.1.1.1 > 172.16.250.2: ICMP echo reply, id 12445, seq 1, length 64
16:05:53.184018 ethertype IPv4, IP 1.1.1.1 > 172.16.250.2: ICMP echo reply, id 12445, seq 1, length 64
16:05:53.184021 ethertype IPv4, IP 1.1.1.1 > 172.16.250.2: ICMP echo reply, id 12445, seq 1, length 64
без --enable-vlan:
root@nat-4:~/pkt-netflow# cat /proc/net/stat/pkt_netflow_flows | grep 172.16.250.2
# hash a t dev:i,o proto src:ip,port dst:ip,port nexthop tos,tcpflags,options,tcpoptions packets bytes ts:first,last
7 1a139 0 0 8,-1 1 172.16.250.2,0 1.1.1.1,2048 0.0.0.0 0,0,0,0 1 84 286,286
8 0e942 0 4 9,10 1 1.1.1.1,0 172.16.250.2,0 0.0.0.0 0,0,0,0 3 252 284,284
11 3a76e 0 0 3,-1 1 172.16.250.2,0 1.1.1.1,2048 0.0.0.0 0,0,0,0 1 84 286,286
16 7fbcd 0 0 10,-1 1 172.16.250.2,0 1.1.1.1,2048 0.0.0.0 0,0,0,0 1 84 286,286
с --enable-vlan:
# hash a t dev:i,o vlan type proto src:ip,port dst:ip,port nexthop tos,tcpflags,options,tcpoptions packets bytes ts:first,last
29 8353e 0 4 9,10 41 0800 1 1.1.1.1,0 172.16.250.2,0 0.0.0.0 0,0,0,0 3 252 189,189
77 41189 0 0 10,-1 41 0800 1 172.16.250.2,0 1.1.1.1,2048 0.0.0.0 0,0,0,0 1 84 191,191
94 8fab3 0 0 3,-1 41 0800 1 172.16.250.2,0 1.1.1.1,2048 0.0.0.0 0,0,0,0 1 84 191,191
136 9aaf7 0 0 8,-1 41 0800 1 172.16.250.2,0 1.1.1.1,2048 0.0.0.0 0,0,0,0 1 84 191,191
Пока не могу повторить поведение из первого сообщения со странными цифрам :( Но, похоже что потоки всё равно склеиваются в один, независимо от поддержки вланов.
Возможно, у any, на каждый вилан, бридж и форвардинг будет дублирование.
Скорее - на каждый интерфейс по которому проходит пакет - дублирваоние
Но, похоже что потоки всё равно склеиваются в один, независимо от поддержки вланов.
Да, возможно. pkt-netflow сам анализирует пакет. И возможно с тз. ядра пакет "без вилана" - а на самом деле, заголовок вилана в нем ещё присутствует.
Добрый! Привязка к конкретному порту очень актуальна, если она будет реализована, то можно удалить все модули iptables и использовать nftables при forward. А как этот модуль будет работать при включенной опции offload в nftables? Он увидит пакеты?
