iptables与IP报文分片浅析

已于 2022-04-07 10:28:27 修改
阅读量3k 收藏 3
点赞数
CC 4.0 BY-SA版权
分类专栏： Linux 文章标签： linux 网络
于 2022-04-07 09:45:21 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_41586875/article/details/124006173
本文详细描述了如何通过iptables配置来测试UDP分片包的处理，发现iptables不会直接过滤IP分片，而是等待内核重组报文。实验结果显示，即使设置了分片过滤选项，完整数据包仍能被接收。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

背景

192.168.0.11（iperf 服务端）
192.168.0.10（iperf 接收端）

​ 系统因会发送大于MTU的UDP组播包，且用户基于都是基于UDP带端口的组播，但是由于UDP分片抓包后，经wireshark分析，分片携带的数据是不会带源目端口，只有首包带，用户怀疑分片被iptables隔离导致无法正常接收数据包，故而进行此次分片iptables过滤测试

配置iptables

# 针对分片过滤的选项 -f
	This means that the rule only refers to second and further IPv4 fragments of fragmented packets.  Since there is no  way  to  tell the  source or destination ports of such a packet (or ICMP type), such a packet will not match any rules which specify them.  When the "!" argument precedes the "-f" flag, the rule will only match head fragments, or unfragmented packets.  This  option  is  IPv4 specific, it is not available in ip6tables
	
# 可见
	1. 当设置 -f后，该规则只适用分片报文的除首报文的后续报文，而且如果指定源目端口的话，该规则无法匹配，因为iptables无法确认分片的源目端口
	2. 当设置 ! -f 后，该规则只会匹配未分片的包，或者分片的首包(首包带源目端口)

# 192.168.0.11,由于设置为发送UDP数据，故而仅设置OUTPUT即可，因接收端端口是随机生成的，这里不做任何规则限制
	#	iptables -A OUTPUT -p udp --dport 8888 -j LOG --log-prefix "UDP-OUTPUT: " --log-level debug
	#	iptables -A OUTPUT -p udp --dport 8888 -j ACCEPT
	# 	iptables -A OUTPUT -p udp -j DROP

# 192.168.0.10, 由于设置为接收UDP数据，故而设置INPUT即可
	iptables -A INPUT -p udp --sport 8888 -j LOG --log-prefix "UDP-INPUT: " --log-level debug
	iptables -A INPUT -p udp --sport 8888 -j ACCEPT
	iptables -A INPUT -p udp -j DROP

设置iperf

# 192.168.0.11
	iperf3 -s -i 1 -B 192.168.0.11 -p 8888 -f M

# 192.168.0.10，从服务端下载数据
	iperf3 -c 192.168.0.11 -p 8888 -l 50000 -t 5 -i 1 -b 10M -f M -u -R

查看tcpdump

192.168.0.10接收端一个完整的UDP报文经tcpdump抓取如下：

