Início / unix / Perguntas / 527786
Accepted
JenyaKh
Asked: 2019-07-01 12:57:30 +0800 CST

Checksum TCP incorreto para pacotes de saída de comprimento zero (capturados com iptables)

  • 772

Eu envio dados TCP entre hosts (a topologia é criada usando namespaces de rede e pares de veth). Para um host, salvo seus pacotes de entrada e saída no arquivo pcap usando NFLOG e tcpdump com os seguintes comandos executados no host:

# 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

Portanto, para todos os pacotes TCP de saída com Len zero , a soma de verificação está sempre errada. Isso é verdadeiro para todos os hosts na topologia para tráfego de saída . Para o tráfego de entrada não existe esse problema. Isso ocorre porque, como verifiquei (capturando regularmente com tcpdump na interface do host em vez de no NFLOG), quando o tráfego de saída está saindo da interface do host, a soma de verificação já está corrigida.

Pcap no remetente (11.0.0.5), capturado com NLOG:

insira a descrição da imagem aqui

Pcap no remetente (11.0.0.5), capturado regularmente na interface do remetente:

insira a descrição da imagem aqui

Pcap no receptor (11.0.0.1), capturado com NLOG:

insira a descrição da imagem aqui

Pcap no receptor (11.0.0.1), capturado regularmente na interface do receptor:

insira a descrição da imagem aqui

Então, como você pode ver nas imagens acima, para pcaps capturados do iptables NFLOG, para todos os pcakets TCP de saída que possuem Len igual a zero, o checksum TCP está errado. Qual pode ser a razão?

Obrigado pela atenção!

linux networking

1 respostas

  1. Best Answer

    Encontrei a solução para o problema. É possível usar o iptables NFQUEUE ao invés do NFLOG. Além de resolver o problema com checksums TCP, a vantagem deste método também é que os pacotes são capturados sem o cabeçalho Link-Layer “Linux Netfilter NFLOG”, ou seja, os pacotes no arquivo pcap resultante são apenas pacotes raw-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

    Eu estava procurando a solução por muito tempo para resolver este problema: Tc qdisc delay not visto na gravação do tcpdump . Primeiro, a solução parecia muito boa para mim: sem cabeçalhos Link-Layer que tornavam os arquivos de despejo menores, problema de soma de verificação TCP curado. Mas descobriu-se que com grandes taxas de envio (3 Gbps quando nenhuma taxa/atraso netem está instalada em links de pares de veth da topologia) apenas metade de todo o tráfego é registrado. Ou seja, se eu gravar o tráfego de entrada e saída no remetente capturando pacotes na interface eu recebo, por exemplo, dump de 1,7 Gigabytes, enquanto se eu gravar o tráfego de captura de iptables do kernel o dump é de cerca de 900 Megabytes. Este problema com a taxa de envio sendo limitada acontece tanto para soluções NFLOG quanto NFQUEUE.

    • 1

relate perguntas