iptable NAT PREROUTING 不生效的接口绑定与顺序问题

PREROUTING链中-i仅匹配入站接口，DNAT必须置于nat表PREROUTING开头、确保ip_forward=1且规则命中，本地回环流量不经过PREROUTING。

PREROUTING 链里 -i 参数只匹配入站接口，不能写成出站接口

很多用户在配置 DNAT 时，误以为 -i 是“流量要从哪个接口出去”，结果填了实际的外网出口（比如 eth1），但 PREROUTING 发生在路由决策前，此时内核还不知道该走哪条路由，-i 只能匹配数据包**真正进入系统的那个物理/虚拟接口**（如 eth0、br-lan、docker0）。如果填错，规则根本不会触发。

实操建议：

• 用 tcpdump -i eth0 port 80 确认目标端口流量是否真从该接口进来
• 查接口名：运行 ip link show 或 cat /proc/net/dev，避免混淆 ens33 和 enp0s3 这类命名差异
• 容器或 K8s 场景下，宿主机 PREROUTING 规则通常需绑定 -i docker0 或 -i cni0，而非 -i eth0

DNAT 必须放在 PREROUTING 链最前面，否则可能被早期规则跳过

iptables 规则按顺序执行，一旦某条规则带 -j ACCEPT、-j DROP 或 -j RETURN，后续规则就不再检查。如果前面有 ACCEPT 已放行原始目的 IP 的包，后面再写 -j DNAT 就完全无效。

常见错误场景：

• 防火墙脚本中先加载了通用白名单规则（如 -A PREROUTING -s 192.168.1.0/24 -j ACCEPT），而你的 DNAT 目标 IP 正好来自这个网段
• 使用了某些发行版预装的防火墙工具（如 ufw、firewalld），它们会在 PREROUTING 插入默认策略，把你的自定义规则压到下面
• 没加 -t nat 表名，误把 DNAT 规则加到了 filter 表的 PREROUTING（该表不支持 DNAT）

验证方法：iptables -t nat -L PREROUTING -n -v，看对应规则的 pkts 列是否为 0；若为 0，说明没命中，优先排查位置和匹配条件。

Curl Http

用于HTTP请求、API测试和文件传输的基础curl命令。

下载

本地进程发往本机 IP 的包不经过 PREROUTING

这是最容易被忽略的底层行为：当源和目的都是本机（比如 curl http://192.168.1.100:8080），内核会走「本地回环路径」，直接进入 INPUT 链，跳过 PREROUTING 和路由决策。所以你在 PREROUTING 写的 DNAT 对这类请求完全无效。

解决路径取决于你要做什么：

• 测试 DNAT 是否生效？必须从**另一台机器**发起请求，不能用 localhost 或本机 IP
• 确实需要本机访问也走 DNAT？改用 OUTPUT 链 + DNAT（仅适用于 IPv4，且需配合 route_localnet=1），例如：iptables -t nat -A OUTPUT -d 192.168.1.100 -p tcp --dport 8080 -j DNAT --to-destination 127.0.0.1:3000
• 更稳妥的做法是让应用直连目标服务，或用 hosts 绑定 + 反向代理，避免强依赖 iptables 回环 DNAT

开启 ip_forward 且确认 sysctl 值未被覆盖

DNAT 后若目标主机不是当前机器，内核必须转发包，否则会被静默丢弃。但仅仅 echo 1 > /proc/sys/net/ipv4/ip_forward 不够——某些系统（如 systemd-networkd、cloud-init、Kubernetes kube-proxy）会在启动后期重置该值。

关键检查点：

• 运行 sysctl net.ipv4.ip_forward，输出必须是 net.ipv4.ip_forward = 1
• 确认 /etc/sysctl.conf 或 /etc/sysctl.d/*.conf 中有 net.ipv4.ip_forward = 1，并执行 sysctl --system 重载
• 云服务器注意：部分厂商（如 AWS EC2）默认关闭转发，且控制台无法直接修改，必须在实例内正确配置并持久化

即使所有规则都对，只要 ip_forward 是 0，DNAT 后的包就会在路由阶段被丢弃，且不会报错，抓包只能看到 SYN 发出、无响应。