17:35:29.013919 IP (tos 0x0, ttl 64, id 21554, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.0.11.ddi-udp-1 > 192.168.0.10.57198: UDP, length 50000
17:35:29.013931 IP (tos 0x0, ttl 64, id 21554, offset 1480, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013934 IP (tos 0x0, ttl 64, id 21554, offset 2960, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013935 IP (tos 0x0, ttl 64, id 21554, offset 4440, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013936 IP (tos 0x0, ttl 64, id 21554, offset 5920, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013937 IP (tos 0x0, ttl 64, id 21554, offset 7400, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013939 IP (tos 0x0, ttl 64, id 21554, offset 8880, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013939 IP (tos 0x0, ttl 64, id 21554, offset 10360, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013940 IP (tos 0x0, ttl 64, id 21554, offset 11840, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013941 IP (tos 0x0, ttl 64, id 21554, offset 13320, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013942 IP (tos 0x0, ttl 64, id 21554, offset 14800, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013943 IP (tos 0x0, ttl 64, id 21554, offset 16280, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013944 IP (tos 0x0, ttl 64, id 21554, offset 17760, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013946 IP (tos 0x0, ttl 64, id 21554, offset 19240, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013976 IP (tos 0x0, ttl 64, id 21554, offset 20720, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.013978 IP (tos 0x0, ttl 64, id 21554, offset 22200, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014000 IP (tos 0x0, ttl 64, id 21554, offset 23680, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014001 IP (tos 0x0, ttl 64, id 21554, offset 25160, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014020 IP (tos 0x0, ttl 64, id 21554, offset 26640, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014040 IP (tos 0x0, ttl 64, id 21554, offset 28120, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014153 IP (tos 0x0, ttl 64, id 21554, offset 29600, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014158 IP (tos 0x0, ttl 64, id 21554, offset 31080, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014159 IP (tos 0x0, ttl 64, id 21554, offset 32560, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014160 IP (tos 0x0, ttl 64, id 21554, offset 34040, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014161 IP (tos 0x0, ttl 64, id 21554, offset 35520, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014162 IP (tos 0x0, ttl 64, id 21554, offset 37000, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014217 IP (tos 0x0, ttl 64, id 21554, offset 38480, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014219 IP (tos 0x0, ttl 64, id 21554, offset 39960, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014220 IP (tos 0x0, ttl 64, id 21554, offset 41440, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014266 IP (tos 0x0, ttl 64, id 21554, offset 42920, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014267 IP (tos 0x0, ttl 64, id 21554, offset 44400, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014268 IP (tos 0x0, ttl 64, id 21554, offset 45880, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014318 IP (tos 0x0, ttl 64, id 21554, offset 47360, flags [+], proto UDP (17), length 1500)
    192.168.0.11 > 192.168.0.10: ip-proto-17
17:35:29.014319 IP (tos 0x0, ttl 64, id 21554, offset 48840, flags [none], proto UDP (17), length 1188)
    192.168.0.11 > 192.168.0.10: ip-proto-17

查看LOG

[root@localhost ~]# dmesg -c
[ 1350.890866] UDP-INPUT: IN=ens33 OUT= MAC=00:0c:29:c5:cf:55:00:0c:29:f1:9e:4a:08:00 SRC=192.168.0.11 DST=192.168.0.10 LEN=32 TOS=0x00 PREC=0x00 TTL=64 ID=38867 DF PROTO=UDP SPT=8888 DPT=51611 LEN=12 
[ 1350.892407] UDP-INPUT: IN=ens33 OUT= MAC=00:0c:29:c5:cf:55:00:0c:29:f1:9e:4a:08:00 SRC=192.168.0.11 DST=192.168.0.10 LEN=50028 TOS=0x00 PREC=0x00 TTL=64 ID=38868 PROTO=UDP SPT=8888 DPT=51611 LEN=50008 
[ 1350.994383] UDP-INPUT: IN=ens33 OUT= MAC=00:0c:29:c5:cf:55:00:0c:29:f1:9e:4a:08:00 SRC=192.168.0.11 DST=192.168.0.10 LEN=50028 TOS=0x00 PREC=0x00 TTL=64 ID=38895 PROTO=UDP SPT=8888 DPT=51611 LEN=50008 
[ 1350.995336] UDP-INPUT: IN=ens33 OUT= MAC=00:0c:29:c5:cf:55:00:0c:29:f1:9e:4a:08:00 SRC=192.168.0.11 DST=192.168.0.10 LEN=50028 TOS=0x00 PREC=0x00 TTL=64 ID=38896 PROTO=UDP SPT=8888 DPT=51611 LEN=50008 
[ 1351.095065] UDP-INPUT: IN=ens33 OUT= MAC=00:0c:29:c5:cf:55:00:0c:29:f1:9e:4a:08:00 SRC=192.168.0.11 DST=192.168.0.10 LEN=50028 TOS=0x00 PREC=0x00 TTL=64 ID=38934 PROTO=UDP SPT=8888 DPT=51611 LEN=50008 
----------------- #剩下的略

注：从上述内核日志可见，iptables过滤方式如下：

  1. 首先发送端发送分片，然后接收端接收分片，该分片从网卡收到后，是可以被tcpdump抓取的，具体tcpdump与iptables关系参见我博客：https://blog.csdn.net/qq_41586875/article/details/123320437
  2. 等数据包到内核后（未设置针对分片过滤），内核对数据包进行报文重组，整合成一个完整的数据包，然后再开始进行iptables过滤，可见iptables并不会对IP分片进行过滤，也即不存在过滤分片了
6万字嵌入式最全八股文面试题大全及参考答案（持续更新）
大模型大数据攻城狮的专栏
07-31 4368
进程上下文定义：进程上下文包含了进程执行时所需的所有信息，包括 CPU 寄存器的值、内核栈、任务控制块（TCB）等。作用：当进程被切换时，需要保存当前进程的上下文，并恢复下一个将要运行进程的上下文。中断上下文定义：中断上下文是指处理中断时 CPU 所处的状态，包括中断发生时的寄存器值等。作用：当中断发生时，CPU 会自动保存当前的上下文信息，并跳转到相应的中断处理程序。示例表格上下文描述进程上下文包含进程执行时的所有相关信息中断上下文处理中断时 CPU 所处的状态线程同步定义。
报文分片（16位分片标识、3位标志、13位片偏移字段详解）
challenglistic的博客
08-31 8758
什么是分片？如何分片？分片以后如何组装？
IPv4之报文分片
九天小哥的专栏
12-29 2611
文章目录重要说明分片时机: ip_finish_output()报文分片: ip_fragment() 分片是网络层的一个重要任务，IPv4需要对两种IP数据包进行分片： 本地产生的数据包； 转发的数据包； 这两种数据包的长度如果超过了出口设备的MTU（或者PMTU），IPv4就会对数据包进行分片处理，使其适配出口设备的MTU。 重要说明 IPv4使用ip_fragment()函数执行分片处理，在设计时，要求该函数能够处理所有的情况。在实现过程中，可能高层协议已经为分片进行了一些准备工作，所以代码也充分
ip6tables 无法基于端口过滤IPv6 分片报文问题解决
fuyuande的博客
12-24 1712
问题现象：使用ip6tables 添加端口过滤规则，只允许指定端口IPv6报文进来，测试结果显示如果是分片报文，只有第一个分片报文能够收到，后续分片会被丢弃。 内核版本：3.4.39 问题原因: 因为同样的规则如果是IPv4分片报文则能够生效，通过分析内核源码，发现问题出在netfilter IPv6连接跟踪模块。 netfilter IPv4 连接跟踪模块会对分片报文进行重组处理使得系统网...
计算机网络基础 IP头部报文；IP的分片；
Murphy_Biao的博客
09-29 3287
Source IP Address：源IP地址Destination IP Address：目标IP地址。
报文分片与重组
ζั͡ޓއއއ๓♥
09-27 3466
MTU是链路层对数据帧的一个限制，所以，IP数据报的分片与重组需要在 网络层 完成。 原始IP报文经分片，只有第一个分片报文带四层信息，后续报文均不带四层信息。 分片后，所有分片报文的IP报头中的源/目的IP等信息都一样（TTL不一定一样，因为不同的分片报文可能会经不同的路由路径达到目的端），不同的地方在于分片标志位和分片偏移量，接收方根据接收到的分片报文的源/目的IP、 IP标识、分片标志位、...
Linux网络层收发包流程及Netfilter框架浅析
j简说Linux的博客
11-19 882
在 TCP/IP 协议框架体系的五层网络模型中，每一层负责处理的数据包协议或类型均存在差异，物理层主要负责在物理载体上的数据包传输，如 WiFi，以太网，光纤，电话线等；数据链路层主要负责链路层协议解析（主要为以太网帧，其他类型此处暂不考虑），网络层主要负责 IP 协议（包括 IPv4 和 IPv6）解析，传输层负责传输层协议解析（主要为 TCP，UDP 等），而传输层以上我们均归类为应用层，主要包括各类应用层协议，如我们常用的 HTTP，FTP，SMTP，DNS，DHCP 等。
Linux 网络层收发包流程及 Netfilter 框架浅析
腾讯技术工程
11-25 1937
本文作者：sivenzhang，腾讯 IEG 测试开发工程师1. 前言本文主要对 Linux 系统内核协议栈中网络层接收，发送以及转发数据包的流程进行简要介绍，同时对 N...
(一)洞悉linux下的Netfilter&iptables：什么是Netfilter？
wjlkoorey的专栏
07-24 978
本人研究linux的防火墙系统也有一段时间了，由于近来涉及到的工作比较纷杂，久而久之怕生熟了。趁有时间，好好把这方面的东西总结一番。一来是给自己做个沉淀，二来也欢迎这方面比较牛的前辈给小弟予以指点，共同学习，共同进步。     能在CU上混的人绝非等闲之辈。因此，小弟这里说明一下：本系列博文主要侧重于分析Netfilter的实现机制，原理和设计思想层面的东西，同时从用户态的iptables到内核
IPv4报文分片基本概念（The Baisc of IPv4 Datagram Fragmentation ）
ROCKY的专栏
02-23 3354
1. IPv4分片 由于数据链路层MTU（最大传输单元）的限制，使用TCP/IP协议传送字节数比较大的数据时，发生IPv4报文分片现象。以太网的MTU=1500B。假设用户数据有5690字节，IPv4 分片如下 分片编号 IPv4报文字节数 分片偏移量(FO) 用户数据字节数 0# 1500=20(IPv4 Header)+8(UDP Header)+1472...
报文，数据报，分片，分组，帧
zaishuowanan的博客
05-15 2240
报文（message）：传输协议交给ip的数据称为报文；典型的报文包含一个传输层首部和应用程序数据； 数据段(segment) 数据段是传输层的信息单元。 数据报（datagram）：在报文首部加上ip首部形成一个数据报； 分片（fragment）：如果在选定网络中，数据报的长度太大，ip就会把数据报分裂成几个分片，每个分片含有它自己的ip首部和一段原来数据报的数据； 分组（packet）：提交给数据链路层进行传送时，一个ip分片或者一个很小的无需分片的ip数据报成为分组； 帧（frame）：..
TCP/IP协议专栏——分片报文详解——网络入门和工程维护必看
热门推荐
weixin_44081384的博客
09-02 1万+
> 一般来说我们都知道MTU是1500字节，因此超过1500字节的数据就需要进行ip分片。 > 包含源和目的端口号的UDP头部只出现在第一个分片里， > 分片由IPv4头部中的标识(Identification)、分片偏移(Fragment offiet)和更多分片(More Fragments, MF)字段控制。
IP报文分片详解
最新发布
qq_44275350的博客
04-11 574
IP报文在传输过程中可能经过不同网络链路，每条链路有**最大传输单元（MTU）**限制。如果报文长度超过MTU，必须分片后传输。若原始报文长度为3000字节，必须分片成多个小于1500字节的片段。总长度 = 3000字节（IP头部20字节 + 数据2980字节）分片数据长度需为8的倍数（分片偏移以8字节为单位）。：分片可能被用于网络攻击（如分片重叠攻击）。：确保大报文能通过不同MTU的网络链路。每个分片需包含IP头部（20字节）。：接收端需缓存和重组分片，消耗资源。：丢失一个分片会导致整个报文重传。
IP报文分片行为(二）
weixin_39662684的博客
05-11 1312
前面介绍了IP报文的格式，下面以IP+UDP报文为例，介绍IP的分片过程，以及相关关键字段的填充. 1.以太网整体报文格式 MTU即LEN/TYPE与FCS之间可以存放的报文长度，超过此长度时，便需要对整体的IP报文做分片处理. 2.分片处理 下面以MTU为100bytes，IP报文头长度为20bytes(没有padding），数据长度为256bytes为例介绍分片过程. 因为（20+8+256)>100，需要对报文做分片处理，分片处理流程如下： 1.首分片包含IP_HDR、UDP_HDR和部分数
iptables详解
cesheng3410的博客
12-13 1465
iptables详解
以太网 以太网帧格式与IP报文分片
Hades_Ling的CSDN博客
11-28 3208
以太网有两种类型的数据帧，一种是Ethernet_II另一种是IEEE802.3。DMAC字段（目标的MAC地址）SMAC字段（发送者的MAC地址）、IP[0x0800]、Data字段（用户数据，其中还包含IP报头、TCP/UDP报头）FCS字段（以太网校验字段，校验方法为循环冗余检验）、数据包分片
iptables的用法
qq_23113053的博客
07-06 403
Netfilter包含有三种表，三种表下共包含有五种链，链下面包含各种规则。即表包含若干链，链包含若干规则。   （一）三种表为：filter   nat  mangle  1、filter:处理与本机有关的数据包，是默认表，包含有三种链：input   output forward  2、nat表：与本机无关。主要处理源与目的地址IP和端口的转换。有三种链：prerouting  post
1.2　使用iptables进行包过滤
y97523的专栏
11-14 890
 透过iptables防火墙用户可对与Linux系统进行交互的IP数据包执行高度的控制，而且这一控制是在Linux内核中实现的。由iptables构建的策略就像一个精力旺盛的交警——不允许通过的数据包将被湮没并不再出现，而符合要求的数据包将继续它们快乐的旅程或经过修改以符合本地网络的要求。iptables策略是由一组有序的规则建立的，它告诉内核应如何处理某些类别的数据包。每一个iptabl
Linux防火墙iptables：禁IP与解封命令实战
本文档详细讲解了如何在Linux系统中利用iptables防火墙进行IP的禁用和解禁操作，这对于服务器安全管理和应对网络攻击非常重要。Linux防火墙iptables是一个强大的工具，用于管理网络包过滤规则，主要负责入站流量的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

旺仔_牛奶

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值