前阵子帮一家小企业调华为USG防火墙遇到一个特别典型的故障公司内网有台Web服务器外网通过公网IP访问一切正常但内网员工用同一个公网域名访问自己的网站页面死活打不开。我登进防火墙看会话表流量到防火墙上就跟撞了墙一样直接消失。原因很简单——他们只做了单向的目的NAT内网访问公网映射地址的那条流量缺少配套的源NAT和回程处理逻辑。这个问题放到华为USG上就是标准的双向NAT双向映射配置场景。这篇文章我会把双向NAT的适用场景、华为USG上的配置逻辑、具体命令和验证方法一次性讲清楚尤其适合刚接手USG防火墙、被NAT回流问题折磨过的同行参考。1. 双向NAT到底是什么为什么要源和目的都转1.1 我们常说的双向NAT其实是两件事的组合很多刚接触USG的朋友会把双向NAT理解成既配了源NAT又配了目的NAT这个理解方向是对的但不够准确。要真正把握双向NAT得先把NAT拆成两件独立的事源NATSNAT改变报文的源IP。典型场景是内网私网地址访问外网时把源地址从192.168.x.x替换成防火墙公网接口地址或公网地址池地址这样回程流量才能正确返回。目的NATDNAT改变报文的目的IP。典型场景是外网用户访问你的公网映射IP时把目的地址从公网映射IP转换成内网服务器的私网IP。单向NAT的配置里一次会话通常只改变一个方向。比如外网用户访问内网Web服务器只做DNAT回程由防火墙基于会话表自动反向转换。但在某些场景下同一会话的源IP和目的IP都需要被转换这才会出现两条NAT规则同时命中一条流量的情况也就是真正意义上的双向NAT。我个人的习惯是把它简单记成一条流里源也换了、目的也换了才叫双向NAT。1.2 必须做双向NAT的典型场景内网用户访问自己的公网服务器最典型的场景就是我开头说的NAT回流或者叫Hairpin NAT。看名字就知道流量在内网发起目的地却是自己公司的公网IP防火墙要把这个流量掰回内网服务器像头发绕回来一样。举个例子你就明白了内网客户端192.168.1.50访问公司公网映射地址202.100.1.100:80Web服务器实际是内网192.168.1.10:80。客户端发出报文目的IP是202.100.1.100这个报文会先到防火墙。防火墙要做一次DNAT把目的IP从202.100.1.100改成192.168.1.10。如果只做DNAT不改源IP那么服务器回包时目的地址是192.168.1.50源IP是192.168.1.10。服务器发现目标在内网直接把回包发给客户端。但客户端发起连接时目的地址写的是202.100.1.100回包源地址却是192.168.1.10TCP连接根本无法建立。解决这个问题的思路就是对源IP也做一次NAT把客户端的源IP从192.168.1.50改成防火墙的公网接口地址202.100.1.2或者地址池里的公网地址。这样服务器看到的源IP是202.100.1.2回包给202.100.1.2防火墙再根据会话表反向转回192.168.1.50。一条流里源和目的都转换了双向NAT闭环成功。除了这个经典场景还有两类场景也会用到双向NAT一是两个私网分支通过公网IP互相访问两侧各自做SNAT和DNAT二是外网用户访问内网服务器同时内网服务器访问外网时需要做源NAT从宏观视角看入方向和出方向都有转换很多项目里也称之为双向NAT。2. 华为USG上NAT的匹配顺序与关键机制2.1 nat server与nat policy的分工差异在华为USG上配置NAT有两条完全不同的路径。nat server专门用于服务器映射场景。它的写法最顺手一条命令定义公网IP:端口 - 内网IP:端口系统会自动生成一张server-map表报文命中server-map后直接做目的转换防火墙的转发性能最优适合单一的服务器发布需求。nat policy策略NAT是华为USG上更通用、更灵活的NAT配置方式。它支持按源区域、目的区域、源地址、目的地址、服务端口做精细匹配可以做源NAT也可以做目的NAT还能组合、调整优先级和匹配顺序适合复杂网络环境。我实际项目里的习惯是如果只是外网访问内网某台服务器的某个端口直接上nat server如果涉及NAT回流、多出口、同区域互访、多条NAT命中同一流量的复杂情况优先用nat policy统一管理。把两者混用时一定要清楚它们的优先级关系华为USG上nat server生成的server-map优先于nat policy匹配。这意味着如果同一条流量既能命中nat server的映射规则又能命中nat policy里的源NAT规则系统会先按server-map去做目的转换再判断是否触发源NAT。理解了这条顺序后面调试双向NAT的很多困惑都能解开。2.2 先转换还是先放行安全策略与NAT的执行顺序这是配置双向NAT时最容易踩坑的问题。很多人在防火墙上配了一堆NAT规则结果流量还是不通于是怀疑NAT写错了实际上问题出在安全策略没有正确放行。华为USG上报文进入设备后的处理流程大致是先查路由再匹配NAT规则完成地址转换然后基于转换后的五元组去匹配安全策略。也就是说安全策略里看到的报文可能已经是NAT转换后的地址和端口。这个转换后匹配的特性经常让人困惑外网用户访问202.100.1.100:80NAT把目的转换成192.168.1.10:80后安全策略要放行的是去往192.168.1.10的流量而不是去往202.100.1.100的流量。内网用户访问202.100.1.100:80NAT回流场景里源IP被转成202.100.1.2目的IP被转成192.168.1.10安全策略要放行的实际是trust区域到trust区域或trust到DMZ的流量。所以我配置NAT和策略时有个习惯安全策略在无法确认NAT转换后地址的情况下先放通大范围比如源区域到目的区域permit等NAT验证通了再回缩。不要一上来就按转换前的地址写得很精细否则你会分不清是NAT问题还是策略问题。2.3 会话表是双向NAT的记忆中枢很多人不理解为什么NAT只需要配入口而不需要配出口。答案就藏在会话表里。防火墙处理首包时会完成源NAT和目的NAT的全部计算在会话表里记录下转换前的五元组和转换后的五元组后续同一会话的报文直接查会话表转发不需要重新匹配NAT规则。服务器回包到达防火墙时防火墙查会话表基于记录做反向转换把源IP、目的IP恢复成客户端看到的地址。双向NAT的会话表尤其重要因为你可能同时命中了源NAT规则和目的NAT规则一旦首包的转换结果有误整个会话都会异常。这也是为什么我要再三强调**配完双向NAT第一步不是看配置刷了有没有报错而是去看会话表里的转换结果对不对。**命令很简单后面验证部分我会详细写。3. 场景一配置外网访问内网Web服务器先打基础先从一个基础场景开始把华为USG的NAT配置思路捋一遍。拓扑先交代清楚Trust区域内网192.168.1.0/24接口G1/0/0地址192.168.1.254Untrust区域外网接口G1/0/1地址202.100.1.2/24运营商网关202.100.1.1Web服务器192.168.1.10监听TCP 80映射的公网地址202.100.1.100运营商分配给公司的公网IP需求一外网用户能通过http://202.100.1.100访问内网Web服务器需求二内网用户能正常上外网。这个场景虽然只是单向NAT的组合但它是后面双向NAT的基础配置上几个环节都不能漏。3.1 接口、区域划分与基础路由先把接口和区域划好interface GigabitEthernet1/0/0 description LAN ip address 192.168.1.254 255.255.255.0 interface GigabitEthernet1/0/1 description WAN ip address 202.100.1.2 255.255.255.0 firewall zone trust add interface GigabitEthernet1/0/0 firewall zone untrust add interface GigabitEthernet1/0/1默认路由指到运营商ip route-static 0.0.0.0 0.0.0.0 202.100.1.1这里的规划思路是服务器放在trust区域和外网用区域隔离。有些项目会把服务器单独划到DMZ区域虽然更安全但双向NAT的配置逻辑是一样的——把文中的trust换成dmz即可。为了便于大家理解和复现我统一用trust。有一点务必注意服务器的默认网关必须指向防火墙内网口地址192.168.1.254否则服务器回包不经过防火墙反向NAT完全没有机会执行连接必断。3.2 目的NAT一条nat server搞定服务器发布用nat server做最基础的服务器映射nat server web_server protocol tcp global 202.100.1.100 80 inside 192.168.1.10 80这条命令的含义是把公网地址202.100.1.100的80端口映射到内网192.168.1.10的80端口。如果以后还要发布443端口再追加一条即可。也可以换成nat policy写法nat policy rule name dnat_web source-zone untrust destination-address 202.100.1.100 32 service protocol tcp destination-port 80 action destination-nat destination-address 192.168.1.10 service protocol tcp destination-port 80nat policy写法的优势是匹配条件细化后面做双向NAT时更容易扩展。如果是这条规则安全策略放行时要注意NAT后的目的地址是192.168.1.10。3.3 源NAT内网访问外网的地址转换内网用户上外网源地址是私网的必须做源NAT才能让流量正常往返。最省事的写法是easy-ip——直接用接口地址做源NATnat policy rule name snat_outbound source-zone trust destination-zone untrust source-address 192.168.1.0 24 action source-nat easy-ip如果有多个公网出口地址、需要固定某些网段走特定公网IP可以改成地址池方式nat address-group public_pool address 202.100.1.2 202.100.1.2 nat policy rule name snat_outbound_pool source-zone trust destination-zone untrust source-address 192.168.1.0 24 action source-nat address-group public_pool3.4 安全策略与黑洞路由安全策略是很多人遗忘的一步尤其是下面这两类规则security-policy rule name untrust_to_trust_web source-zone untrust destination-zone trust destination-address 192.168.1.10 32 service protocol tcp destination-port 80 action permit rule name trust_to_untrust source-zone trust destination-zone untrust action permit第一条放行外网访问内网Web服务器第二条放行内网访问外网。注意第一条里的目的地址我刻意写了192.168.1.10而不是202.100.1.100因为在华为USG的匹配流程里安全策略看到的是NAT转换后的报文。黑洞路由在这里也必须配ip route-static 202.100.1.100 32 NULL0这段配置很多人不理解。防火墙虽然发布了映射地址202.100.1.100但如果报了文的会话老化或分片丢失防火墙看到一个目的地址是202.100.1.100、但没有命中任何会话表的报文时会去查路由表。没有黑洞路由的话这个报文会走默认路由再次发向运营商运营商又把报文路由回来形成环路。黑洞路由的本质就是告诉设备202.100.1.100就是本设备负责的地址查不到映射关系的报文直接丢弃。这条命令是USG项目的标配配映射地址时顺手就要加上。4. 场景二配置内网用户通过公网IP访问内网服务器NAT回流4.1 为什么内网访问会绕路后直接断现在进入正题。外网访问和内网上网的配置都就位了但内网员工输入http://202.100.1.100访问自己公司的网站完全打不开。有些同行这时候的直觉是关掉安全策略试试其实问题不在策略而在NAT的转换逻辑不完整。内网客户端的报文到达防火墙后目的地址是202.100.1.100。防火墙查NAT规则如果只配置了nat server而这个nat server默认带有reverse属性系统会额外生成一张反向server-map允许内网访问公网映射地址时也被DNAT。源NAT呢内网访问外网的snat_outbound规则里destination-zone是untrust但这条流量目的地址转换后的方向其实还在trust区域或按流向判断为trust到trust根本不匹配。于是报文被DNAT到192.168.1.10源IP却保持192.168.1.50不变服务器回包源地址是192.168.1.10和客户端发起的连接源目不匹配TCP握手彻底失败。这就是典型的只配了一半双向NAT的状态目的转了源没转。4.2 关键配置源也转、目的也转一次到位要解决这个问题思路很明确需要为hairpin流量增加一条源NAT规则把内网发往公网映射IP的流量源地址也转成公网出口地址。我用nat policy实现逻辑也更直观nat policy rule name snat_hairpin source-zone trust destination-address 202.100.1.100 32 service protocol tcp destination-port 80 action source-nat easy-ip这条规则的作用是凡是从trust区域来的、目的地址是202.100.1.100:80的流量源地址一律转换为G1/0/1接口地址202.100.1.2。配合已有的nat server或dnat_web规则做DNAT就形成了一条完整的双向NAT客户端192.168.1.50访问202.100.1.100:80防火墙做DNAT目的变成192.168.1.10:80防火墙做SNAT源变成202.100.1.2服务器收到的报文来自202.100.1.2回包给202.100.1.2防火墙查会话表反向转换把回包目的恢复成192.168.1.50整个流程就像一条双向隧道进出的地址都替换过了。会话表里能看到完整的双向五元组记录。4.3 no-reverse参数与源NAT匹配的细节坑实际配置中有一个细节我必须单独拿出来说nat server默认开启reverse这会自动生成反向server-map导致内网访问公网映射IP时自动匹配目的NAT。这种自动有时候是好事省一条DNAT规则但有时候恰恰是麻烦因为很难精确控制源NAT的匹配。如果你希望完全掌控双向NAT的每条规则建议在nat server上关掉reversenat server web_server protocol tcp global 202.100.1.100 80 inside 192.168.1.10 80 no-reverse配合显式的dnat规则和源NAT规则看起来逻辑更清晰。这里有个版本和实践差异需要提醒在部分USG版本上源NAT规则匹配时读取的可能是NAT转换前的目的地址即202.100.1.100也可能是转换后的目的地址即192.168.1.10。我在实际项目中两种写法都遇到过。如果在你的设备上配了snat_hairpin后查看nat session发现源IP没有变化把snat_hairpin里的destination-address改成192.168.1.10 32再试一次。也有一个保底方案干脆把hairpin的源NAT规则写成无条件命中trust到trust的流量nat policy rule name snat_hairpin_all source-zone trust destination-zone trust action source-nat easy-ip这样内网任意主机访问同区域其他主机时都会做源NAT代价是内网用户直连服务器时服务器看到的源IP也会变成公网IP无法从服务器日志区分真正来源。生产环境里如果服务器访问日志对审计有要求建议还是用精确匹配别图省事。4.4 同区域安全策略放行不会自动放行再提醒一次安全策略。华为USG的默认行为中同一区域的流量trust到trust默认是放行的但如果你在防火墙上开启了安全策略严格模式或者配置了统一的security-policy管理就需要显式放行security-policy rule name trust_to_trust_hairpin source-zone trust destination-zone trust service protocol tcp destination-port 80 action permit如果这里不放行即使双向NAT配置完全正确报文也会在策略检查阶段被丢弃。排错时遇到配置看起来都对就是不通的情况优先检查这层。4.5 完整配置示例汇总把场景二的完整配置串一遍方便直接对照修改# 接口与区域 interface GigabitEthernet1/0/0 ip address 192.168.1.254 255.255.255.0 interface GigabitEthernet1/0/1 ip address 202.100.1.2 255.255.255.0 firewall zone trust add interface GigabitEthernet1/0/0 firewall zone untrust add interface GigabitEthernet1/0/1 # 黑洞路由 ip route-static 202.100.1.100 32 NULL0 ip route-static 0.0.0.0 0.0.0.0 202.100.1.1 # 目的NAT nat server web_server protocol tcp global 202.100.1.100 80 inside 192.168.1.10 80 no-reverse # 源NAT内网上网 nat policy rule name snat_outbound source-zone trust destination-zone untrust source-address 192.168.1.0 24 action source-nat easy-ip # 源NATNAT回流 nat policy rule name snat_hairpin source-zone trust destination-address 202.100.1.100 32 service protocol tcp destination-port 80 action source-nat easy-ip # 目的NATNAT回流如果no-reverse后发现内网流量不执行DNAT需加此条 nat policy rule name dnat_web_hairpin source-zone trust destination-address 202.100.1.100 32 service protocol tcp destination-port 80 action destination-nat destination-address 192.168.1.10 service protocol tcp destination-port 80 # 安全策略 security-policy rule name untrust_to_trust_web source-zone untrust destination-zone trust destination-address 192.168.1.10 32 service protocol tcp destination-port 80 action permit rule name trust_to_untrust source-zone trust destination-zone untrust action permit rule name trust_to_trust_hairpin source-zone trust destination-zone trust service protocol tcp destination-port 80 action permit这套配置有个地方需要根据版本微调dnat_web_hairpin是否需要单独配置取决于nat server的no-reverse在具体版本上的行为。如果开启no-reverse后内网流量无法命中任何目的NAT就得补上这条如果内网访问公网IP时直接匹配到dnat规则部分版本nat server的no-reverse只影响反向server-map生成relocate后的流量仍然能命中对应的nat policy规则那可以省掉。验证方法就是登录防火墙查看nat session我下面写。5. 验证双向NAT是否生效从会话表到抓包的排错链路5.1 用display命令快速判断转换结果配完之后不要急着下结论先清掉旧会话调试期为了观察方便reset firewall session table然后让客户端访问一次http://202.100.1.100回到防火墙执行display firewall session table重点看这条TCP 80会话的转换字段。一条正常的双向NAT会话会在会话表里同时体现原始方向192.168.1.50:随机端口 - 202.100.1.100:80转换后方向202.100.1.2:随机端口 - 192.168.1.10:80源与目的都发生改变如果看到源IP还是192.168.1.50说明snat_hairpin没有生效按照前文说的把destination-address换成本地服务器地址再试。如果会话表里压根没有这条会话说明安全策略丢包了按4.4检查放行规则。还可以单独查看NAT策略和server-map状态display nat policy all display nat server all display nat session tabledisplay nat session table只会显示经过NAT的会话比display firewall session table更聚焦我排查时会两个都敲一遍对照看。5.2 抓包与debug定位转换前后的报文如果会话表显示的转换结果正确但业务还是不通就需要抓包确认报文路径。华为USG上在接口抓包capture packet interface GigabitEthernet1/0/0 capture packet interface GigabitEthernet1/0/1注意抓包位置对理解NAT很关键。G1/0/0是内网口抓到的可能是NAT转换前的原始报文G1/0/1是外网口抓到的可能是转换后的报文。如果你在两个口上都开了抓包对照着看就能判断转换是否完整。此外还可以开NAT调试debugging nat packet开启后会打印NAT匹配和转换的过程性信息能看到每条报文命中了哪条规则、转换前后的地址。调试完务必及时关闭undo debugging nat packet不关debug在高流量环境下会刷屏严重时影响防火墙CPU性能。5.3 排查思路总结从源到目的逐步看我把双向NAT排错的完整链路整理一下遇到问题可以从头到尾过一遍客户端到防火墙内网客户端访问公网映射地址报文能不能到防火墙在G1/0/0口抓包确认。NAT规则匹配查看nat policy all和nat server all确认目标地址端口命中的规则顺序无误。NAT转换结果查看nat session table确认源和目的都完成了转换这一步直接决定双向NAT是否真正成功。安全策略放行基于转换后的地址检查security-policy尤其别忘了trust到trust的放行。服务器回程确认服务器网关指向防火墙内网口如果不确定可以在服务器上tracert回包路径。防火墙出接口转发在G1/0/1口抓包确认回包正常发出会话表反向转换无异常。这六步走完99%的双向NAT问题都能定位到具体环节。6. 实战中容易翻车的几个细节6.1 黑洞路由别漏漏了等着环路前面说过发布公网映射地址时务必配黑洞路由。我接手过一台USG外网访问老是一阵一阵的不通排查了AP、运营商、服务器最后才发现防火墙没配黑洞路由某些会话超时的报文在防火墙和运营商网关之间来回打转消耗了设备性能还影响正常业务。这个教训让我从此把黑洞路由当成NAT配置的固定步骤。6.2 nat server的reverse属性是一把双刃剑nat server默认自动生成反向server-map很多场景比如内网访问公网映射IP依赖它才能通但它也会带来一个问题同一个目的地址的流量可能同时命中多张隐含映射导致源NAT规则难以精确匹配。如果你发现内网访问服务器的流量总是走不到预期的源NAT规则考虑给nat server加上no-reverse把目的NAT的主动权交还给nat policy一切规则显式化排错会轻松很多。6.3 安全策略请同时检查两个方向华为USG的安全策略是单向的源区域到目的区域放行不等于反向也放行。双向NAT场景里内网到服务器的流量可能涉及trust到trust外网访问涉及untrust到trust内网上网涉及trust到untrust。三个方向的放行规则缺一不可。我在项目里习惯把安全策略规则命名清晰比如untrust_to_trust_web、trust_to_untrust、trust_to_trust_hairpin一眼能看出用途避免漏配。6.4 服务器网关错了所有NAT都白搭服务器的默认网关必须指向防火墙。这个错误隐蔽在防火墙之外但破坏力最强。排查时如果在防火墙上看不到任何会话记录先别急着怀疑NAT跑到服务器上看看路由表和网关配置往往答案就在那儿。6.5 FTP、SIP等协议需要额外关注ALGFTP这类协议在控制连接里协商数据连接地址NAT只会转换IP头和端口如果不对协议做应用层网关ALG处理客户端能登录FTP但列目录卡死。USG上相关命令和版本有关系界面上一般在对象或应用层配置里打开对应协议的ALG开关。涉及非HTTP协议的双向NAT发布上线前先拿真实客户端测一遍完整业务流不要只在防火墙上看会话表。6.6 双机热备下别忘会话同步如果USG做了HRP双机热备双向NAT的会话表必须同步到备用设备。否则主设备宕机切换到备机后原有TCP连接会全部中断新连接也可能会因为server-map或NAT会话未同步而建立失败。配置HRP时建议把NAT会话的同步项一并打开切换后立即做一轮完整的业务验证。最后再分享一个我自己的习惯双向NAT这类配置很容易在几个月后自己都看不懂当初为什么这么写。每一条NAT规则的作用域、适用场景、被哪条流量命中我都会写进注释里用USG的命令行注释功能或者干脆记在运维文档中。NAT规则一多规则顺序和匹配关系就会变得很微妙一份清晰的注释文档比任何调试命令都管用。