1. 双ISP服务器发布这个组合的底层矛盾是什么说实话搞企业网这么多年被华为防火墙NAT坑得最惨的往往不是那些冷门到一年用不上一次的高级特性反而是双ISP出口 服务器发布这种看着人畜无害的组合。外网用户访问你发布的Web服务时通时断一条运营商线路过来正常、另一条过来就超时内网员工用公网IP访问自家服务器直接失败——这三个现场我都在机房真实遇到过而且每次排查到最后问题根源都在NAT和路由的配合上。这篇文章不打算复述手册而是把我用USG系列防火墙处理双出口和服务器发布时踩过的坑、验证过的经验、以及现场排障的思路完整拆开。内容里会给出可直接参考的配置命令也会讲清楚每个配置背后的原因适合刚接手华为防火墙的网工也适合业务已经出问题、正在机房里头疼的值班同学。整套思路在USG2000/5000/6000以及eNSP里的USG6000V上都能沿用版本差异我会在关键地方单独提醒。1.1 先明确一下典型组网长什么样为了方便后面讲配置和避坑我先固定一个最常见的拓扑。防火墙有三个安全区域trust放内网用户dmz放要对外发布的服务器untrust接两条运营商线路。内网用户网段是192.168.1.0/24服务器网段是192.168.2.0/24Web服务器真实地址是192.168.2.10。运营商A给了一个互联地址202.100.1.2/30网关202.100.1.1另外分配了一个业务公网段202.100.10.0/29给NAT使用。运营商B给的是互联地址203.100.2.2/30网关203.100.2.1业务公网段203.100.20.0/29。两个运营商各给一个公网IP用于发布服务器分别是202.100.10.1和203.100.20.1这两个IP都映射到内网192.168.2.10的80端口。我见过不少朋友把互联地址段和业务公网段混在一起用也不是不行但容易把NAT Server和地址池搅浑。我强烈建议你在规划阶段就把三个地址空间分开写清楚互联地址只用于接口和路由业务公网地址只用于NAT服务器发布地址单独挑出来。这个习惯能少踩一半的坑。1.2 为什么单线路没毛病双出口就翻车单出口的NAT逻辑其实是非常简单的出站流量在WAN口做源地址转换入站流量做目的地转换回程流量靠会话表原路返回。双出口一加入事情就变了因为你有了两个出口、两个运营商分配的地址段、两条默认路由路线的选择权。核心矛盾在于出站流量需要根据你选哪条线路来决定用哪个公网IP做源地址转换入站流量又要保证外部用户无论从哪个运营商的IP访问你发布的服务器都能正确转换并且回包能原路回来。这两件事如果割裂开配就会产生一个方向通、另一个方向不通的经典故障。底层还有一个更深的问题华为防火墙的安全策略、NAT动作、路由查询三者之间存在执行顺序。很多人习惯把安全策略的目的地址写成公网IP这在部分其他品牌防火墙上能通在华为上却会导致策略完全匹配不上因为NAT Server执行后流量已经被还原成了内网服务器地址。这个细节后面我会专门展开它是本篇最重要的翻车点之一。2. 出站NAT双ISP场景下的源地址转换设计先讲出站方向。内网用户访问互联网在双出口环境下最大的问题是你希望两条线路都能走而且无论走哪条线回包都能正确回来。这就涉及到NAT Outbound和地址池的配合以及一个很容易被人忽略的地址池冲突问题。2.1 NAT Outbound和地址池两条线路要各自为战华为防火墙最常用的出站NAT方式就是把ACL和地址池绑定在接口的NAT Outbound上。ACL用来圈出哪些源地址需要做转换地址池用来指定转换后的公网IP范围。我习惯把配置拆成两步acl number 3000 rule 5 permit ip source 192.168.1.0 0.0.0.255 rule 10 permit ip source 192.168.2.0 0.0.0.255 nat address-group 1 202.100.10.2 202.100.10.6 nat address-group 2 203.100.20.2 203.100.20.6ACL覆盖了内网用户段和服务器段这样无论哪边走都能保证有转换动作。然后分别在两个WAN口绑定interface GigabitEthernet1/0/2 nat outbound 3000 address-group 1 interface GigabitEthernet1/0/3 nat outbound 3000 address-group 2很多人从网上抄到过nat outbound 2000 address-group 0这个写法这里顺便解释一下2000是ACL编号0是地址池索引。华为的NAT地址池索引是可以从0开始的所以看到0别觉得是没配置或者默认值它就是个普通索引。真正要检查的是address-group里有没有地址、ACL里的源地址段有没有覆盖全。这个设计背后的逻辑是报文从哪个WAN口出去就用哪个WAN口绑定的地址池做源NAT。运营商A分配的地址是202.100.10.2到202.100.10.6运营商B是203.100.20.2到203.100.20.6互不交叉回包自然回到对应的WAN口会话表也能正确闭合。如果两个WAN口你绑定了同一个地址池那流量从B线路出去却带着A线路的公网IPA运营商的设备大概率会把这个源地址丢掉结果就是访问时通时断。2.2 一个隐藏雷区地址池和服务器公网地址打架这是我最想强调的一个坑。很多人配置出站NAT时图省事把运营商分配的所有业务公网IP都扔进一个地址池比如202.100.10.1到202.100.10.6全部放进address-group 1。与此同时又把202.100.10.1配成了NAT Server的公网地址。这样做在大部分华为版本上入站NAT Server会优先匹配看起来暂时没问题但出站会话一旦抽到这个IP和入站会话在会话表层面会互相影响轻则日志里出现大量NAT冲突记录重则外网用户访问服务器偶发失败。规范做法是地址池和NAT Server公网地址绝对不共用。我上面给例子的时候特意把202.100.10.1留出来作为NAT Server专用地址池只放202.100.10.2到202.100.10.6就是这个原因。运营商给了6个公网IP宁可少用一两个也要保证服务器发布地址是独立且固定的。公网IP不够的情况下优先压缩地址池范围而不是去占用服务器发布地址。2.3 DMZ里的服务器出站也要NAT再补充一个特别容易漏的点。服务器放在DMZ区后如果它自己也需要访问外网比如调用第三方接口、抓取数据、升级补丁那么它的出站流量同样需要NAT。我见过不止一次ACL只写了内网用户网段DMZ服务器出站没有被覆盖导致服务器的出站流量没有转换动作直接以192.168.2.x的私有地址发到了运营商侧。运营商下一跳一看源地址是私网IP直接丢弃然后故障就表现成服务器访问外网超时。所以我在ACL 3000里同时放行了192.168.1.0/24和192.168.2.0/24目的就是让DMZ服务器也参与出站NAT。如果你们服务器出站流量有特殊要求比如必须保留固定公网IP访问第三方白名单那可以考虑单独给服务器配一个NO-PAT的NAT规则保源IP转换后固定映射到某个公网IP上而不是动态抽取地址池。这个属于进阶应用但思路还是同一套ACL圈范围接口绑地址池。3. 入站NAT服务器发布在双ISP下的正确姿势出站配置完毕后接着处理外部访问服务器的入站流量。这里就是把NAT Server和双ISP路由、安全策略三者对齐的环节也是翻车概率最高的区域。我按从基础到进阶的顺序一点点拆。3.1 NAT Server基础配置一个公网IP发布一台服务器NAT Server本质上就是目的地址转换外部用户访问公网IP的80端口防火墙把目的地址翻译成内网服务器的192.168.2.10。在华为防火墙上常用配置如下nat server web_isp1 protocol tcp global 202.100.10.1 80 inside 192.168.2.10 80这条命令的含义是把公网地址202.100.10.1的80端口映射到内网192.168.2.10的80端口。协议可以是tcp、udp也可以不写协议做全映射。实际场景里如果只发布HTTP服务明确写tcp和端口就行了没必要做全端口全协议的映射范围越小越安全排查时也越清晰。NAT Server配置完成后防火墙会自动生成对应的server-map表项外部流量到达时先查这条映射完成目的地址转换再进入安全策略检查。我提醒一句不同VRP版本下NAT Server的配置位置略有差异老版本可能在接口视图下配新版本通常在系统视图或全局配置下就能完成所以抄命令时记得先确认版本和视图。3.2 两条线路发布同一台服务器两个NAT Server条目双ISP场景下外部用户既可能通过运营商A的公网IP访问也可能通过运营商B的公网IP访问所以你必须给同一个内网服务器配置两条NAT Server映射。我现在服务过的不少现场翻车就翻在只配了一条然后换线路测试时发现不通还以为是运营商问题。正确的配置是这样两条一起上nat server web_isp1 protocol tcp global 202.100.10.1 80 inside 192.168.2.10 80 nat server web_isp2 protocol tcp global 203.100.20.1 80 inside 192.168.2.10 80这两条命令的全局地址分别来自两个业务公网段最终都指向同一个内网服务器。外部用户无论从哪条链路进来防火墙都能完成目的地址转换。这里顺带提一句如果内网服务器有多个应用端口要发布比如80和443那就需要多条NAT Server条目别幻想着一条命令能把所有端口都映射了除非你做全端口映射否则逐个明确配置才是最稳妥的。配置完NAT Server之后别忘了确认运营商真的把公网IP路由到了你这条WAN口上。很多时候配置完全正确但运营商的设备把业务公网段路由到了别处或者根本没有宣告到你的接入设备上这种情况外部访问肯定通不了。3.3 安全策略写的目标地址是内网IP不是公网IP这个点我必须单独拿出来讲因为它是华为防火墙NAT排障里最典型的坑。很多从思科、飞塔转过来的朋友习惯在安全策略里把目标地址写成公网IP觉得外部用户访问的就是这个公网IP嘛。但在华为USG的默认处理流程里报文到达防火墙后NAT Server会先把目的地址转换为内网服务器IP安全策略匹配用的是转换后的地址。换句话说你要在安全策略里放行的目的地址是192.168.2.10不是202.100.10.1。如果策略写成了公网IP流量根本匹配不上于是被默认策略丢弃。我在现场排查过不下五次这种问题每次都是配置看起来哪都对但外网就是访问不了最后一看安全策略目的地址写的是公网地址改回真实服务器IP后瞬间恢复。放通策略我一般这样写security-policy rule name untrust_to_web source-zone untrust destination-zone dmz destination-address 192.168.2.10 32 service protocol tcp destination-port 80 action permit同时我还会加一条trust到dmz的策略目的地址同样是192.168.2.10用于内网用户访问这台服务器。这条策略在下一节的回流NAT问题里也会用到。另外提醒一句source-zone只写了untrust两个WAN口只要都在untrust区域里就都能匹配上不需要分别给两个接口写两条策略这是区域设计带来的便利。4. 最容易翻车的四个细节配置层面的框架搭完后下面四个细节是实际运行中翻车率最高的地方每一个我都遇到并解决过所以拿出来单独分析。它们大多不是配置语法问题而是组网设计、路由方向、会话状态这类需要整体考虑的问题。4.1 细节一服务器的默认网关必须指向防火墙内网口这个坑说起来特别基础但破坏力极大。服务器发布出去后外部用户访问经过NAT Server目的地址变成192.168.2.10报文从防火墙上送到DMZ交换机服务器接收、处理、回包。这一步是决定成败的关键服务器的默认网关如果指的不是防火墙的DMZ接口地址192.168.2.1而是指到了核心交换机或另一台路由器上那么回包就不会回来。比如服务器的网关指向了内网核心交换机核心交换机又把默认路由指给了运营商方向的其他设备回包就会从别的路径出网。此时防火墙等不到这个TCP握手的SYN-ACK外部用户自然连接失败。这种故障最迷惑人的地方在于你在防火墙上看到外部来的SYN报文正常NAT会话正常服务器那边也收到了包但两边就是握不上手。我在现场排查的结果里服务器网关配置错误占的比例甚至比NAT命令写错的还高。所以发布服务器之前第一件事就是核对服务器的网关和ARP。display arp | include 192.168.2.10能直接看到服务器MAC是否学习到如果ARP表项里没有说明二层都不通那NAT配置再正确也没有意义。4.2 细节二内网用户用公网IP访问发布服务器回流NAT要打通业务上线后很快会有人提出为什么内网员工不能用公网域名访问服务器。这是典型的回流NAT场景。外部用户访问没问题但内网用户访问公网IP时流量从trust接口进来防火墙查询NAT Server把目的地址转成192.168.2.10然后报文可能又在trust和dmz之间转发。这个过程中防火墙需要完成一次源地址也转换成公网地址的处理否则服务器收到源地址是192.168.1.x的报文回包时直接从DMZ网关发回去了但会话在防火墙侧已经按公网源地址建立两边就对不上。华为防火墙在较新的VRP版本上这部分转换在配置了NAT Server后会隐式处理但我被坑过的是策略层面内网用户到DMZ服务器的流量必须有一条trust到dmz的安全策略放通目的地址写192.168.2.10而且服务端口要匹配。如果内网用户和服务器在同一个安全区域那个区域内的域间策略也要确认放通不同版本对域内流量的默认策略不一致有的默认放行、有的默认丢弃最好的办法是实测一次。我建议直接按我上面给的security-policy模板把trust到dmz的策略和untrust到dmz的策略一起配齐别等测出问题再补。4.3 细节三双出口切换后会话表残留双线路运行中某一条运营商线路抖动或割接防火墙会自动把默认路由切换到备用线路。这时候麻烦就来了原有的NAT会话如果还挂在旧WAN口上用户的流量却已经被新的路由导向了新WAN口新会话的NAT源地址来自新地址池但旧会话的返回流量可能还在等旧线路的响应两边交错之后用户的感知就是网络没断但很多应用卡住了。处理这种问题有几个方向。首先别在防火墙上同时配置两条完全等价的默认路由除非你的设备支持基于会话的双出口负载均衡并且你确实判断过流量模型。我更推荐用策略路由显式区分一部分业务走ISP-A一部分业务走ISP-B切换时只影响对应业务不至于全网都抖。其次如果线路切换已经发生用户反馈卡顿最原始也最有效的办法是清理会话表华为防火墙的三层会话表可以通过reset session清掉操作前注意影响范围。此外链路切换后的路由收敛和ARP刷新也需要时间如果业务敏感建议开启BFD或NQA联动静态路由的探测这样切换能控制在秒级以内。这个做法比人工发现断线再改路由要可靠得多。4.4 细节四FTP和ALGNAT之后的第二层坑服务器发布了FTP服务外部用户能连上但列不出目录这是ALG没处理好。FTP分主动模式PORT和被动模式PASV被动模式下服务器会开放一个随机高端口数据连接需要NAT和ALG配合识别并放通。华为防火墙对FTP的ALG处理通常默认开启但如果你为了安全调整过ALG策略或者发布的FTP采用非标准端口就可能出现控制连接正常、数据连接失败的现象。另一个隐藏问题是MTU和分片。双ISP环境下两条线路的MTU可能不一致运营商A允许1500字节帧运营商B在中间链路上可能实际只支持1450字节。NAT本身不改变报文大小但如果不做分片重组大包经过NAT后再出接口遇到更小的MTU可能直接被丢弃。表现就是打开网页图片加载不全、大文件传输中断。遇到这种情况先排查链路两端MTU一致性必要时在防火墙出接口调整MTU或者检查是否需要让服务器端配合调整TCP MSS。5. 故障排查实录三个现场案例与你该敲的命令配置讲得再多不如直接复盘几个真实故障现场。下面三个案例都是我实际遇到过、并且能通过命令快速定位的类型我把排查路径和对应命令写出来。这说明一下华为不同版本的具体调试命令拼写会有差异但排查思路是通用的。5.1 案例一外网用户全部打不开发布的Web服务器这个案例是我接手一台已有业务的USG时遇到的典型问题。外部用户访问202.100.10.1完全没有响应内网用户访问同样地址也没反应。我先检查接口状态display ip interface brief看到WAN口和DMZ口都UP。再查NAT Server映射是否生成关键命令是display nat server-map结果发现映射表项确实存在但状态不是预期的可用状态。接着查安全策略display security-policy rule all一看就发现问题了策略的目的地址写的是202.100.10.1而不是192.168.2.10。这就是我前面讲的NAT Server执行顺序问题。把策略目的地址改成真实服务器IP后外网访问立刻恢复。这个案例的价值在于不是所有配置看起来正确的NAT都会正常工作安全策略匹配的始终是转换后的地址这个认知要刻在脑子里。5.2 案例二一个运营商访问正常另一个超时另一个现场是用户反映联通的宽带访问服务器正常移动宽带访问超时。首先确认两件事两条NAT Server条目是否都配置了两个WAN口是否都在untrust区域。排查下来NAT配置没问题但display ip routing-table里只有一条指向运营商A的默认路由运营商B的默认路由虽然有但优先级配错了导致从运营商B进来的请求即使能到达防火墙返回报文也会被路由查到运营商A那边去。这个问题的本质是回程路由不对称。我在前面强调过入站流量的回包方向依赖于会话表和接口的对应关系如果防火墙软件处理上存在回程路由又绕回原路径的场景就必须保证两个运营商方向的默认路由都具备且优先级合理。处理方法是把两条默认路由的优先级调整为相同或者让防火墙按会话输出方向强制从原接口回包具体机制不同版本有差异但在配置层面确保两条线路的NAT地址池和路由条目是独立的能避免大部分问题。5.3 案例三内网访问自己发布的服务器失败第三个案例来自一家做电商的公司外网访问都正常就是办公室内网用域名访问官网打不开。我先查了NAT Session看到内网访问公网IP的会话建立没多久就被丢弃。再查安全策略发现trust到dmz方向的策略确实存在但只放通了untrust到dmz。也就是说内网用户访问DMZ服务器的流量因为没有对应策略而被丢弃。补上trust到dmz方向的策略后内网访问恢复正常。这里多说一句如果内网用户和服务器在同一个安全区域记得验证域内策略。我在某版本USG上就遇到过域内默认策略是禁止的情况不显式放通内网访问就是不通。5.4 常用排查命令速查表我把NAT排障中最常用的命令整理成一张表方便你在机房里快速对照命令作用display ip interface brief查看接口UP状态和IP地址配置display ip routing-table确认缺省路由走向和优先级display nat session table查看NAT转发的源地址、目的地址、端口display nat server-map查看NAT Server映射是否生效display security-policy rule all查看域间安全策略的匹配规则display session table verbose查看完整会话信息确认回包方向display log buffer查看安全日志和丢包原因reset session清空会话表用于链路切换后的恢复排查时我习惯按接口状态→路由→NAT映射→安全策略→会话表这个顺序走每一步都有对应的显示命令能快速把故障范围缩小到某一层。这里再强调一个容易被忽略的点很多NAT问题错不在NAT本身而是在路由表上。回程路由错了、默认路由优先级错了NAT做得再完美也白搭。所以看到NAT不通不要一头扎进NAT命令里先花三十秒看路由表经常能直接定位。6. 写在最后的排障心得跑过这么多现场、处理过这么多NAT故障之后我最深的一个体会是双ISP出口加服务器发布考验的从来不是你对某一条NAT命令熟不熟而是你能不能把地址规划、路由选路、安全策略、NAT转换四个层面的逻辑串在一起。很多翻车现场单看每一步都对但放在一起就是互相打架。我自己后来养成了一套固定流程每次接手这类组网时先做三件事。第一画一张地址表把互联地址、业务公网地址、NAT Server地址、内网服务器地址分列清楚检查有没有重叠。第二确认两条线路的默认路由和NAT绑定是否一对一对应绝不混用。第三测试时不仅测外网访问还要测内网回流和服务器主动出站三个方向全部通了才算业务真正可用。这套流程帮我少加了无数次班也让我在同事眼里成了NAT玄学问题处理专家。最后再分享一个小技巧如果你手头有eNSP和USG6000V镜像完全可以把这个双ISP加服务器发布的场景在模拟器里搭一遍。镜像的版本不同NAT命令和回程处理逻辑会有细节差异但坑的形态基本一致。我自己就是先在模拟器上复现了安全策略写公网IP不通的问题后来在现场遇到时心里才有底。纸上谈兵说得再多都不如自己动手跑一遍路由和会话把那些NAT表象背后的逻辑真正吃透。