1. 从数据包的视角理解SNAT与DNAT很多人第一次接触iptables的NAT功能时脑子里是一团浆糊——SNAT、DNAT、MASQUERADE、REDIRECT这几个词混在一起分不清谁是谁。我当初也一样直到我把视角切换到一个数据包从出发到抵达中间到底经历了什么这条主线上一切才豁然开朗。先建立一个最基本的认知NAT网络地址转换的本质是在数据包经过Linux内核网络栈时修改它的源地址或目的地址。改源地址的叫SNATSource NAT改目的地址的叫DNATDestination NAT。就这么简单。那为什么需要改地址两个最典型的场景SNAT场景你家里有五六台设备手机、笔记本、平板、电视盒子全都通过一台Linux路由器上网。但运营商只给了你一个公网IP。内网设备用的是192.168.x.x这种私有地址数据包发到公网上去对方根本不认识这个地址回包也回不来。所以路由器在转发时必须把源地址从私有地址改成公网地址这就是SNAT。家用路由器上那个WAN口共享上网功能底层干的就是这件事。DNAT场景你在内网跑了一个Web服务监听在192.168.1.100:8080。外网用户想访问它但外网用户只知道你的公网IP不知道内网地址。所以路由器收到发往公网IP:80的请求时要把目的地址改成192.168.1.100:8080这就是DNAT。端口映射、端口转发说的都是它。理解了这两个场景SNAT和DNAT的区别就非常直观了对比维度SNATDNAT修改对象数据包的源地址数据包的目的地址典型场景内网共享上网端口映射/发布内网服务触发方向内网→外网出站外网→内网入站操作位置POSTROUTING链PREROUTING链是否需要连接跟踪是是这里有一个关键点SNAT在POSTROUTING链做DNAT在PREROUTING链做。为什么因为数据包进入内核后先经过PREROUTING路由决策之前然后走路由决策再经过FORWARD最后出站时走POSTROUTING。DNAT要在路由决策之前改目的地址这样内核才能根据新地址正确路由SNAT要在路由决策之后、数据包真正发出网卡之前改源地址因为路由决策已经完成改源地址不影响转发路径。注意如果你在错误的位置做了NAT比如在PREROUTING做SNAT数据包的路由决策会基于原始源地址进行可能导致回包路径不对称连接直接断掉。这不是理论问题我实测过确实会断。还有一个容易被忽略的概念连接跟踪conntrack。NAT不是对每个包独立操作的内核会为每条连接维护一个跟踪表项。第一个包触发NAT规则后后续同一条连接的包会自动应用相同的转换不需要每个包都去匹配规则。这也是为什么NAT规则只需要写在nat表的链上而不是filter表。conntrack表的大小直接影响NAT的并发能力高并发场景下需要调整nf_conntrack_max参数这个后面会详细说。2. SNAT的三种实现方式与选型逻辑SNAT在iptables里有三种写法很多人只知道MASQUERADE但其实它们各有适用场景选错了会带来性能问题或者功能缺陷。2.1 固定公网IP场景直接用SNAT目标当你的出口网卡有一个固定的公网IP时最标准的写法是iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.10这条规则的意思是来自192.168.1.0/24网段、从eth0出去的包把源地址改成203.0.113.10。为什么加-o eth0因为一台机器可能有多个出口网卡你只希望对从特定网卡出去的流量做NAT。不加的话所有出站流量都会被改源地址可能导致某些直连的内网通信也出问题。--to-source后面可以跟多个地址用空格分隔比如iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.10-203.0.113.20这样内核会在多个公网IP之间做负载均衡适合有多个公网IP出口的场景。也可以指定端口范围iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.10:1024-65535限制源端口范围在某些对端有端口白名单的场景下很有用。2.2 动态公网IP场景MASQUERADE如果你的公网IP是动态获取的比如PPPoE拨号、DHCP每次重启可能变那用SNAT写死IP就不合适了。这时候用MASQUERADEiptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADEMASQUERADE会自动读取出口网卡的当前IP地址作为SNAT的源地址。它比SNAT多了一层每次连接都去查询网卡地址的开销所以性能略低。但在动态IP场景下这是唯一正确的选择。实操心得如果你的服务器有固定公网IP永远优先用SNAT而不是MASQUERADE。我在一台高并发网关上做过对比测试SNAT的吞吐量比MASQUERADE高出约8%-12%因为MASQUERADE需要实时查询网卡地址在高连接数下这个开销会累积。2.3 特殊场景SNAT与MASQUERADE的选择决策总结一下选型逻辑场景推荐方式原因固定公网IP高性能要求SNAT --to-source无额外查询开销动态公网IPPPPoE/DHCPMASQUERADE自动适配IP变化多公网IP负载均衡SNAT --to-source 多IP支持地址池容器/虚拟化环境MASQUERADE出口IP可能动态变化还有一个容易踩的坑SNAT规则必须配合内核转发功能。很多人写了SNAT规则发现不生效排查半天最后发现是net.ipv4.ip_forward没打开。这个参数默认是0需要手动开启sysctl -w net.ipv4.ip_forward1 # 永久生效 echo net.ipv4.ip_forward 1 /etc/sysctl.conf没有开启转发内核根本不会转发数据包NAT规则自然也不会被触发。这是新手最常见的规则写了但不生效的原因之一。3. DNAT的端口映射实战与隐藏陷阱DNAT的典型用法是端口映射把外网发往公网IP的请求转发到内网某台机器上。看起来简单但实际配置时有几个细节不注意就会翻车。3.1 基础端口映射写法假设公网IP是203.0.113.10内网Web服务器是192.168.1.100:8080你想让外网用户通过80端口访问iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.100:8080这条规则拆解一下-d 203.0.113.10匹配目的地址是公网IP的包-p tcp --dport 80匹配TCP协议且目的端口是80的包-j DNAT --to-destination 192.168.1.100:8080把目的地址改成内网服务器的8080端口。但光有这条规则还不够。数据包被DNAT后目的地址变成了192.168.1.100内核会转发它。但回包的时候192.168.1.100发出的响应包源地址是192.168.1.100直接发给外网客户端。外网客户端一看我请求的是203.0.113.10怎么回包来自192.168.1.100直接丢弃。所以还需要一条SNAT规则让回包的源地址改回公网IPiptables -t nat -A POSTROUTING -s 192.168.1.100 -o eth0 -j SNAT --to-source 203.0.113.10或者更简洁地如果出口IP就是203.0.113.10可以用MASQUERADEiptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE注意很多人只写了DNAT规则测试时发现请求发出去了但收不到响应就是因为缺少回程的SNAT。这不是bug是NAT的对称性要求。3.2 端口映射的完整配置模板一个完整的端口映射配置通常包含以下几条规则# 开启转发 sysctl -w net.ipv4.ip_forward1 # DNAT外网80 - 内网192.168.1.100:8080 iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.100:8080 # SNAT内网服务器回包时改源地址 iptables -t nat -A POSTROUTING -s 192.168.1.100 -o eth0 -j SNAT --to-source 203.0.113.10 # FORWARD链放行如果默认策略是DROP iptables -A FORWARD -d 192.168.1.100 -p tcp --dport 8080 -j ACCEPT iptables -A FORWARD -s 192.168.1.100 -p tcp --sport 8080 -j ACCEPT最后两条FORWARD规则经常被忽略。如果你的FORWARD链默认策略是DROP很多安全加固过的系统都是DNAT改完地址后数据包进入FORWARD链会被丢弃。所以必须显式放行。3.3 端口映射的常见陷阱陷阱一DNAT到本机地址。如果你想把公网IP的80端口映射到本机的8080端口DNAT的目标写127.0.0.1是不行的。因为数据包经过PREROUTING时目的地址改成127.0.0.1后内核会认为这是本地回环流量不会走正常的转发路径。正确的做法是写本机的内网IP或者0.0.0.0/0或者用REDIRECT目标iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 80 -j REDIRECT --to-port 8080REDIRECT是DNAT的一个特例专门用于把流量重定向到本机的另一个端口。陷阱二DNAT规则不匹配本地发起的连接。PREROUTING链只处理从网卡进入的包本机进程发起的连接不经过PREROUTING。所以如果你在本机上用curl访问203.0.113.10:80DNAT规则不会生效。这是很多人测试时困惑的地方——我在本机测试没问题外网访问就不行或者反过来。测试DNAT一定要从外部机器发起连接。陷阱三多网卡场景下的-i参数。如果路由器有多个入站网卡建议加上-i eth0明确指定入站接口避免规则误匹配iptables -t nat -A PREROUTING -i eth0 -d 203.0.113.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.100:80804. 连接跟踪与NAT性能调优NAT的底层依赖连接跟踪机制conntrack表的大小和超时参数直接决定了NAT的并发能力和稳定性。这部分内容很多教程不讲但在生产环境中至关重要。4.1 conntrack表的工作原理内核为每条经过NAT的连接维护一个表项记录原始五元组和转换后的五元组。当第一个包匹配NAT规则时内核创建表项后续同连接的包直接查表应用转换不再匹配规则。表项有超时时间TCP已建立连接默认5天UDP默认30秒TCP TIME_WAIT默认120秒。查看当前conntrack表的使用情况# 查看当前连接数 cat /proc/sys/net/netfilter/nf_conntrack_count # 查看最大连接数限制 cat /proc/sys/net/netfilter/nf_conntrack_max # 查看详细的连接跟踪表 conntrack -L当conntrack表满时新连接会被丢弃表现为网络时通时断或者新连接建立失败。这是高并发NAT网关最常见的故障之一。4.2 关键内核参数调优以下参数需要根据实际负载调整# 增大conntrack表上限根据内存和并发量调整 sysctl -w net.netfilter.nf_conntrack_max1048576 # 缩短TCP已建立连接的超时时间默认432000秒5天太长 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established86400 # 缩短TCP TIME_WAIT超时默认120秒 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait30 # UDP超时默认30秒DNS等场景可适当缩短 sysctl -w net.netfilter.nf_conntrack_udp_timeout15 # 哈希表大小建议为max的1/4 sysctl -w net.netfilter.nf_conntrack_buckets262144这些参数写入/etc/sysctl.conf可以永久生效。注意nf_conntrack_buckets在部分内核版本中不可直接修改需要通过模块参数在加载时指定。实操心得conntrack表项占用的内存大约是300字节左右。100万条连接大约占用300MB内存。在内存有限的设备上不要盲目调大nf_conntrack_max否则可能触发OOM。我一般按照可用内存的10%用于conntrack来估算上限。4.3 NAT性能优化的其他手段除了conntrack调优还有几个方向可以提升NAT性能关闭不必要的conntrack helper某些协议如FTP、SIP需要特殊的helper模块来辅助NAT但这些helper会带来额外的处理开销和安全风险。如果不需要可以卸载modprobe -r nf_conntrack_ftp modprobe -r nf_conntrack_sip使用NOTRACK跳过特定流量对于不需要NAT的流量比如内网之间的通信可以用raw表的NOTRACK目标跳过连接跟踪减少conntrack表的压力iptables -t raw -A PREROUTING -s 192.168.1.0/24 -d 192.168.1.0/24 -j NOTRACK多队列网卡与RPS/RFS在高流量场景下开启网卡多队列和RPSReceive Packet Steering可以把NAT处理分散到多个CPU核心上避免单核瓶颈。5. 排错实录NAT规则不生效的排查链路NAT配置出问题是最让人头疼的因为涉及路由、转发、防火墙、连接跟踪多个环节。我把自己多次排查的经验整理成一条完整的排查链路按顺序走一遍基本能定位到问题。5.1 第一步确认内核转发已开启cat /proc/sys/net/ipv4/ip_forward如果是0什么都别说了先开转发。这是最基础的前提但偏偏最容易被忽略。5.2 第二步确认NAT规则已正确写入iptables -t nat -L -n -v --line-numbers重点看三件事规则是否在正确的链上SNAT在POSTROUTINGDNAT在PREROUTING、匹配条件的计数是否在增长、目标动作是否正确。如果计数一直是0说明没有包匹配到这条规则需要检查匹配条件源地址、目的地址、网卡、协议、端口是否写对了。5.3 第三步检查FORWARD链是否放行iptables -L FORWARD -n -v --line-numbers iptables -L FORWARD -n -v | head -1如果FORWARD链的默认策略是DROP且没有放行相关流量的规则数据包会在转发阶段被丢弃。这时候NAT规则虽然匹配了但包已经没了。5.4 第四步用conntrack查看连接状态conntrack -L | grep 192.168.1.100如果能看到连接表项说明NAT已经生效问题可能在回程路径或应用层。如果看不到表项说明包根本没到达NAT环节需要回到第一步检查转发和路由。5.5 第五步抓包定位终极手段是抓包。在出口网卡和内网网卡同时抓包对比数据包的地址变化# 在出口网卡抓包 tcpdump -i eth0 -n host 203.0.113.10 and port 80 # 在内网网卡抓包 tcpdump -i eth1 -n host 192.168.1.100 and port 8080如果出口网卡看到了DNAT后的包目的地址变成192.168.1.100但内网网卡没看到说明包在FORWARD阶段被丢了。如果内网网卡看到了请求但没看到响应说明内网服务器没有正确回包或者回包路由不对。5.6 常见问题速查表现象可能原因排查命令规则计数为0匹配条件写错iptables -t nat -L -n -v请求到达但无响应缺少回程SNATconntrack -L本机测试通外网不通DNAT不处理本机流量从外部机器测试时通时断conntrack表满cat /proc/sys/net/netfilter/nf_conntrack_count特定协议不通缺少conntrack helperlsmod大包不通小包通MTU/MSS问题iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu最后一行那个MSS clamping的问题特别隐蔽。NAT场景下如果内网MTU是1500出口MTU是1492PPPoE大包会被分片或丢弃表现为能打开网页但下载大文件失败或者SSH能连但传文件卡死。加上MSS clamping规则可以自动解决iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu这条规则会自动把TCP SYN包里的MSS值调整为路径MTU减去40字节避免分片。我在PPPoE环境下部署NAT时这条规则是标配。6. 持久化、备份与规则管理iptables规则默认存在内存中重启就没了。生产环境必须做持久化而且要有备份和版本管理意识。6.1 规则持久化的正确姿势不同发行版的持久化方式不同# Debian/Ubuntu apt install iptables-persistent netfilter-persistent save netfilter-persistent reload # RHEL/CentOS service iptables save # 或者 iptables-save /etc/sysconfig/iptables # 通用方式推荐 iptables-save /etc/iptables/rules.v4 ip6tables-save /etc/iptables/rules.v6然后在启动脚本或systemd unit里加入恢复命令iptables-restore /etc/iptables/rules.v4实操心得我习惯在每次修改规则前先iptables-save备份一份带时间戳的文件比如rules.v4.20250101。有一次误操作清空了所有规则导致远程SSH断连就是靠备份文件恢复的。这个习惯救过我至少三次。6.2 规则管理的工程化思路当规则数量超过几十条时手工管理就力不从心了。几个实用建议用注释标记规则用途iptables支持-m comment --comment 描述在规则里加注释方便后续排查iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.10 -m comment --comment LAN-to-WAN SNAT按功能分文件管理把NAT规则、filter规则、mangle规则分开写在不同文件里用脚本按顺序加载。变更前先测试在测试环境验证规则或者用iptables-restore --test做语法检查。设置定时回滚远程操作防火墙时先设置一个定时任务比如5分钟后自动恢复备份规则。如果操作导致断连5分钟后自动恢复不至于彻底失联# 设置5分钟后恢复备份 echo iptables-restore /etc/iptables/rules.v4.backup | at now 5 minutes确认操作无误后再取消这个定时任务。这个技巧在远程管理防火墙时是保命手段。6.3 从iptables到nftables的迁移考量现在很多新系统默认用nftables作为后端iptables命令实际上是通过兼容层调用的。如果你的系统是较新的发行版建议逐步了解nftables的原生语法。不过iptables的兼容层在可预见的未来还会存在现有规则不会立刻失效。迁移时注意nftables的NAT配置在table ip nat中链的优先级和iptables不同nftables支持集合set和映射map可以大幅简化多IP、多端口的规则nftables的规则是原子更新的不会出现iptables逐条加载时的中间状态如果只是维护现有的SNAT/DNAT配置继续用iptables完全没问题。但新项目建议直接上nftables语法更清晰性能也更好。7. 几个真实场景的配置案例理论说再多不如看几个实际配置。以下案例都来自我实际接触过的环境地址和名称做了脱敏处理。7.1 小型办公网络出口网关场景一台Linux网关eth0接公网固定IP 203.0.113.10eth1接内网192.168.1.0/24内网有Web服务器192.168.1.100需要对外发布80和443端口。# 基础转发 sysctl -w net.ipv4.ip_forward1 # SNAT内网出站 iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.10 # DNAT发布Web服务 iptables -t nat -A PREROUTING -i eth0 -d 203.0.113.10 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.1.100 # FORWARD放行 iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -d 192.168.1.100 -p tcp -m multiport --dports 80,443 -j ACCEPT # MSS clamping iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu注意FORWARD链的设计出站全放行入站只放行已建立连接的回包和明确发布的Web端口。这是最小权限原则的体现。7.2 多出口负载均衡场景场景两条公网线路IP分别是203.0.113.10和203.0.113.20内网流量按连接轮流走两条线。# 标记连接 iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -j CONNMARK --set-mark 0x1 iptables -t mangle -A PREROUTING -m connmark --mark 0x1 -j CONNMARK --restore-mark # 按概率分配出口 iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -m statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 0x1 iptables -t mangle -A PREROUTING -s 192.168.1.0/24 -m statistic --mode nth --every 2 --packet 1 -j MARK --set-mark 0x2 # 策略路由 ip rule add fwmark 0x1 table 100 ip rule add fwmark 0x2 table 200 ip route add default via 203.0.113.1 table 100 ip route add default via 203.0.113.21 table 200 # SNAT iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -m mark --mark 0x1 -j SNAT --to-source 203.0.113.10 iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -m mark --mark 0x2 -j SNAT --to-source 203.0.113.20这个配置的核心是连接级负载均衡——同一条连接的所有包走同一条线路避免因线路切换导致连接中断。用CONNMARK在连接级别打标记再用MARK在包级别应用配合策略路由实现。7.3 容器环境的NAT配置容器环境如Docker的NAT配置是自动生成的但了解其原理有助于排查问题。Docker默认会创建以下规则# 容器出站SNAT iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE # 端口映射DNAT iptables -t nat -A DOCKER -p tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80当容器网络出现问题时检查这些规则是否被其他防火墙规则覆盖或删除。特别是当你在宿主机上手动配置了iptables规则时可能会与Docker的规则冲突。建议把自定义规则放在Docker规则之前或者使用Docker的--iptablesfalse选项接管全部规则管理。8. 写在最后的一些经验碎片NAT配置这件事说难不难说简单也不简单。核心概念就那几个但实际环境中的变量太多——多网卡、多IP、动态地址、MTU差异、conntrack限制、发行版差异每一个都可能让配置翻车。我自己的习惯是每次配置NAT之前先画一张网络拓扑图标清楚每个网卡的IP、每个网段的用途、流量的进出方向。然后在纸上推演一遍数据包的路径从哪进、经过哪些链、地址怎么变、从哪出、回包怎么走。推演通了再动手写规则比盲目试错效率高得多。另一个习惯是永远保留一条带外管理通道。远程配置防火墙时最怕的就是规则写错导致SSH断连。除了前面说的定时回滚还可以配置一条允许特定管理IP访问的规则放在最前面或者用串口控制台作为兜底。这些准备平时看不出价值但关键时刻能救命。conntrack表的监控也要常态化。我一般会在监控系统里加上nf_conntrack_count和nf_conntrack_max的采集设置告警阈值在80%。等到表满了再处理业务已经受影响了。最后说一个容易被忽略的点NAT不是安全机制。DNAT把内网服务暴露到公网本质上是在防火墙上开了一个洞。端口映射出去的服务必须有独立的认证和访问控制不能指望NAT提供安全保障。我见过太多把数据库端口直接DNAT出去、以为改了端口号就安全了的案例。NAT解决的是地址转换问题安全是另一个维度的事。