企业官网建设流程全解析

说实话，这活儿我接过不止一次。上周刚帮一个朋友收拾完双出口环境的烂摊子，现象特别典型：两条运营商线路都接在华为USG防火墙上，内网服务器对公网发布业务，结果电信用户访问一切正常，移动用户那边时通时不通，偶尔还出现“能Ping通但打开网页就是慢”的怪病。搞到最后发现，问题根本不在带宽、也不在服务器，而是NAT在双ISP场景下的几个细节没处理干净。

华为防火墙做NAT，单出口的时候谁都会配，但一旦上了双ISP出口，再加上服务器发布（目的NAT），这里面的坑就一个接一个地冒出来。今天这篇就围绕这个场景，把我踩过的、帮别人填过的坑都捋一遍，权当一份避坑清单。不管你是刚接触华为USG系列的新人，还是已经在维护企业出口网络的老手，这篇文章里一定有你能用上的东西。

1. 先弄明白双ISP加NAT到底难在哪

1.1 一个典型得不能再典型的翻车场景

先画个大家都熟悉的拓扑：防火墙有两个上联口，分别接电信和移动两条宽带，下联口接内网核心交换机。内网划分了办公网段和服务器区（DMZ）。服务器区有一台Web服务器，需要同时通过电信和移动两个公网IP对外提供服务。办公网用户需要正常访问互联网。

听着很简单对吧。单看任何一条链路，配置都是教科书级别的：源NAT负责让内网上网，目的NAT（NAT 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或在域间策略中放开对应流量实现，不同版本命令有差异。

第二种更简单粗暴，但符合大多数企业的实际做法：内网访问服务器时，直接让它走内网IP，DNS解析根据来源区分成内外网不同结果，即所谓的“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 一张速查表，出现症状时照着看

为了让大家以后排查能快一点，我把常见症状和排查方向整理成一张速查表：

这张表不能覆盖所有场景，但至少能帮你把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. 最后再分享一点我的配置习惯

前面讲的都是原理和坑，最后这部分分享几个我个人在双ISP+NAT场景下的配置习惯，权当给大家的配置Checklist。

第一，所有NAT规则和地址池命名必须带链路标识。我习惯用ISP1_和ISP2_做前缀，后面跟用途。这样做的好处是，半年后再回来看配置，依然能一眼看懂。

第二，配置完NAT后必须做双向验证。外网访问验证不用说，内网通过公网IP访问也要测一遍。有条件的话，请一个外网的朋友帮你从公网发起访问，因为有些运营商NAT或代理环境下，从内部访问外部映射地址的现象和真实公网访问并不完全一致。我自己就遇到过内网测试通过，外网用户全部访问不了的案例，原因是运营商封了某些高端口，NAT映射的端口恰好被波及。

第三，在配置NAT Server时，尽量把映射端口控制到最小范围。只开放需要的端口，不要做全端口映射。同时，定期查看防火墙日志，关注是否有异常的映射访问记录。NAT Server就是对公网开了一扇门，门开得越小越安全。这个道理大家都懂，但日常维护中很容易松懈。

第四，做任何NAT变更前，先备份配置。华为USG支持display current-configuration全量导出，操作前导出一份，出问题能快速回滚。别嫌麻烦，我曾经在客户现场改NAT规则时手滑配错了一条黑洞路由，差点把整个出口搞断，幸亏有备份才及时回滚。

行了，双ISP出口加服务器发布的NAT避坑指南就到这。这些坑每一个都是我拿真金白银的网络故障换来的经验，希望能帮你少走点弯路。如果你正准备给公司做双出口改造，或者正在排查一个找不到头绪的NAT问题，不妨把这篇翻出来对照一下。网络这东西，细节决定成败，NAT尤其如此。