说实话这活儿我接过不止一次。上周刚帮一个朋友收拾完双出口环境的烂摊子现象特别典型两条运营商线路都接在华为USG防火墙上内网服务器对公网发布业务结果电信用户访问一切正常移动用户那边时通时不通偶尔还出现“能Ping通但打开网页就是慢”的怪病。搞到最后发现问题根本不在带宽、也不在服务器而是NAT在双ISP场景下的几个细节没处理干净。华为防火墙做NAT单出口的时候谁都会配但一旦上了双ISP出口再加上服务器发布目的NAT这里面的坑就一个接一个地冒出来。今天这篇就围绕这个场景把我踩过的、帮别人填过的坑都捋一遍权当一份避坑清单。不管你是刚接触华为USG系列的新人还是已经在维护企业出口网络的老手这篇文章里一定有你能用上的东西。1. 先弄明白双ISP加NAT到底难在哪1.1 一个典型得不能再典型的翻车场景先画个大家都熟悉的拓扑防火墙有两个上联口分别接电信和移动两条宽带下联口接内网核心交换机。内网划分了办公网段和服务器区DMZ。服务器区有一台Web服务器需要同时通过电信和移动两个公网IP对外提供服务。办公网用户需要正常访问互联网。听着很简单对吧。单看任何一条链路配置都是教科书级别的源NAT负责让内网上网目的NATNAT Server负责把公网IP映射到服务器。但问题恰恰出在“两条链路同时存在”这件事上。很多人在配完两条默认路由、做完两个接口的NAT之后就以为万事大吉。实际上华为USG在这类场景下需要考虑的链路选择顺序、回程路由、NAT会话老化机制都比单出口复杂得多。我见过最快的翻车记录是配置完的当天下午。业务方报障说移动线路的用户访问服务器时好时坏技术人员第一反应是移动线路质量差结果拿笔记本接在移动公网IP上Ping服务器发现丢包率只有0.1%。真正的问题出在防火墙内部——数据包从移动接口进来处理完之后回包却从电信接口出去了典型的非对称路由引起的状态检测问题。1.2 NAT和回程路由的关系是问题的核心要理解这里的坑必须先搞清楚一个概念NAT不是单纯改个IP地址就完事它牵扯到整个会话的来回路径。华为防火墙和大多数状态检测防火墙一样会为每个经过NAT转换的会话维护一张会话表。会话表里记录了转换前的IP和端口、转换后的IP和端口、入接口、出接口等信息。后续的数据包只要命中这张会话表就直接按表里的信息转发不会再重新匹配路由和NAT策略。这个机制本身没问题但在双ISP环境下它成了一个巨大隐患。假设电信用户访问服务器的数据包从电信接口进来防火墙做目的NAT后转发给内网服务器。服务器回包时防火墙看到这是已有会话的流量会按照会话表从电信接口回给用户。这没毛病。但如果因为策略路由或者链路故障导致电信方向来的请求走了移动接口出去或者更隐蔽的情况——内网服务器回包的路径和入接口对应的路由不一致——防火墙就找不到完整匹配的会话直接把回包丢弃。用户看到的现象就是“请求发出去了服务器也收到了但回包永远到不了”。这个问题的本质就是网络界老生常谈的“源进源出”原则。多出口环境下进来自哪个接口回去就必须还从哪个接口走。华为USG在默认状态下对非对称流量非常不友好因为状态检测机制要求流量必须对称。传统的解决办法是配置策略路由把回程流量强制引导回对应的出接口或者在上联设备上做路由策略。但在做这些之前你必须先想清楚NAT会话表是怎么建立的否则就是治标不治本。1.3 状态防火墙为什么对非对称流量特别敏感很多人不理解为什么普通路由器上非对称路由没事到了防火墙上就出问题。区别在于路由器只看IP包头的目的地址把包扔给下一跳就完事防火墙则要追踪整个连接的状态。华为USG上的会话表不仅仅包含五元组信息还包含接口信息。当一个数据包到达防火墙它会先查会话表如果命中了就检查报文方向和接口是否与会话匹配匹配才能通过。这就带来一个很直接的结果即便你的路由表在逻辑上能把回包送到正确的方向但只要接口对不上防火墙就会把回包当成非法报文丢掉。很多人在排查时只看了路由表发现静态路由、策略路由都没问题就一头雾水。实际上问题不在路由而在会话表。这也是为什么在双ISP环境下单纯调整路由优先级解决不了NAT回程问题必须把“入接口”和“出接口”当成一套完整的逻辑来设计。我还遇到过更隐蔽的场景防火墙开了会话同步主备两台设备做了双机热备。主设备处理从电信口进来的请求然后主备切换后回包从备设备转发而备设备上没有对应的会话表项因为会话同步只同步了转换后的信息没同步完整状态结果整个会话被重置。这种问题在排障时极其头大因为它不是稳定复现的而是跟切换时机强相关。2. 双出口下源NAT的配置要点与真实坑位2.1 看清你的出口链路再决定地址池怎么分先把源NAT的分类捋清楚。华为USG上最常见的源NAT就是NAT Outbound也就是大家常说的出接口NAT。做双出口时最容易犯的第一个错误就是两条链路共用一个NAT地址池。举个例子电信和移动都是动态拨号获取IP或者各有固定IP。有人图省事直接配一个NAT地址池然后在两个出接口上都引用同一个地址池。这种配置在会话少的时候看不出问题一旦并发量上来很容易出现会话表项异常。原因很简单流量从电信接口出去时地址池本应映射到电信的公网IP但如果同一时间内移动接口的流量也来了防火墙在转换时可能使用地址池中的任意一个地址而电信侧的路由器根本不知道这个地址应该怎么回程结果就是大量丢包。正确的做法是按接口分别维护独立的NAT地址池。电信接口的NAT Outbound就用电信的公网IP地址段移动接口的NAT Outbound就用移动的公网IP地址段。两条链路的NAT转换逻辑完全隔离互不干扰。在华为USG上配置大致是这样的以命令行示例Web界面同理# 定义电信侧地址池 nat address-group telecom 0 address 120.80.x.10 120.80.x.20 # 定义移动侧地址池 nat address-group mobile 0 address 221.7.x.10 221.7.x.20 # 接口下分别调用 interface GigabitEthernet1/0/0 # 电信出口 nat outbound 2000 address-group telecom interface GigabitEthernet1/0/1 # 移动出口 nat outbound 3000 address-group mobile这里有个细节值得多说一句如果出口是PPPoE拨号公网IP是动态变化的那你有两个选择——要么使用出接口地址做NAT就是华为设备上的nat outbound 2000不带地址池直接用接口IP转换要么写脚本联动更新地址池。我个人更推荐前者省心且不易出错。固定IP场景才建议配置地址池。2.2 策略路由和NAT的联动最容易出事的点双ISP环境下几乎必然要配策略路由PBR否则两条链路只能靠默认路由做负载分担效果很容易失控。常见需求是内网办公网段走电信服务器区回程走移动或者根据源IP区分链路。这时候就要注意策略路由和NAT的执行顺序问题。华为USG上策略路由的匹配优先级高于普通路由表而NAT Outbound是基于接口执行的。这意味着一个数据包先进来先根据策略路由被扔到指定出接口然后在该出接口上执行对应的NAT转换。这个逻辑链条本身没问题但有一个坑你必须保证策略路由的分类方式和接口NAT的匹配范围是严格对应的。举个例子你希望办公网段走电信出口配置了策略路由把办公网段下一跳指向电信的网关。但你忘了检查电信接口上的nat outbound引用的ACL是否也包含了办公网段。如果ACL没匹配上数据包确实从电信接口出去了但源地址没被转换成电信公网IP到了互联网上要么被丢弃要么回程路由直接乱掉。我在实际项目中见过更夸张的配置策略路由把源地址10.10.0.0/16的流量分成了两条链路但NAT Outbound的ACL写的是匹配源地址10.10.1.0/24。结果10.10.1.0/24这个网段的流量走NAT其余网段全裸奔。这种配置出来后很难一眼看出来排查时看到会话表里源IP是私网地址才知道出了问题。所以配置时一定要有二层检查习惯先检查策略路由匹配规则再检查对应出接口的NAT匹配规则两边必须保持一致。最好画个表格把“源网段-策略路由-出接口-NAT地址池”四个元素对应起来逐项核对。2.3 几条必须养成的操作习惯双ISP的源NAT配置有几点操作习惯值得从项目一开始就养成。首先所有NAT规则的命名一定要带链路的标识比如telecom_nat、mobile_nat。不要用默认的编号或者随便起的名字。设备跑起来之后出问题要快速定位时清晰的命名能省下至少半小时。其次配置NAT Outbound的ACL时尽量精确到网段不要图省事写permit any。双出口场景下任何一个网段如果同时匹配了两条链路的NAT规则防火墙的处理逻辑不是你想象中严格按顺序匹配而是会根据会话、接口、优先级综合判断结果很难从配置上直接推理出来。把ACL缩小到具体网段能避免很多逻辑冲突。最后强烈建议开启防火墙的NAT日志并配置日志服务器或至少能在本地查看。出问题时display nat session、display firewall session table这些命令能帮你看到实时转换情况但如果历史日志被冲掉了排障会非常困难。日志里有会话建立的原始原因是排障时还原现场的重要依据。3. 服务器发布目的NAT的细节与翻车现场3.1 NAT Server在做端口映射前先把流程想明白服务器发布的核心是目的NAT在华为防火墙上基本都用NAT Server功能。它做的工作很简单把发往公网IP某个端口的流量转换后发给内网服务器的对应端口。传统Web服务多为80/443端口这个功能看起来毫无难度但双ISP场景下事情就没这么简单了。先看一个基本配置示例# 电信公网IP 120.80.x.10 的 443 端口映射到内网服务器 192.168.10.10 的 443 nat server web_telecom protocol tcp global 120.80.x.10 443 inside 192.168.10.10 443 # 移动公网IP 221.7.x.10 的 443 端口映射到同一台服务器 nat server web_mobile protocol tcp global 221.7.x.10 443 inside 192.168.10.10 443配置本身很简单但有两个容易踩的点。第一这两条NAT Server规则配置完成后防火墙会把公网IP的所有端口都“占住”吗不会。华为USG上NAT Server是按端口映射的除非明确配置了映射所有端口否则其他端口仍然是关闭的。第二NAT Server配置的顺序和匹配逻辑在多条规则的情况下需要特别小心。我在项目里踩过这样一个坑服务器上有Web服务和数据库服务Web服务要对公网开放数据库只允许内网访问。运维图省事直接通过NAT Server把数据库端口也映射出去了想着“反正数据库有密码”。结果没两天就被扫描到数据库被尝试暴力破解。这里的问题不在NAT配置本身而是安全意识。NAT Server是双刃剑每映射一个端口就等同于在内网服务器上开了一个对公网的入口。能不映射的坚决不映射不能为了图方便把所有端口都放开。3.2 多运营商地址映射的几个高频翻车点双ISP环境下做NAT Server最经典的问题出现在“同一个公网IP同时用于源NAT地址池和NAT Server映射”。我碰到过不止一次用户把电信的公网IP同时配置成了NAT Outbound地址池中的地址以及NAT Server的全球地址。结果内网用户上网时源地址可能被转换成这个IP然后同一IP又承载着Web服务。这会导致防火墙在处理时产生歧义NAT Server的回应流量和上网用户流量相互干扰现象就是Web服务偶尔打不开或者内网上网速度极慢。解决方法是把地址池划分清楚用于出接口源NAT的地址段和用于服务器映射的地址段必须物理隔开不能重叠。如果运营商只给了一段IP比如电信给了8个公网IP那最好是设定其中一个或两个专门做服务器映射剩余几个做源NAT地址池。另一个高频翻车点是公网IP没有在防火墙上“占住”导致路由环路。这个坑很隐蔽。NAT Server配置好之后如果你没有把对应的公网IP规划到防火墙的接口或黑洞路由上当这个IP收到流量但防火墙没有匹配到NAT会话时流量可能会被转发到默认路由去然后绕一圈回来形成环路白白消耗设备CPU。华为设备上标准的做法是给这些公网IP配置黑洞路由# 把电信的服务器映射公网IP指到黑洞 ip route-static 120.80.x.10 32 NULL0 # 把移动的服务器映射公网IP指到黑洞 ip route-static 221.7.x.10 32 NULL0有了黑洞路由发往这些IP但未匹配任何NAT和会话的流量就会直接被丢弃不会再进入路由循环。这条经验是我在一个客户现场踩了整整一个下午才定位到的当时CPU占用率居高不下排查了半天才发现是环路问题。3.3 内外网访问差异与NAT回环的解决双ISP场景下做NAT Server另一个必踩的坑是“内网用户通过公网IP访问服务器”不通。具体现象是从外网访问Web服务一切正常但内网用户用域名或公网IP访问时要么打不开要么时通时断。原因也很好解释。内网用户向公网IP发起访问请求流量到了防火墙防火墙检查NAT Server规则后把目的地址转换成了内部服务器地址。关键在回包方向服务器回包时它看到的目标地址是内网用户PC的IP源地址是服务器自己的内网IP。如果防火墙没有对这个流量做额外处理服务器回包会直接在内网广播PC收到后发现对方不是自己访问的公网IP直接丢弃。这就是典型的NAT回环问题NAT Hairpin。解决方式有两种。第一种在防火墙上启用NAT Hairpin功能让经过NAT Server转换的流量回包时再执行一次源NAT把服务器源地址转换成公网IP。第二步其实做的是“在NAT转换后的内部流量上再叠加一次NAT”。华为USG上可以通过配置接口下的nat hairpin enable或在域间策略中放开对应流量实现不同版本命令有差异。第二种更简单粗暴但符合大多数企业的实际做法内网访问服务器时直接让它走内网IPDNS解析根据来源区分成内外网不同结果即所谓的“Split DNS”。这种方案在网络架构上更干净既能避免NAT回环带来的性能消耗又能减少防火墙CPU的无效处理。如果公司有内网DNS服务器强烈推荐用这个方案。不过现实是很多中小企业没有独立的内网DNS解逻辑所以NAT Hairpin还是得会配。只提醒一点开启Hairpin后务必检查安全策略放行内网到防火墙映射公网IP的流量否则NAT虽然做了但包被安全策略拦了照样不通。4. 故障排查从现象到原因的实战笔记4.1 必会的几组排查命令华为USG排查NAT问题有几条命令是吃饭的家伙建议直接记在笔记本上。第一条查看当前会话表display firewall session table display firewall session table destination 120.80.x.10第二条查看NAT会话display nat session all display nat session destination 120.80.x.10第三条查看NAT地址池使用情况display nat address-group第四条查看策略路由命中情况display ip policy-based-route这些命令看什么重点放在会话表的“接口对”上。比如你发现一条会话的入接口是GigabitEthernet1/0/1移动出接口却是GigabitEthernet1/0/0电信那基本可以确定是非对称路由问题优先排查策略路由配置。如果会话表里源IP没被转换但接口又是对的那就是NAT Outbound的ACL没匹配上。排查NAT Server问题时优先看display nat server all确认规则是否存在、状态是否Active。有时配置了NAT Server但因为全局地址冲突等原因规则会处于Inactive状态流量自然无法转换。这种情况在Web界面上看配置完全正常但就是不生效用命令行才能看到真实状态。4.2 三个真实故障复盘挑三个我处理过的、非常有代表性的故障复盘一下每个都戳中不同的问题点。第一个是移动线路时通时不通的问题。现场拓扑就是开篇说的双出口服务器同时通过电信和移动发布。排查发现移动线路的入流量全部正常到达防火墙但防火墙处理后的回包全部走的是电信接口出去。看了配置发现静态路由把服务器网段的回程指到了电信的下一跳。移动方向的请求是“从移动口进从电信口出”违反了源进源出原则。改法很简单在策略路由里加一条规则把源地址为服务器网段、且入接口为移动口的流量下一跳强制指向移动网关。配置完才真正解决。第二个是内网访问公网IP不通的案例。客户的外网访问一切正常内网所有PC都无法用域名访问自己的网站。检查后发现防火墙上配了NAT Server但完全没有开启NAT Hairpin功能。内网用户访问公网IP的流量到了防火墙目的NAT转换后发给服务器服务器回包到防火墙防火墙找不到对应的出接口映射直接把包扔了。开启Hairpin并放行相应域间策略后问题解决。当时用户还以为是DNS问题白白排查了大半天。第三个是端口映射后FTP传输失败的问题。客户做了FTP服务器的NAT Server映射控制端口21可以连上但数据传输一直失败。这是很多年没遇到的老问题FTP协议的主动模式需要服务器主动向内网用户发起一个新的连接而这个连接跟原来的控制连接是两条独立的TCP会话。在启用了NAT Server的防火墙上必须启用ASPF应用层状态检测对FTP协议做特殊处理否则数据连接无法被正确转换。华为USG上需要在安全策略或ASPF配置中放行FTP协议。改完后传输正常。4.3 一张速查表出现症状时照着看为了让大家以后排查能快一点我把常见症状和排查方向整理成一张速查表故障现象可能原因首要排查命令典型解决路径外网访问服务器时通时不通回程非对称出接口和入接口不匹配display firewall session table调整策略路由保证源进源出内网无法通过公网IP访问服务器未开启NAT Hairpindisplay nat session all开启hairpin功能放行对应域间策略内网上网速度慢且服务器访问异常源NAT地址池与NAT Server地址重叠display nat address-group重新规划公网IP分离地址池某条链路出口完全不通出接口NAT ACL未覆盖对应网段display nat session检查ACL匹配范围防火墙CPU飙高、有链路环路未配置黑洞路由display ip routing-table给映射公网IP配置NULL0路由FTP/SIP等协议映射后功能异常多通道协议未启用ASPFdisplay aspf all启用对应协议的ASPF检测双机热备切换后所有会话中断会话同步或NAT规则不一致display hrp state检查会话同步状态核对主备NAT配置这张表不能覆盖所有场景但至少能帮你把80%的问题定位到正确方向。真正的排障高手靠的往往不是一条命令而是把现象、配置、路由、会话四方面信息快速对照起来缩小问题的范围。这里再补一句排障心法碰见NAT问题先判断是“转换前”的问题还是“转换后”的问题。在华为USG上可以通过capture-packet和诊断工具抓包确认流量是否到达防火墙、是否被转换、是否被策略拦。别看这些是高阶操作实际上多抓几次包你就能建立对NAT转发流程的直觉排查速度会比单纯看配置快得多。5. 多ISP场景下NAT之外的几个连带问题既然是双ISP出口NAT绝不会是唯一需要关注的地方。几个连带问题如果没处理好NAT配得再对整体网络也跑不顺。第一个就是DNS解析的选址问题。很多企业直接用域名对外提供服务而域名解析由服务商控制。当你拥有两条运营商的公网IP做映射时DNS服务器到底返回哪个IP如果解析到电信IP移动用户访问就会跨运营商跑延迟和丢包率都会上升。正规做法是使用智能DNS或云解析的线路分流功能让电信用户解析到电信IP移动用户解析到移动IP。这块和防火墙NAT配置是配合关系缺一不可。第二个是健康检查与链路切换。双ISP的最终目的不是简单地“两条线同时用”而是要保证一条链路故障时业务能自动切换到另一条链路上。但NAT会话不会自动迁移。链路切换后原有会话全部中断用户需要重新建立连接。这个感知是无法完全消除的但可以通过缩短DNS的TTL、使用链路健康检查的探测机制尽量缩短故障影响时间。华为USG上有IP-Link链路检测功能可以联动静态路由或策略路由检测到链路不通时自动切换到备用链路。第三个是内网服务器的源地址选择问题。当服务器需要主动访问外网时比如服务器要做系统更新它的流量如何选择出口链路如果这块没规划好服务器更新走了一条链路而用户访问服务器走另一条链路防火墙上的会话表会变得异常混乱。尤其在服务器主动连接外网时源NAT和目的NAT可能会互相干扰产生很难排查的偶发性问题。建议在策略路由里把服务器主动访问外网的流量单独拎出来统一走一条经过验证的链路。第四个是带宽和连接数限制。双ISP出口的整网NAT性能取决于防火墙的会话处理能力和带宽能力。很多中低端华为USG设备NAT转换的性能和会话数是有上限的。高峰期并发连接数如果超过了设备规格就会出现新会话无法建立、老会话被强拆的情况。虽然这不算NAT配置错误但在设计阶段就应该根据业务规模选型别等上线了才发现设备带不动。6. 最后再分享一点我的配置习惯前面讲的都是原理和坑最后这部分分享几个我个人在双ISPNAT场景下的配置习惯权当给大家的配置Checklist。第一所有NAT规则和地址池命名必须带链路标识。我习惯用ISP1_和ISP2_做前缀后面跟用途。这样做的好处是半年后再回来看配置依然能一眼看懂。第二配置完NAT后必须做双向验证。外网访问验证不用说内网通过公网IP访问也要测一遍。有条件的话请一个外网的朋友帮你从公网发起访问因为有些运营商NAT或代理环境下从内部访问外部映射地址的现象和真实公网访问并不完全一致。我自己就遇到过内网测试通过外网用户全部访问不了的案例原因是运营商封了某些高端口NAT映射的端口恰好被波及。第三在配置NAT Server时尽量把映射端口控制到最小范围。只开放需要的端口不要做全端口映射。同时定期查看防火墙日志关注是否有异常的映射访问记录。NAT Server就是对公网开了一扇门门开得越小越安全。这个道理大家都懂但日常维护中很容易松懈。第四做任何NAT变更前先备份配置。华为USG支持display current-configuration全量导出操作前导出一份出问题能快速回滚。别嫌麻烦我曾经在客户现场改NAT规则时手滑配错了一条黑洞路由差点把整个出口搞断幸亏有备份才及时回滚。行了双ISP出口加服务器发布的NAT避坑指南就到这。这些坑每一个都是我拿真金白银的网络故障换来的经验希望能帮你少走点弯路。如果你正准备给公司做双出口改造或者正在排查一个找不到头绪的NAT问题不妨把这篇翻出来对照一下。网络这东西细节决定成败NAT尤其如此。