做网络的人几乎没有谁没被NAT转换折腾过。我印象最深的一次是某天下午同事跑来说“内网服务全好好的可外地的人怎么也访问不了”我连上去查了一整天从端口映射看到防火墙最后发现根本不是配置写错而是整个出口根本不在公网上。这类问题十次里有八次都出在NAT转换这一层。这篇内容我会把NAT转换从头到尾讲透它为什么存在、数据包是怎么被改写的、三种模式各自用在哪、连接跟踪表怎么把端口耗尽、端口映射到底怎么配才稳以及NAT穿越时那些“看起来能通、实际上不通”的经典场景。适合刚入门网络运维的同行也适合写业务代码时被NAT坑过的开发朋友看完能独立排查大多数常见问题。1. NAT的本质不是“转换”而是端口上的“替身演出”1.1 为什么必须有NATIPv4地址稀缺的必然选择IPv4协议在设计时并没有预料到互联网会膨胀到今天这个规模32位地址空间最多只能提供约43亿个公网地址。全球设备数量早就超过了这个数字如果每台电脑、手机、摄像头都要占用一个独立公网IP地址在几十年前就该枯竭了。于是设计者划出了一批私有地址段也就是RFC 1918里规定的10.0.0.0/8、172.16.0.0/12和192.168.0.0/16。这些地址只能在局域网内部使用不允许直接在公网路由。问题随之而来内网设备发出去的数据包源地址是私有的公网服务器拿到后根本无法回包因为这样的地址在公网路由表里不存在。NAT转换就是在这个背景下出现的。它让一整片私有网络共用少数几个公网IP出口设备把内网包的源地址改写成公网地址同时记住“这个包曾经从哪台内网机器、哪个端口发出来”等外网回应到达时再顺着记录反推回去把包交给正确的内网设备。如果用生活化的类比NAT就像小区门口的前台住户出去办事时报上自己的房号和身份前台记下来等到访客来找人时前台按记录把访客引到对应住户那里。住户不需要把自己的真实房号告诉全世界访客也只需要认准前台这一个地址就够了。1.2 一次完整的“外出与回信”源NAT视角下的数据包旅程为了讲清楚这个过程我以最常见的场景为例内网电脑访问一个公网网站。假设内网电脑IP是192.168.1.100端口随机选了50000网关是192.168.1.1网关的公网出口IP是203.0.113.5。完整流程拆开来看是这样内网电脑发出TCP SYN包源地址192.168.1.100:50000目的地址是公网网站IP的80端口。网关收到这个包发现源地址属于私有网段于是执行源NAT改造把源地址改成自己的公网IP 203.0.113.5同时从空闲端口里挑一个比如60000把源端口也改掉。网关在连接跟踪表里记下一条记录内网192.168.1.100:50000对应外网203.0.113.5:60000目的地址是某个公网IP的80端口。改写后的包发往公网网站服务器看到的发送方是203.0.113.5:60000于是正常回包回包的目的地址就是203.0.113.5:60000。网关收到回包后查表发现外部端口60000对应的是内网的192.168.1.100:50000于是再把目的地址改回去交给内网电脑。整个过程中内网电脑完全不知道自己的包被改过公网服务器也完全不知道背后还有一台内网设备存在。两边都觉得“我在跟对面直接通信”实际上所有数据都在网关处过了手。这一步的关键是NAT不只改IP还改端口。改端口这件事儿实在太重要了没有端口改写一个公网IP同时只能服务一台内网设备改写了端口之后一个公网IP的65535个端口可以被成百上千台内网设备共享这也是它被称为“端口多路复用”的原因。1.3 反方向的DNAT让外网主动访问内网刚才说的方向是“内网主动外出”由内网发起连接属于源NAT也就是SNAT。另一种常见需求是反向的外部设备要主动访问内网里的一台服务器比如公司内网有一台开发服务器出差在外的同事要连上去用它。这时候内网设备并没有主动向外发任何包连接跟踪表里不可能预先存在映射记录。如果网关不做任何处理外网来的包到达出口后不知道该往哪里转只能被丢弃。解决办法是目的NAT也就是DNAT大家更熟悉的叫法是“端口映射”或“端口转发”。它的工作方式很直接管理人员在网关上配置一条规则声明“公网IP的8443端口 → 内网192.168.1.200的443端口”。外部访问者只要连接出口IP的8443端口网关就把包的目的地址改写成192.168.1.200:443再转进内网。SNAT和DNAT经常同时出现在一条连接里。比如外网设备访问了映射后的内网服务内网服务器回包时网关必须把源地址从192.168.1.200改回成公网IP才能让外网设备按原路收到。也就是说进来的包做一次目的改写出去的包再做一次源改写两个方向缺一不可。2. 三种NAT模式的适用边界从静态映射到端口复用2.1 静态NAT一对一映射适合服务器发布静态NAT的规则最容易被理解一个内网IP固定映射到一个公网IP一对一从不改变。公司或学校如果有多个公网IP资源需要把几台服务器分别对外暴露就会给每台服务器分一个公网IP互相不干扰。这种模式的优点是干净、简单、可预期。每条连接都能直接对应到一个明确的地址日志审计容易做访问控制也容易写规则。缺点是消耗公网IP资源内网有200台设备就要准备200个公网IP对大多数中小型网络来说根本做不到。实际工作中静态NAT最适合的是“必须独享公网IP的业务”比如需要某些特定端口绑定的游戏服务器、某些对IP白名单敏感的对外应用。如果只是普通办公网络几乎不会用它作为整网出口方案。2.2 动态NAT地址池轮转的鸡肋动态NAT配一个公网IP地址池内网设备每次发起连接时网关从池子里挑一个空闲IP分配给它。因为没有做端口复用一个公网IP在一段时间内只能被一个内网设备独占导致并发能力非常差。当一个地址池有10个公网IP最多只能同时支持10台内网设备对外通信。现代办公环境里光手机、电脑、打印机就不止这个数所以动态NAT在纯粹作为出口的场景下几乎已经绝迹了。它真正还有价值的地方往往体现在IPsec类站点间互通的场景中两个分支机构通过加密隧道对接隧道另一端的地址是动态变化的用地址池做绑定能提高兼容性。普通读者不用太关注这个模式理解它“用空闲公网IP做轮转分配”就够了。2.3 NAPT/PAT家庭和办公室最常见的形态NAPT也叫PAT全称是网络地址端口转换。它就是1.2节描述的那种“一个公网IP大量端口复用”的方案。今天你家里的路由器、办公室的出口防火墙、云上的NAT网关默认都是这个模式。它的核心价值在于“挤”地址不够就缩成1个端口总共有65535个大量内网设备共享这些端口资源。网关用一张连接跟踪表维护每个外部端口对应哪台内网设备的哪个连接。只要表足够大、超时设置合理几百人规模的网络用一个公网IP也能跑得动。三种模式的对比直接列出来方便参考模式映射粒度公网IP消耗适用场景主要缺点静态NAT一对一高对外服务器发布公网IP占用大动态NAT地址池映射中特殊隧道对接并发支持差NAPT/PAT端口级复用极低普通办公、家庭网络连接表压力大、外部无法主动访问3. 连接跟踪表NAT的灵魂也是端口耗尽的元凶3.1 五元组与状态表NAT能工作的前提前面反复提到“网关查表”这张表在Linux系统里由netfilter维护叫连接跟踪表通常写作conntrackOpenBSD的pf防火墙里也有对应的状态表概念一致。表里记录的核心是五元组协议、源IP、源端口、目的IP、目的端口。NAT能不能正确转发取决于这张表里的记录是否准确、是否还在有效期内。一次完整的TCP连接从SYN到FIN所有数据包走的都是同一条表项UDP虽然无连接但网关也会用超时时间模拟出“虚拟连接”来维护表项。每条连接在NAT网关上都占了内存不同协议的超时时间不一样。Linux默认的常见超时大概是TCP established约5天UDP约30秒ICMP约30秒。这些数值并非越大越好也不是越小越安全需要结合真实业务调整。3.2 表容量耗尽网速正常但新连接不通的典型故障连接跟踪表的大小是有限制的。Linux上可以通过两条命令查看当前状态# 查看当前跟踪的连接数 cat /proc/sys/net/netfilter/nf_conntrack_count # 查看系统允许的最大连接数 cat /proc/sys/net/netfilter/nf_conntrack_max当跟踪的连接数逼近上限时新连接就无法建立对应的表项数据包会被直接丢弃。表现出来非常诡异网页刷得动但新开一个页面持续转圈ping通但SSH半天连不上视频会议能加入但发起桌面共享就断。因为“已经在表里的旧连接”还在正常转发而“新连接”全部被掐断。我见过最典型的一次某办公室接了三百多台设备出口路由器长期高负载运行突然某天下午所有员工开始反映一些网页打不开、内网办公系统偶尔卡顿。登录设备查看后发现连接跟踪表使用率已经超过95%再继续开会就会直接满表丢包。重启并清理表项只能管几分钟因为设备数量摆在那里接入量一上来表又满了。这种情况下治标方案是调大上限以常见Linux服务器为例# 临时调大重启后失效 sysctl -w net.netfilter.nf_conntrack_max1048576 # 写入配置文件持久化 echo net.netfilter.nf_conntrack_max1048576 /etc/sysctl.conf治本方案是找出谁在大量占用连接表。局域网里最常见的是各种P2P软件、流媒体缓存、以及异常退出的进程不断发起重复连接导致表项堆积。配合老化时间调优比如把UDP超时从30秒调到15秒把TCP established超时从默认的5天调短一些能有效减少僵尸表项。3.3 端口资源与连接数的现实差距理论上一个公网IP有65535个端口最大并发连接数就是65535条。实际上完全达不到这个数字原因有三点第一端口0到1023属于特权端口普通服务一般不会用NAT分配出去也基本避开这些范围。第二大量TCP连接处于TIME_WAIT状态时同一个四元组源IP、源端口、目的IP、目的端口无法立即复用需要等待超时才释放。第三连接跟踪表本身的内存开销很大每条记录几百字节表设置得越大占用的内存越夸张。所以现实是如果一个公网IP背后挂了上千台设备高峰期并发连接数可能会在三五万条就开始出现各种不稳定。遇到这种规模要么减少单IP背后的设备数要么拆分多个公网IP出口要么用专业运营级NAT设备而不是靠一个家用路由器硬撑。4. 实操向的端口映射与NAT类型判定4.1 家用路由器端口转发配置流程把内网服务暴露到公网最常用的方式是配置端口转发。我以一台常见的家用路由器为例完整的稳定配置流程如下给目标内网设备设置固定IP。这一步非常关键如果设备走DHCP动态分配IP一旦变化映射规则就指向了错误的主机。建议在路由器DHCP静态分配里绑定MAC地址确保IP永久不变。登录路由器管理界面找到“端口转发”或“虚拟服务器”菜单。新建规则外部端口填写外网访问时使用的端口内部IP填写上一步固定的内网地址内部端口填写服务实际监听的端口协议按需选择TCP、UDP或TCP/UDP。保存规则并重启路由器。不是所有路由器都需要重启但重启一次能保证配置生效并刷新连接跟踪表里的旧映射。验证先用内网IP直连服务确认服务本身正常然后使用手机流量不连Wi-Fi从外网访问“公网IP:外部端口”做验证。内网访问公网IP验证的做法很多教程会教你但我劝你尽量避免因为大部分路由器不支持NAT回路NAT Loopback从内网访问公网IP时数据包会在出口处打转很容易出现“内网访问自己公网IP失败但外网实际能访问成功”的假象。4.2 内外网端口不一致的隐藏坑端口映射里有个细节容易被忽略外部端口和内网端口可以不一致。绝大多数场景都建议刻意设计成不一致因为这样可以达到“隐藏内网真实端口”的效果。举例来说内网服务器上的服务监听在8080端口外部访问使用8443端口。配置规则时外部端口8443、内部IP填服务器IP、内部端口8080这样外部访问者连的是8443数据进入内网后才被改写成8080。这时候有几个常见坑会同时出现。第一服务监听地址必须包含对外通信的网络接口。如果服务只监听了127.0.0.1那么从内网其他机器访问它的IP都会失败更别说经过NAT转发了查看方法很简单netstat -lntp | grep 8080如果输出里的监听地址是127.0.0.1:8080需要把服务配置改为0.0.0.0:8080让它监听所有接口。第二内网服务器自己的防火墙也要放行对应的内部端口。很多系统默认防火墙只放行22或808080在外部被NAT转进来后又被本机防火墙拦住了一样连不上。第三路由器如果开启了“防火墙防攻击”“WAN侧禁ping”之类的功能要确认这些功能没有把映射端口一并拦掉。4.3 四种NAT类型与判定方法做点对点通信、VoIP、游戏联机这类需求时光知道“做了NAT”还不够还要知道NAT具体是哪一种类型。因为不同NAT类型对外部主动连接的容忍度差别巨大主流分类是四种NAT类型外部设备能否主动连接对“已建立映射的端口”能否被其他主机复用全锥型任意外部主机都可以可以受限锥型仅目标主机可以可以端口受限锥型仅目标主机的目标端口可以可以对称型每次会话都重新分配端口外部基本无法预判前三种统称锥型NAT区别在于对外部数据包的限制严格程度不同但共同点是内网设备对同一个外部地址发起通信时映射的公网端口保持不变。这就让“外部主动连入”成为可能条件是双方都先通过STUN服务器探知自己的公网地址和端口。对称型NAT最麻烦内网设备每对一个不同的外部地址发起通信网关都会重新分配一个新的公网端口导致外部设备无法根据已知的“公网地址:端口”反向连入。这也是很多P2P联机失败、某些视频会议无法直连的根源。判断自己的NAT类型可以在智能手机上下载一个打洞测试工具也可以在内网电脑上访问提供NAT类型检测的网站。检测网站的原理很巧妙它通过服务器A和服务器B配合发起探针观察内网设备展示的公网地址和端口是否存在差异。如果对服务器A和对服务器B展示的端口不一样基本可以确定是对称型NAT。4.4 UPnP和NAT-PMP自动映射的利与弊UPnP和NAT-PMP是两类自动端口映射协议。像游戏主机、智能摄像头、部分点对点应用会主动通过这两个协议向路由器申请开放端口免去手动配置的麻烦。从方便性来说开着UPnP确实省事游戏主机自动申请开放端口联机质量更好摄像头自动映射远程查看不折腾。但安全性也明显任何内网程序都可能借助UPnP协议在路由器上静默地增加映射规则一旦内网有恶意软件它可以无声无息地把内部端口暴露到公网。我的建议是默认关闭UPnP只有确需自动映射的设备才临时打开用完后立刻关掉。家用网络里主动暴露端口本身就要谨慎能手动配置的规则绝不交给协议自动完成。5. 绕过NAT的几条现实路径打洞、中继与可控的例外5.1 打洞的基本逻辑两个NAT设备如何找到彼此两台设备都处在各自的NAT后面互相之间没有公网映射规则它们能否直接通信答案是在很多情况下可以靠的是打洞技术。基本思路是引入一台公网上的STUN服务器做“引路人”。双方先各自向STUN服务器发送探测包服务器回包时会把它们各自的公网地址和端口告知对方。因为双方都主动向外发过包各自的NAT网关里已经留下了映射表项公网地址和端口是开放的。随后双方拿着对方的公网地址和端口互相发包一旦都到达对方的NAT网关映射关系就被触发直连通道打通。这个流程听上去很简单但每一个环节都可能失败。最常见的问题是双方都处于对称型NAT之后由于各自的公网端口随连接对象变化用STUN服务器探到的地址端口对另一个目标根本无效打洞直接失败。还有多层NAT叠加、运营商级NAT等因素也会让打洞毫无反应。5.2 运营商级NAT藏在运营商的私有地址后面这里必须单独提一个现实问题运营商级NAT业内常说的CGNAT。很多宽带用户实际拿到的所谓“公网IP”并不是自己能完全控制的公网IP而是运营商路由器分配的一个保留地址段通常落在100.64.0.0/10范围内也就是RFC 6598规定的共享地址空间。判断方法很简单登录路由器查看WAN口IP然后访问任何一个IP查询网站确认当前出口公网IP。如果这两个IP不一致说明运营商把你的宽带叠在了运营商级NAT后面路由器上做的端口映射对公网完全没有意义因为外部访问过来时根本找不到你的路由器。遇到这种情况打洞基本无望点对点直连也会经常失败。解决方案无非两条路向运营商申请一个真正独立的公网IP部分宽带套餐可以申请或者放弃直接连入改用中继转发方案。如果你只是需要从外部访问内网的某个服务后者反而是一条稳定得多的路。5.3 中继服务器兜底什么时候该放弃打洞当打洞不成功时还有一个成熟兜底方案让所有流量经过一台公网中继服务器转发。这个方案的思想很朴素双方都主动连接到同一台公网服务器由服务器把数据从一端转给另一端。这样做的好处非常明显不再依赖双方的NAT类型无论是锥型NAT、对称型NAT还是运营商级NAT只要双方能主动访问公网中继就一定能工作。缺点也明显延迟增加、带宽受限于中继服务器的出口能力、中继服务器的可用性成为单点瓶颈。我在给某公司设计远程协作方案时遇到过这个问题员工分布在各地宽带环境五花八门有的人在运营商级NAT后面有的人的公司出口防火墙策略严格打洞测试失败率超过一半。最终方案就是老老实实走中继部署了一台公网云主机做数据转发同时做了端口限速和访问白名单。实测下来传输速度虽然不如直连但胜在稳定各省市接入都正常用户满意度比之前频繁断连高了太多。打洞和中继并不是非此即彼更常见的做法是优先尝试打洞失败后自动降级到中继。也就是把直连当成“快速通道”把中继当成“保底方案”两者结合才能覆盖绝大多数网络环境。6. 一次内网服务无法访问的完整排查链路6.1 现象配置了端口映射外网依然连不上某公司有一台内网服务器跑着一个内部管理系统端口是8080。管理员在出口路由器上配置了端口映射外部端口8080映射到内网服务器的8080。服务器本机访问一切正常局域网内其他电脑用内网IP访问也正常但人在外地的同事访问“公网IP:8080”就是不通。这种案例在运维群里几乎每周都能看到而且绝大多数人第一反应都是“再改一遍端口映射”。但问题往往不在那几条规则上。6.2 完整排查链路从内到外逐层排除我当时的排查顺序是这样的这个顺序很重要能最大程度避免走弯路第一步在内网服务器上确认服务本身正常。使用如下命令确认8080端口确实处于监听状态并且监听地址不是127.0.0.1netstat -lntp | grep 8080第二步确认出口路由器的WAN口IP与公网实际出口IP是否一致。在路由器状态页记录WAN口地址再在电脑上访问公网IP查询网站。如果两个IP不一致直接断定是运营商级NAT剩下的排查都不用做了。第三步检查端口映射规则的完整参数。外部端口、内部IP、内部端口、协议类型TCP还是UDP。这里最容易犯的错是服务用的是TCP规则里却写成了UDP或者内部IP写错一个数字映射指向了不存在的设备。第四步在出口路由器上抓包或者在公网侧的一台测试主机上发起访问后在路由器WAN口执行抓包观察TCP SYN包是否真正到达了路由器。这一步是分水岭如果能抓到SYN说明公网路径没问题问题出在路由器到内网服务器的后半段如果抓不到SYN说明数据根本没到这台路由器。第五步检查路由器自身的ACL或安全策略。很多路由器默认会拦截WAN侧主动访问即使有端口映射也需要在防火墙策略里显式放行。部分家用路由器把端口映射和防火墙策略分开处理只做映射不放开防火墙照样不通。第六步如果前面全部通过再检查内网服务器自身的防火墙。用iptables查看INPUT链规则确认8080端口没有被DROPiptables -L INPUT -n --line-numbers | grep 8080综合以上排查如果公网侧抓不到任何数据包且WAN口IP和公网出口IP不一致基本就能锁定运营商级NAT。实际情况也正是如此那家公司的宽带走的是共享出口用户拿到的地址是运营商NAT网关分配的端口映射在本地路由器上一万个正确也毫无意义。6.3 根因与解决公网IP到底是不是公网IP根因清晰之后解决方向就很明确了。首选是联系运营商把宽带改成公网IP接入。不少企业宽带套餐本身就包含公网IP只是由运营商侧默认开启了大网NAT提交申请后就能调整一般一天之内生效。家用宽带则要看地区策略部分区域仍然可以申请部分区域已经彻底不做公网IP了。改造完成后再访问“公网IP:8080”数据包就能顺利到达路由器再经端口映射进入内网服务器。整个过程前后对比非常直观同一个路由器、同一套映射规则之前怎么都不通出口改成公网IP后立即恢复。这个案例给了我一个很深的教训排查NAT类故障永远不要想当然地认为“路由器上显示的就是公网IP”。大网NAT在国内宽带环境里极其普遍把它列为第一排查项能省下大半天无意义的试错时间。我个人的习惯是处理所有NAT相关故障第一步先画一张简单的数据流图客户端从哪里发起经过哪几层设备每一层做了什么事最终到达哪里。只要图上标注清晰往往还没动手敲命令问题就已经暴露了大半。最后再分享一个小技巧任何端口映射配置完成后都不要用内网环境验证“公网访问是否正常”直接用手机流量从外网测这一步能绕开NAT回路和DNS缓存带来的假象是检验映射最干净的手段。