在Ubuntu系统中，内核参数rp_filter（反向路径过滤）是控制源地址验证的核心开关，它决定了系统在收到一个数据包时，是否会检查这个包的源IP地址是否可以从接收接口路由回去。简单说，rp_filter就是用来防止IP地址伪造的一道关卡。当你把它设置为1时，系统会严格验证源地址的可达性；设置为0时则完全关闭验证；设置为2时则在非对称路由环境下提供更宽松但仍有保护的验证策略。对于大多数Ubuntu服务器来说，把rp_filter设为1是最安全的默认选择，但在多网卡、多路由表、负载均衡等复杂网络场景下，这个参数如果配错了，轻则丢包，重则导致整个网络通信瘫痪。
rp_filter的三种模式到底有什么区别
Linux内核中rp_filter有三个可选值，分别是0、1、2，它们的行为差异非常大，搞清楚这个是配置的前提。
值为0：完全关闭反向路径检查。内核不会对任何入站数据包做源地址验证，所有包都会被接受。这种模式适合NAT网关、负载均衡器或者一些特殊的隧道场景，但安全性最低，容易被IP欺骗攻击利用。
值为1：严格模式。内核会检查数据包的源IP地址，判断从该源IP回包时是否会走同一个接收接口。如果路由表显示回包路径和接收接口不一致，这个包就会被直接丢弃。这是最常用的安全配置，适合单网卡或对称路由的环境。
值为2：松散模式。内核同样做源地址验证，但不要求回包必须走同一个接口，只要源IP地址在系统的任何一个接口上可达就行。这个模式专门为非对称路由设计，比如服务器有多个网卡分别连接不同网段的场景。
如何查看和修改Ubuntu中的rp_filter参数
在Ubuntu系统中，rp_filter参数存在于/proc文件系统中，路径是/proc/sys/net/ipv4/conf/下的各个接口目录。你可以用以下命令查看当前所有接口的rp_filter值：
cat /proc/sys/net/ipv4/conf/all/rp_filter cat /proc/sys/net/ipv4/conf/eth0/rp_filter cat /proc/sys/net/ipv4/conf/default/rp_filter
这里有三个层级：all代表所有接口的默认值，default代表新建接口的默认值，而eth0、eth1这样的具体接口名则是针对单个网卡的设置。具体接口的设置会覆盖all和default的值。
临时修改可以用echo命令直接写入：
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
但这种修改重启后会失效。要永久生效，需要编辑/etc/sysctl.conf或者在/etc/sysctl.d/目录下新建配置文件：
net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.eth0.rp_filter = 1
修改后执行sysctl -p让配置立即生效。
rp_filter对源地址验证的实际工作原理
当一个数据包到达网卡时，内核会提取包的源IP地址，然后查询路由表，看如果要向这个源IP地址发送一个回复包，应该从哪个接口出去。如果查询结果显示回复包应该从当前接收包的同一个接口出去，验证通过；否则就认为这个源IP可能是伪造的，直接丢包并可能记录日志。
这个机制的核心依赖是路由表的正确性。如果你的路由表本身就是错的，或者你的网络拓扑是非对称的（比如请求从eth0进来，但回复要从eth1出去），那么rp_filter=1就会误判正常流量为伪造流量，造成大量丢包。这就是为什么很多运维人员在配置了rp_filter=1之后发现网络突然不通了，其实不是参数有问题，而是网络架构和参数不匹配。
哪些场景下rp_filter=1会导致问题
第一种情况是多网卡服务器。比如一台Ubuntu服务器有eth0连接内网192.168.1.0/24，eth1连接另一个网段10.0.0.0/24。当从eth0收到一个源地址为10.0.0.5的包时，内核查路由表发现去往10.0.0.5应该走eth1，和接收接口eth0不一致，包就被丢了。这种情况应该把对应接口的rp_filter设为2，或者在all上设为2。
第二种情况是使用了策略路由。如果你通过ip rule和ip route做了复杂的路由策略，比如根据源地址或防火墙标记选择不同的路由表，那么默认的rp_filter检查可能会和你的策略路由冲突。这时候需要仔细评估每个接口的rp_filter值，或者干脆设为0。
第三种情况是容器和虚拟化环境。Docker、LXC等容器技术会创建虚拟网卡，容器之间的通信有时候会触发rp_filter的误判。尤其是当容器使用bridge网络模式，宿主机的rp_filter=1可能会把容器发出的包当作伪造包处理。解决办法是针对veth相关接口单独设置rp_filter=0或2。
rp_filter与其他内核安全参数的配合
rp_filter不是孤立工作的，它需要和其他内核参数配合才能构建完整的安全防护体系。以下几个参数建议一起关注：
log_martians：当内核因为rp_filter或其他原因丢弃包时，是否记录日志。建议设为1，方便排查问题。
net.ipv4.conf.all.log_martians = 1
accept_source_route：是否接受带有源路由选项的包。源路由是一种古老的IP选项，可以让发送者指定包的路径，但也是IP欺骗的常用手段。建议设为0。
net.ipv4.conf.all.accept_source_route = 0
accept_redirects：是否接受ICMP重定向消息。攻击者可以通过发送伪造的ICMP重定向来篡改路由表。建议设为0。
net.ipv4.conf.all.accept_redirects = 0
secure_redirects：只接受来自网关的ICMP重定向。设为1可以稍微放宽限制但仍有保护。
net.ipv4.conf.all.secure_redirects = 1
如何诊断rp_filter导致的丢包问题
如果你怀疑是rp_filter在丢包，可以通过以下步骤排查。首先查看内核日志：
dmesg | grep -i "rp_filter\|martian"
如果看到类似"IPv4: martian source"的日志，说明内核确实在因为源地址验证失败而丢包。然后用tcpdump抓包确认包是否真的到达了网卡：
tcpdump -i eth0 -n "not port 22"
如果tcpdump能看到包但应用收不到，同时dmesg有martian日志，基本可以确认是rp_filter在起作用。接下来就是根据网络拓扑调整对应接口的rp_filter值。
还有一个实用技巧是用ip route get命令模拟内核的路由查询过程，手动验证源地址的回包路径：
ip route get 10.0.0.5 from 192.168.1.100 iif eth0
这个命令会告诉你从192.168.1.100这个地址去往10.0.0.5时，内核会选择哪个接口。如果输出的接口不是eth0，那rp_filter=1就一定会丢包。
生产环境的最佳实践建议
对于单网卡的Ubuntu服务器，直接把all和default都设为1，简单安全。对于多网卡服务器，先梳理清楚每个网卡的流量方向，然后针对性地设置。核心原则是：如果一个接口只负责接收来自特定方向的流量，就用1；如果接口可能收到来自多个方向的流量（非对称路由），就用2；如果是NAT设备或容器宿主机，考虑用0。
另外建议不要只改all和default，而是明确指定每个接口的值。因为默认情况下新创建的接口会继承default的值，但如果你之后加了新网卡忘了配置，就可能出问题。把每个接口都显式写进sysctl配置文件，是更稳妥的做法。
最后提醒一点，rp_filter只是源地址验证的一层防护，它不能替代防火墙规则。真正的安全防护需要iptables或nftables的配合，在链路上做更细粒度的过滤。rp_filter解决的是内核层面的快速丢弃，防火墙解决的是策略层面的精细控制，两者缺一不可。
总结
Ubuntu中的rp_filter参数看似简单，但它的影响贯穿整个网络栈。设置得当可以有效防止IP欺骗和DDoS反射攻击，设置不当则会让正常业务流量被误杀。理解它的三种模式、掌握排查方法、结合实际网络架构做针对性配置，是每个Linux运维和安全工程师的基本功。不要盲目跟风设为1，也不要为了省事全部设为0，根据你的网络实际情况做判断，才是正确的做法。
