ホスト間でTCPデータを送信しています。トポロジは、ネットワークネームスペースとvethペアを使用して生成されます。ホストの場合、NFLOG および tcpdump を使用して、受信および送信パケットを pcap ファイルに保存し、ホストで次のコマンドを実行しました。
# we turn off checksum offload:
sudo ethtool -K veth0 tx off sg off tso off ufo off
# we log packets with nflog:
sudo iptables -A OUTPUT -j NFLOG --nflog-group 17
sudo iptables -A INPUT -j NFLOG --nflog-group 17
# we write the packets:
sudo tcpdump -i nflog:17 -w mypcap.pcap
だからみんなのために出るTCPパケット若いLenのチェックサムは常に間違っています。これはトポロジ内のすべてのホストに当てはまります。出口輸送。着信トラフィックにはそのような問題はありません。これは、私が確認したように（NFLLOGを介さずにホストインターフェイスでtcpdumpを使用して定期的にキャプチャします）、送信トラフィックがホストインターフェイスを離れるときにチェックサムが変更されたためです。
NLOGを使用してキャプチャされた送信者（11.0.0.5）のPcap：
送信者インターフェイスで定期的にキャプチャされた送信者のPcap（11.0.0.5）：
NLOGを使用してキャプチャされた受信機（11.0.0.1）のPcap：
受信機インターフェイスで定期的にキャプチャされる受信機（11.0.0.1）のPcap：
したがって、上記のように、iptables NFLOGによってキャプチャされたpcapの場合、Lenが0のすべての送信TCPパケットに対してTCPチェックサムが正しくありません。なぜですか？
興味を持ってくれてありがとう！
ベストアンサー1
問題の解決策を見つけました。 NFLLOGの代わりにiptables NFQUEUEを使用できます。 TCPチェックサムの問題を解決することに加えて、この方法の利点は、キャプチャされたパケットに「Linux Netfilter NFLOG」リンク層ヘッダーがないことです。つまり、生成された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
この問題を解決するために、私は解決策を見つけるのに長い時間を費やしました。tcpdump 履歴に Tc qdisc 遅延が表示されない。まず、解決策はかなりよさそうだ。リンク層ヘッダーがないため、ダンプファイルが小さくなり、TCPチェックサムの問題が修正されました。ただし、高速転送速度（トポロジのベスペアリンクにネットワーク速度/待機時間がインストールされていない場合は3 Gbps）では、トラフィックの半分しか記録されていません。つまり、インターフェイスキャプチャパケットの送信側で受信および送信トラフィックを記録すると1.7 GBのダンプが得られ、カーネルiptablesでキャプチャされたトラフィックを記録するとダンプは約900 MBです。 NFLOG ソリューションと NFQUEUE ソリューションの両方が、伝送速度の制限のために困難に直面しています。