NAT回流故障详解：内网打不开公网映射服务的排查与配置

做网络维护的应该都遇到过这种场景公司的某台服务器Web服务已经做好了公网端口映射外部客户用手机4G访问一切正常结果老板在办公室连上公司Wi-Fi用同一个域名反而打不开。一开始怀疑DNS解析有问题换了好几个DNS都不行又怀疑内网防火墙拦了流量放行规则加了一堆也毫无反应。最后把出口路由器的抓包打开一看才明白问题出在NAT回流上。NAT回流这个词听起来有点绕实际就是内网用户通过出口设备的公网地址、去访问内网自己服务器时出口设备能不能正确处理地址转换的问题。这次我用ensp模拟器把整个场景完整复现出来从流量走向到配置命令再到排错思路一次性讲清楚。1. NAT回流问题的典型症状与迷惑性1.1 最经典的业务现象外网正常内网打不开先描述一下这个问题的经典画像。某机构内部有一台OA服务器IP是内网地址跑着Web服务。管理员在出口路由器上做了端口映射把服务器的Web端口映射到了公网地址的80端口外部任何人访问公网IP都能正常打开页面。所有内网员工访问同一个公网IP时则出现两种极端表现第一种是完全超时浏览器转圈半天最后报错第二种是能通但打开页面极其缓慢而且页面里的静态资源经常加载失败。这两种表现都指向同一个方向内网到服务器的流量链路不正常而不是服务器本身有问题。很多人第一反应是是不是服务器负载太高了。但外部访问正常恰恰说明服务器、Web服务、端口映射本身都没问题。问题只出在内部访问这一侧。如果这时候用telnet或者浏览器去连公网IP的80端口大概率会卡在连接阶段这更增加了迷惑性。1.2 为什么这个问题特别容易让人绕远路这个故障真正坑人的地方在于它太容易把排查方向带到DNS和防火墙上。先说DNS。公司内部访问自己的业务系统通常会使用域名。如果内网DNS服务器解析域名得到的是公网IP那流量就会先走到出口设备如果内网DNS解析得到的是内网IP流量就会直接在内网路由。很多人排查时先改DNS把域名解析改成内网IP结果发现好了就以为是DNS配置问题。但这种方式是绕开问题不是解决问题。再说防火墙。内网访问公网IP要经过出口设备的安全策略或ACL。不少网管觉得外网能访问说明ACL放行了于是忽略NAT层面反复在防火墙上加策略。实际上出口路由器在NAT处理这个环节就把流量搞丢了加再多安全策略也没用。这也是我为什么建议直接在出口设备上抓包早抓包早定位别凭感觉猜。1.3 先给结论NAT回流到底是什么NAT回流行业里也叫NAT Hairpin、NAT Loopback、NAT Reflection。它的作用简单说就是内网主机通过出口设备的公网IP去访问内网服务器时出口设备在内部完成地址转换并直接把流量送到内网服务器不让数据包真正绕到公网去。正常的外网访问数据包是公网用户 - 运营商网络 - 出口设备 - 内网服务器而内网访问公网IP时如果没有回流机制数据包会变成内网PC - 出口设备 - 运营商网络 - 出口设备 - 内网服务器白白绕了一大圈。如果运营商的网络设备对这类源IP和目的IP相同的异常报文做反欺骗检查数据包就直接被丢弃了表现为完全不通。理解了这层逻辑后面所有配置和抓包验证就都有了方向。2. 内网用户访问公网IP数据包究竟经历了什么2.1 先分清出口路由器上的两类NAT要理解回流得先把出口设备上的两类NAT拆开看。第一类是源NAT也就是大家常说的NAT Outbound。它的作用是让内网主机访问外部网络时把内网源地址转换成公网接口地址让回程流量能正确回来。在企业里最典型的使用就是内网PC上网。第二类是目的NAT也就是NAT Server或端口映射。它把公网IP的某个端口映射到内网服务器的某个IP和端口让外部用户能通过公网地址访问到内网服务。这两类NAT平时是独立的上网流量走源NAT外部访问内网服务器走目的NAT。可一旦内网用户访问的是自己的公网IP这两类NAT就会同时作用到同一条流量上——既要转换源地址又要转换目的地址问题就从这里冒出来了。NAT类型作用典型命令位置转换方向源NAT / NAT Outbound把内网源地址转为公网地址用于上网出接口WAN口源地址改变目的NAT / NAT Server把公网地址和端口映射到内网服务器出接口WAN口目的地址改变NAT回流 / Hairpin在内网接口上处理源和目的的双向转换内网接口LAN口源和目的都改变2.2 未开启回流时的公网一日游以ensp里的实验环境为例出口路由器AR1的公网接口是202.100.1.1内网PC是192.168.1.10内网Web服务器是192.168.10.10。PC访问公网IP 202.100.1.1的80端口在没有NAT回流时数据包会经历这样的流程PC1发出请求源地址192.168.1.10目的地址202.100.1.1因为是跨网段所以发给网关AR1。AR1查路由表发现202.100.1.1是自己出接口的地址于是把报文引导到WAN口方向。AR1在WAN口执行源NAT把源地址从192.168.1.10改成202.100.1.1。此时报文变成源地址202.100.1.1目的地址202.100.1.1异常报文就此产生。报文从WAN口出发进入运营商网络。运营商路由器查路由发现202.100.1.1这台设备的下行接口就是AR1于是把报文原路返回给AR1。AR1再次收到报文这次在WAN口命中NAT Server表项把目的地址从202.100.1.1改成192.168.10.10然后转发给内网Web服务器。服务器收到的是源地址202.100.1.1目的地址192.168.10.10的请求处理完毕后回包源地址192.168.10.10目的地址202.100.1.1。AR1收到回包根据NAT会话表做反向转换把源地址改回202.100.1.1目的地址改成192.168.1.10最终把响应送回PC1。流程看起来能闭合但这套流程非常脆弱。它在ensp里能跑通是因为模拟的运营商设备AR2有一条指向AR1的回程路由。真实互联网里的运营商设备对这种源地址和目的地址完全相同的报文普遍做uRPF反欺骗检查直接丢弃。就算运营商不丢包每一次内网访问服务器都要绕到公网转一圈延迟高、带宽占用大页面卡顿是必然的。这也是为什么很多企业内网访问自己的公网域名时要么超时要么慢得离谱。2.3 NAT回流的核心理念让出口设备扮演外部服务器回流机制要解决的问题其实很朴素让内网PC发出的我要访问公网IP 202.100.1.1:80这个请求被出口设备在内部消化掉直接转换成我要访问内网服务器192.168.10.10:80然后走内网转发过去。关键是回程。PC发出请求时心里记住的是我访问的目标是202.100.1.1:80所以它只认源地址是202.100.1.1的响应。如果服务器的回包是源地址192.168.10.10PC会直接丢弃因为TCP连接四元组对不上。所以出口设备在回程时必须把服务器回包的源地址再改回202.100.1.1。也就是说一个完整的回流动作在出口设备上要同时做两次NAT请求方向做源地址转换目的地址转换回程方向再反向做一次。整个过程都在内网接口的转发路径上完成不依赖WAN口和运营商网络。理解了这一点再看命令配置就顺理成章了NAT回流必须作用在内网侧的接口上这样设备才能第一时间截获并转换流量。3. ensp实验拓扑搭建与基础NAT配置3.1 拓扑结构与地址规划为了把问题隔离清楚我用三台设备搭了一个最小实验环境AR1作为企业出口路由器同时负责源NAT、NAT Server和回流AR2模拟运营商设备另有一台PC1模拟内网用户一台PC2模拟公网用户一台Server1模拟内网Web服务器。这里有个值得注意的设计我把内网PC和服务器放在两个不同的网段。原因是为了避免同网段ARP直连这个干扰因素。如果PC和服务器在同一个广播域服务器回包时可能ARP直接找到PC根本不经过路由器导致NAT回流无法体现。分成两个网段所有流量都必须经过AR1转发问题才能暴露得更纯粹。设备/接口IP地址用途AR1 GE0/0/0192.168.1.1/24连接内网PCAR1 GE0/0/2192.168.10.1/24连接内网Web服务器AR1 GE0/0/1202.100.1.1/24连接运营商作为WAN口AR2 GE0/0/0202.100.1.2/24模拟运营商侧接口AR2 GE0/0/1203.0.113.1/24模拟外网段PC1192.168.1.10/24内网用户网关192.168.1.1Server1192.168.10.10/24内网Web服务器网关192.168.10.1PC2203.0.113.2/24公网用户网关203.0.113.13.2 AR1基础配置先配置AR1的接口地址和默认路由system-view sysname AR1 interface GigabitEthernet0/0/0 ip address 192.168.1.1 255.255.255.0 undo shutdown interface GigabitEthernet0/0/2 ip address 192.168.10.1 255.255.255.0 undo shutdown interface GigabitEthernet0/0/1 ip address 202.100.1.1 255.255.255.0 undo shutdown ip route-static 0.0.0.0 0.0.0.0 202.100.1.2AR2模拟运营商设备配置接口地址和路由让公网用户能访问到202.100.1.1所在网段system-view sysname AR2 interface GigabitEthernet0/0/0 ip address 202.100.1.2 255.255.255.0 undo shutdown interface GigabitEthernet0/0/1 ip address 203.0.113.1 255.255.255.0 undo shutdown ip route-static 202.100.1.0 255.255.255.0 202.100.1.13.3 配置源NAT与NAT Server在AR1的WAN口上配置源NAT和NAT Server。ACL 2000放行内网两个网段这样内网PC访问任何外部地址时源地址都会被转换成202.100.1.1acl number 2000 rule 5 permit source 192.168.1.0 0.0.0.255 rule 10 permit source 192.168.10.0 0.0.0.255 interface GigabitEthernet0/0/1 nat outbound 2000 nat server protocol tcp global 202.100.1.1 80 inside 192.168.10.10 80到这里基础NAT场景就已经配置完毕。外部PC访问202.100.1.1的80端口经过AR2转发到AR1AR1命中NAT Server表项把流量转给内网服务器。注意NAT Server配置在WAN口下面这是传统做法。它只负责外部访问对于内网发起的、目的地址同样为202.100.1.1的流量它也能命中目的地址转换但整个转发路径不会自动变得优雅。3.4 复现外通内不通的现象现在做三组测试。第一组在PC2上用浏览器访问http://202.100.1.1页面正常打开。这说明NAT Server配置没有毛病服务器Web服务正常。第二组在PC1上ping 202.100.1.2。这个202.100.1.2是AR2的运营商侧接口地址属于外网地址。如果能ping通说明PC1上网的源NAT是正常的。第三组也就是关键测试在PC1上访问http://202.100.1.1。我模拟出的结果分两种在ensp里因为AR2有回程路由这个访问有概率能通但明显慢如果AR2是模拟公网报文的丢弃环境则完全超时。为了让问题在实验里暴露得更明显我建议你在AR2的GE0/0/0接口上开启抓包你会看到一个非常诡异的报文源地址是202.100.1.1目的地址也是202.100.1.1。这个源和目的相同的报文就是NAT回流缺失的最直接证据。4. 开启NAT回流命令、抓包验证与替代方案4.1 关键命令在内网接口开启NAT回流在AR1上执行以下配置interface GigabitEthernet0/0/0 nat hairpin enable interface GigabitEthernet0/0/2 nat hairpin enable这里特别说明一下配置位置。NAT回流命令要加在内网接口上而不是WAN口上。原因在原理部分已经讲过回流流量从内网接口进入最终也回到内网出口设备需要在这个入接口上识别出用户访问的目标其实是我自己映射出去的公网地址这个特殊情况从而走内部转换逻辑。为什么PC网段和服务器网段两个内网接口都要开因为请求从GE0/0/0进来转换后从GE0/0/2出去服务器的回包则正好反过来。我测试时只在一个接口开启也能让实验通过但为了对多种拓扑都稳妥建议把所有内网三层的接口都加上nat hairpin enable。4.2 开启前后的抓包差异对比开启NAT回流之后再重复PC1访问http://202.100.1.1的操作。对比一下抓包结果观察点未开启回流时开启回流后AR1 WAN口 GE0/0/1出现大量源地址目的地址202.100.1.1的异常报文干净不再出现这种报文AR1 内网接口 GE0/0/0只能看到PC1发出的原始请求能看到请求和响应且响应报文的源地址为202.100.1.1AR1 内网接口 GE0/0/2看不到服务器收到的请求或请求被绕路影响能看到转换后的请求源地址为202.100.1.1目的地址为192.168.10.10访问速度卡顿、超时或依赖运营商回程路由正常速度无卡顿抓包是验证回流是否生效的最直观手段。如果你发现WAN口还在出现源目的公网IP的怪包说明回流没有生效先检查nat hairpin enable是否漏配在了内网接口上。4.3 用display命令验证NAT会话表抓包之后还可以在AR1上看一下NAT会话表确认回流会话是否正确建立display nat session all正常情况下PC1访问202.100.1.1:80的会话会出现类似这样的内容协议TCP原始源地址192.168.1.10原始目的地址202.100.1.1转换后源地址202.100.1.1转换后目的地址192.168.10.10。如果看到的是两条独立会话或者只有源NAT会话而没有目的NAT会话多半是NAT Server或ACL配置有问题需要继续往下排查。4.4 变通方案DNS分流、静态路由指引不是所有设备都支持nat hairpin enable这条命令尤其是一些老型号的出口路由器或三层交换机。这时候有几个变通方案。第一个变通方案是DNS分流。让内部DNS服务器解析公司域名时直接返回内网服务器地址。这样内网用户访问域名时流量直接在内网走根本不经过出口设备的公网IP。但这要求DNS服务器具备智能解析能力而且如果同一域名同时服务内外网运维上要小心维护两套解析记录。第二个变通方案是在出口设备上配置静态路由把访问公网IP的流量强制指向内网服务器。这个方案仅适合非常简单的环境一旦涉及多个端口、多个服务器路由配置会非常零散遇到源地址转换和回程处理时还是容易出现问题。第三个变通方案是更换支持回流功能的设备。ensp里AR系列路由器用nat hairpin enable防火墙设备则在安全策略里放行对应域间流量。如果业务规模不大但网络体验要求高把出口设备升级成同时支持Hairpin和会话保持的中端设备是更省心的选择。5. 排错链路与几个高频坑5.1 从现象到根因的完整排查顺序如果按照上面的配置操作后内网PC还是访问不了我建议按这个顺序排查。第一步先检查外网PC是否能正常访问。外网能访问说明NAT Server和服务器本身没有大问题外网也访问不了那就先修NAT Server别急着碰回流。第二步在内网PC上ping运营商设备地址例如202.100.1.2。能通说明源NAT的ACL、路由、出接口地址都正常不能通先解决上网问题。第三步在AR1上执行display nat session all看PC1访问202.100.1.1时有没有生成NAT会话。如果根本没有会话检查ACL 2000是否放行了PC1所在网段以及内网PC的网关、路由是否指向AR1。第四步在AR1的WAN口抓包。如果看到源地址和目标地址都是202.100.1.1的报文说明回流没有生效检查nat hairpin enable是否配置正确。第五步在AR1的内网接口GE0/0/0和GE0/0/2同时抓包。看PC发起的请求是否从GE0/0/2转到了服务器服务器回包是否又从GE0/0/2返回、最终从GE0/0/0回到PC。只要中间有一个环节缺失就能定位到是路由、NAT还是ARP问题。5.2 Ping得通但网页打不开的隐藏原因这个现象特别有迷惑性值得单独拿出来讲。内网PC去ping 202.100.1.1如果通了很多人就会觉得网络是通的。但实际上ping这个公网IP的时候响应报文很可能是出口设备路由器自己回的而不是内网服务器回的。因为202.100.1.1是出口设备的WAN口地址设备收到目的地址等于自身接口地址的ICMP报文会按照本地报文处理直接由设备自身响应。这个过程跟NAT Server、NAT回流都没有关系。所以ping得通只能说明出口设备的WAN口IP是可达的不能说明从内网经过公网IP访问服务器这条路是通的。一旦换成TCP 80端口访问流量必须被NAT Server转发到内网服务器问题才会暴露。这也是为什么很多人一看到ping通就放松警惕结果卡在为什么网页还是打不开上面浪费大量时间。5.3 同网段ARP干扰服务器回包没走路由器如果PC和服务器在同一个网段、同一个广播域还有一个容易踩的坑服务器收到请求后凭借ARP广播直接找到了PC的MAC地址回包根本没有经过出口路由器。这不是NAT回流的配置错误而是网络三层结构的问题。当服务器回包直接发给PC时PC看到的响应源地址是服务器的内网地址192.168.10.10而不是它发起请求时使用的公网地址202.100.1.1PC会认为这是一个陌生设备发来的报文直接丢弃。表现就是服务器日志里有请求记录但PC这边始终收不到响应。解决办法有两种。一种是把服务器和用户划分到不同的VLAN和网段强制所有流量都经过出口路由器的三层转发这样NAT转换才有机会作用在回包上。另一种是确保本来的拓扑就是服务器在独立网段避免跨三层路径上出现ARP旁路。5.4 多出口和双链路场景下的额外坑如果企业出口有多条WAN链路或者做了基于源地址的策略路由NAT回流还会遇到一个新麻烦流量的进出路径不对称。举个例子PC访问202.100.1.1时策略路由让它走了WAN1口但服务器回包到达出口设备后设备可能因为路由策略把回包从WAN2口转发出去。一旦回包从另一条链路出去NAT会话表在WAN1和WAN2之间对不上回包就永远回不到PC。处理这类场景核心原则是保证同一条业务流进出都在同一个出口设备上。最简单的方法是给目的地址等于自身公网IP的流量做策略路由控制强制它走NAT会话建立的那个出接口或者检查设备是否有会话保持和多出口关联NAT会话这类功能开启后能自动绑定。5.5 我自己在实际操作中的一点体会坦白说NAT回流的原理并不复杂但它在故障现场特别容易让人抓狂因为症状太像DNS问题或防火墙问题了。我后来养成了一个习惯只要听到外网能访问内网访问不了公网域名这个描述直接先在出口设备的WAN口抓包看一眼。要是有那个源地址和目的地址都指向公网IP的怪包就连猜都不用猜问题八九不离十就是回流配置缺失。如果是在ensp里做实验记得把WAN口的抓包工具用熟练一点开启回流前后各抓一次对比效果非常直观。配置方面两个内网接口都加上nat hairpin enable把ACL放行范围包含所有内网网段基本一遍就能跑通。最后还是那句话别被域名和DNS牵扯太多注意力很多公网访问正常、内网访问不通的诡异问题根子都在出口设备的NAT处理上。先看包再查会话最后动配置排查效率会高很多。