Я нашел решение проблемы. Вместо NFLOG можно использовать iptables NFQUEUE. Помимо решения проблемы с контрольными суммами TCP, преимуществом этого метода также является то, что пакеты перехватываются без заголовка «Linux Netfilter NFLOG» Link -Layer, то есть пакеты в результирующем файле pcap -являются просто необработанными -IP-пакеты.
sudo iptables -A INPUT -p tcp -s $receiver-ip -d $sender-ip -j NFQUEUE --queue-num 17
sudo iptables -A OUTPUT -p tcp -s $sender-ip -d $receiver-ip -j NFQUEUE --queue-num 17
sudo iptables -A INPUT -p udp -s $receiver-ip -d $sender-ip -j NFQUEUE --queue-num 17
sudo iptables -A OUTPUT -p udp -s $sender-ip -d $receiver-ip -j NFQUEUE --queue-num 17
sudo tcpdump -i nfqueue:17 -w mypcap.pcap
Я довольно долго искал решение этой проблемы:Задержка Tc qdisc не наблюдается в записи tcpdump . Во-первых, решение показалось мне довольно хорошим :отсутствие заголовков Link -Layer, которые сделали файлы дампа меньше, проблема с контрольной суммой TCP устранена. Но оказалось, что при больших скоростях отправки (3Gbps, когда не установлен netem rate/delay на veth -парных линках топологии )регистрируется только половина всего трафика. То есть, если я записываю входящий и исходящий трафик отправителя, перехватывающего пакеты на интерфейсе, я получаю, например. дамп 1,7 гигабайта, а если я записываю захват трафика из iptables ядра, то дамп составляет около 900 мегабайт. Эта проблема с регулированием скорости отправки возникает как для решений NFLOG, так и для решений NFQUEUE.