非对称路由与 rp_filter：抓到请求却没有响应

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

rp_filter 是 Linux IPv4 的 Reverse Path Filtering（反向路径过滤）：根据请求源地址的反向可达性检查输入包。它不是端口防火墙，也不是修复回程的替代品。

值	含义
0	不做此检查
1，strict	到请求源地址的最佳反向路径应使用当前入接口
2，loose	请求源地址通过某个接口可达即可

有效值取 conf/all/rp_filter 与入接口值中的较大者；default 是新接口的初始配置，不会自动改写所有既有接口。发行版默认值可能不同，先读取，不猜测。Linux 内核说明

1. 构造确定失败的场景#

沿用策略路由实验；若已清理，先 sudo python3 policy-lab.py setup。以下移除表 200 的规则（已不存在则略过），保留默认经 R1 的错误回程：

sudo ip -n rp-app rule show
# 仅当该条存在时删除，不是让你清空规则集。
sudo ip -n rp-app rule del priority 100 from 198.51.100.10/32 lookup 200
sudo ip netns exec rp-app sysctl -w net.ipv4.conf.all.rp_filter=0
sudo ip netns exec rp-app sysctl -w net.ipv4.conf.eth1.rp_filter=1
sudo ip -n rp-app route get 203.0.113.10 from 198.51.100.10
sudo ip netns exec rp-client curl --noproxy '*' --connect-timeout 2 --max-time 3 --interface 203.0.113.10 http://198.51.100.10:8080/health

预期超时。用 sudo ip netns exec rp-app tcpdump -ni eth1 tcp port 8080 可以抓到请求；抓包点看到包，不代表它已经通过内核检查或到达应用。此时 ss -lnt 仍能看到正常监听，HTTP 服务也没有故障。

2. 用对照实验定位，再修复回程#

仅在本实验接口改为 loose，重跑请求应成功；这用于验证假设，不作为生产的默认修复：

sudo ip netns exec rp-app sysctl -w net.ipv4.conf.eth1.rp_filter=2
sudo ip netns exec rp-client curl --noproxy '*' --fail --max-time 3 --interface 203.0.113.10 http://198.51.100.10:8080/health
# 修复第二条出口的源地址路由；replace 可用于本实验已有的表项。
sudo ip -n rp-app route replace table 200 198.51.100.0/24 dev eth1 src 198.51.100.10
sudo ip -n rp-app route replace table 200 default via 198.51.100.1 dev eth1
sudo ip -n rp-app rule add priority 100 from 198.51.100.10/32 lookup 200
sudo ip netns exec rp-app sysctl -w net.ipv4.conf.eth1.rp_filter=1
sudo ip netns exec rp-client curl --noproxy '*' --fail --max-time 3 --interface 203.0.113.10 http://198.51.100.10:8080/health

验收：strict 恢复后仍成功；源地址选路指向 eth1；R2 能抓到往返包。确有合法非对称设计时，可评估局部 loose，并配合防伪造规则与上游策略；不要一遇到超时就全局设 0。

3. 实际环境额外检查#

# 在故障 Linux 主机只读执行，替换网卡名。
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter
ip -4 rule show
ip -4 route show table all

使用 fwmark（包标记）路由时还应检查 src_valid_mark 是否将标记纳入反向路径查找；不能脱离具体流量与规则盲改。IPv6 不使用这个 IPv4 开关，需要单独检查对应的路由和防火墙。

结束后 sudo python3 policy-lab.py cleanup。把“放宽检查后恢复”和“修好路径后恢复”分别记录，才算定位原因。