.png)
호스트 간에 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 체크섬 문제가 해결되었습니다. 그러나 높은 전송 속도(토폴로지의 veth 쌍 링크에 네트워크 속도/대기 시간이 설치되지 않은 경우 3Gbps)에서는 트래픽의 절반만 기록되는 것으로 나타났습니다. 즉, 인터페이스 캡처 패킷의 발신자 측에서 수신 및 송신 트래픽을 기록하면 1.7GB 덤프를 얻는 반면, 커널 iptables에서 캡처한 트래픽을 기록하면 덤프는 약 900MB입니다. NFLOG와 NFQUEUE 솔루션 모두 전송 속도 제한으로 인해 어려움을 겪고 있습니다.