PPP认证+GRE隧道+NAT综合配置：企业分支互联的排错与实战

做企业网络项目，或者正在备考华为HCIP认证的朋友，应该都有过这种经历：单独配PPP认证，一条串口链路轻轻松松就起来了；单独配GRE隧道，两边接口地址一填，路由一指向，也能通；单独做NAT，静态一对一也就是两条命令的事。可一旦把这三个技术点放进同一张拓扑里，很多人就开始迷糊——PPP认证失败会不会影响GRE隧道建立？隧道流量经过出接口时会不会被NAT改写？内网用户通过公网地址访问内部服务器，为什么数据包到了却回不来？这篇文章就把这张综合拓扑从头到尾拆开，讲清楚PPP认证、NAT和GRE隧道三者之间的协作关系、配置顺序，以及我在eNSP和真实设备上踩过的坑。适合正在备考HCIP的人、准备做分支互联项目的新手工程师，以及那些"单个技术都会，合在一起就废"的同路人。

1. 为什么这套组合是分支机构互联的"标准答案"

1.1 三个技术点各自解决的问题

先说清楚一个基本问题：既然要做的是一张"企业互联网络"，为什么偏偏是这三样东西组合在一起？单独用任何一种不行吗？

在实际的企业组网里，总部和分支之间通过运营商提供的广域网链路互联，最常见的就是串口链路（Serial接口），而串口链路上几乎默认跑PPP封装。PPP本身是一个完整的二层链路协议，它除了能封装数据帧，还自带一套认证机制——PAP和CHAP。运营商给企业开专线，很多时候会要求做链路认证，目的就是保证接入方是企业自己的路由器，而不是被谁在物理链路上偷偷插了一台设备。

但PPP只是解决了"链路能不能用"的问题。企业总部的服务器网段、分支的办公网段，这些私网地址要跨过运营商网络互访，不能直接把私网路由扔给运营商，也不适合用RIP/OSPF这种动态路由协议从公网上传递私网路由。于是需要GRE隧道——它把私网数据包整个包起来，外面套上一个新的IP头，用公网地址做源和目的，到了对端再解封装。GRE隧道的特点是简单、通用，支持承载几乎任意三层协议，而且配置量极小。

那NAT又是干嘛的？分支出口往往只有运营商分配的一两个公网地址，但分支内部几十上百台终端都需要上互联网或者访问总部。这时候就需要NAT把内部私网地址转换成公网地址。另外还有一种场景，总部的某个服务器既想对内提供服务，又想对外提供，私网地址和公网地址之间需要一个静态映射，这就是nat static outbound这类命令存在的意义。

1.2 三者在同一张拓扑里的协作关系

真正让这张拓扑有价值的，不是三个技术各自怎么配，而是它们叠加之后的联动关系。我画过一张很典型的拓扑：总部路由器R1通过Serial接口连接运营商，分支路由器R2通过Serial接口连接运营商，R1和R2之间的物理链路使用PPP封装并开启CHAP双向认证。在R1和R2上分别创建Tunnel接口，GRE隧道跨越PPP链路承载总部的私网网段和分支的私网网段之间的路由。同时，分支内网终端访问总部服务器时，流量先经GRE隧道走；分支终端访问互联网时，流量在R2的出口接口上做NAT转换。

这三者的关系是层层嵌套的：GRE隧道依赖PPP链路提供服务，因为隧道的源地址和目的地址就是PPP链路两端的公网IP；而NAT处理的是"哪些流量需要在出接口被转换地址"的问题，它与GRE隧道的先后关系就很微妙——如果GRE流量出了tunnel口之后又被NAT改写，外层IP头就变了，对端解封装时要么校验失败，要么回包找不到隧道。这些细节，下面一节一节讲。

2. 拓扑与地址规划：先让PPP、GRE、NAT各自"安家"

2.1 实验拓扑与接口划分

我的实验环境是基于eNSP搭的，三台路由器：R1代表总部，R2代表分支，中间加一台R3模拟运营商设备，同时把R3两侧的链路都配置成PPP封装，用来模拟真实的专线接入。总部内网有一台服务器，地址段是172.16.0.0/24；分支内网有终端，地址段是192.168.104.0/24。整个拓扑里的公网互联段我规划为10.1.1.0/30和10.1.2.0/30。

具体接口规划如下：

注意，R3不仅仅是一条直连线路，我在R3上还加了另一条链路连到R2的另一个Serial接口，专门用来做NAT出互联网的实验。这样拓扑就分成了两个维度：总部和分支之间走GRE隧道，分支上互联网走NAT。两条路径互不干扰，但都在R2这一台设备上汇聚，正好能测试流量的分流逻辑。

2.2 地址规划里的三个"不要"

做这个实验，地址规划上我有三个教训，分享出来给你避坑。

第一，隧道的源地址和目的地址不要用Loopback地址。很多教材喜欢用Loopback做隧道源，因为Loopback稳定不掉线。但在PPP链路上，你如果还没把物理接口的PPP认证调通，Loopback地址虽然能Ping通对端，但是GRE隧道依然起不来——因为GRE要求源和目的之间的IP连通性，而PPP认证失败会直接导致物理链路Down，Loopback地址根本路由不出去。所以老老实实用物理接口IP做隧道源和目的，链路状态透明，排错更容易。

第二，私网地址段不要跟公网互联段重叠。我见过有人图省事，分支内网直接用10.1.1.0/24，结果跟PPP链路互联地址撞了，静态路由一配，所有测试全乱套，查了半天才发现是地址冲突。内网段的规划一定要避开运营商侧的互联段，也避开隧道地址段。

第三，隧道地址段不要跟两边的私网段在同一个网段里。Tunnel接口是一个三层接口，它有自己独立的网段，比如10.1.3.0/30。如果你把隧道地址跟总部内网放在一起，路由表会出现冲突，因为对端的私网网段需要通过隧道学过来，而隧道本身的地址又在同一个网段里，递归路由就出问题了。

3. PPP认证落地：CHAP抓包对比与display验证

3.1 PAP和CHAP的选择逻辑

PPP认证有两种方式：PAP和CHAP。PAP的认证流程是客户端把用户名和密码以明文形式直接发给服务器端，服务器端比对后返回通过或拒绝。全程只有一次握手，密码暴露在链路上，安全性很差，而且是在建立链路阶段就发密码，一旦抓包就能看到明文。

CHAP不一样，它是三次握手：服务器端向客户端发送一个随机挑战值，客户端用密码哈希后的结果连同用户名一起返回，服务器端用自己保存的密码做同样的哈希计算，比对一致就通过。整个过程中密码从不直接在链路上传输，挑战值每次随机，即使有人抓包，拿到的是哈希值，也无法反推出原始密码。所以在企业专线互联里，几乎都选择CHAP。

HCIP考试里经常问"为什么用CHAP不用PAP"，答案就是这几点：CHAP不传输明文密码、挑战值随机防重放、密钥不在链路上暴露。如果题目还追问配置差异，你要知道在华为设备上，PAP的客户端配置是ppp pap local-user xxx password xxx，CHAP的客户端配置是ppp chap user xxx配合ppp chap password xxx，两种协议的密码配置命令完全不同。

3.2 服务器端与客户端的完整配置

R1作为CHAP认证的服务器端（认证方），配置如下：

# R1 认证方配置 sys sysname R1 # aaa local-user hcip password cipher HUAWEI@123 local-user hcip privilege level 15 local-user hcip service-type ppp quit # interface Serial1/0/0 link-protocol ppp ip address 10.1.1.1 255.255.255.252 ppp authentication-mode chap

R2作为被认证方，配置如下：

# R2 被认证方配置 sys sysname R2 # interface Serial1/0/0 link-protocol ppp ip address 10.1.1.2 255.255.255.252 ppp chap user hcip ppp chap password cipher HUAWEI@123

这里有三个细节值得注意。

第一个细节，CHAP认证的用户名要跟被认证方ppp chap user配置的用户名严格一致，大小写都算。我曾经在真实设备上调试，本地用户配的是HCIP，客户端写的是hcip，结果链路一直认证失败，查了好久才发现是大小写问题。华为的设备对用户名大小写是敏感的，这一点和思科行为不一样，特别容易踩。

第二个细节，如果服务器端的local-user没有配置service-type ppp，客户端认证就会报错。很多人配了local-user但忘了写服务类型，display logbuffer里会看到"Authentication failed"之类提示，链路起不来。所以AAA里三步缺一不可：local-user、密码、service-type。

第三个细节，华为设备在AAA视图下配置的本地用户，默认是带domain的，默认domain是default或者default_admin。如果你在客户端只写了用户名没有带域名，服务端也能匹配上，因为默认domain自动补齐了。但如果你的设备上做了多个domain，或者把用户交给了RADIUS认证，那客户端就必须写成user@domain的格式。这个在实际项目中很常见，企业网络往往用RADIUS鉴权，用户名后面必须带域名，否则AAA会直接拒绝。

3.3 验证与排错三板斧

PPP认证配置完，验证手段我一般用三条命令。

第一条是display interface Serial1/0/0，重点看Physical layer is up, Link protocol is up，只要物理层和链路层都Up，说明PPP认证已经通过了。如果链路层一直Down，多半是认证失败或者封装协议不匹配。

第二条是display ppp link，这条命令在Serial接口视图下执行，能看到PPP链路的状态机，包括LCP协商阶段、认证阶段（Authenticate）、网络层协议阶段（NCP）。如果在Authenticate阶段卡住，就说明认证有问题。

第三条是display aaa online-user，认证通过后能在AAA模块看到在线用户。华为AR上执行这条命令，能看到本地用户hcip在线。我看过很多人只ping通了链路就以为PPP认证配置成功了，其实如果配置的是PAP密码错误但IP地址还能通，那是不可能的——PPP认证不通过，NCP阶段就不会给对端分配网络层参数，IP根本不可能Ping通。所以"Ping通"本身就是一个很好的认证通过验证。

排错时如果链路层始终Down，建议在R1上执行terminal debugging和debugging ppp all，把PPP调试信息打开，看挑战值、用户名、错误原因。调试输出里如果能看到CHAP user hcip wrong之类的提示，基本就是用户名或者密码的问题，直接回AAA修正。调试完记得关掉，用undo debugging all，不然生产设备上CPU会一直被打印信息拖垮。

3.4 双向认证与真实链路的差异

考试实验一般做单向认证就够了，但实际专线场景运营商往往要求双向CHAP，也就是R1认证R2，R2也认证R1。配置方式是在R2上同样建立一组AAA用户，同时把R2的Serial接口也加上ppp authentication-mode chap，然后把两边的ppp chap user分别指向对方的用户名。

这里有一个很坑的点：双向认证时，同一台设备既是认证方又是被认证方，它的ppp chap user填的是本端发出去给对端验证的用户名，而local-user里存的是对端发过来要本端验证的用户名。这两个名字不能一样，更不能搞反。我见过有人把R1的local-user写成R1自己的名字，R2的local-user也写成R2自己的名字，结果两边都拿自己的用户名去挑战对端，对端本地用户表里查不到，认证全失败。正确做法是：R1的local-user存R2（客户端）的名字，R1的ppp chap user填R1（本端）的名字，R2反过来。

4. GRE隧道跨越PPP链路：从tunnel接口到keepalive

4.1 隧道接口配置的核心命令

PPP链路认证通过、Serial接口状态Up之后，GRE隧道就具备了基础条件。R1和R2的Tunnel接口配置如下：

# R1 GRE隧道配置 interface Tunnel0/0/0 tunnel-protocol gre ip address 10.1.3.1 255.255.255.252 source 10.1.1.1 destination 10.1.1.2 keepalive 5 3 mtu 1476

# R2 GRE隧道配置 interface Tunnel0/0/0 tunnel-protocol gre ip address 10.1.3.2 255.255.255.252 source 10.1.1.2 destination 10.1.1.1 keepalive 5 3 mtu 1476

注意，这里的source和destination填的是PPP物理接口的IP地址，不是Tunnel接口地址。source也可以写成接口名，比如source Serial1/0/0，设备会自动取该接口的IP作为隧道源。但我建议直接写IP地址，因为如果Serial接口的IP被改动，写接口名的配置会自动跟随新IP，有时候反而掩盖了真实的隧道源变化，排错时不容易想起来。

tunnel-protocol gre这条命令必须写，因为华为设备上Tunnel接口默认封装可能是其他协议（比如GRE over IPv6或者手动隧道），不显式声明GRE，后面的配置会报错或者行为不对。另外，华为AR上Tunnel接口默认允许GRE协议的，不需要像某些防火墙那样单独放行协议，但你的ACL如果对Serial接口做了入方向的流量过滤，必须放行协议号为47（GRE）的流量。

4.2 keepalive：隧道链路的"心跳线"

GRE隧道配置里有一行keepalive 5 3，很多人不知道它到底管什么。它的含义是：本端每5秒向对端发送一次GRE keepalive报文，如果连续3次没有收到对端的回应，就认为隧道链路不可用，将Tunnel接口的协议状态置为Down。

这个机制的实际价值体现在：物理链路断了，Serial接口会Down，Tunnel接口也会跟着Down，这是理想情况。但真实网络中还有另一种情况——物理链路没断，但中间的一段网络路径出现了单向故障（比如运营商侧发生了路由黑洞），Serial接口依然Up，但实际上GRE报文已经过不去了。没有keepalive，Tunnel接口会一直显示Up，静态路由一直存在，业务流量持续黑洞；有了keepalive，Tunnel接口会在几十秒内自动Down，流量自动切换到备份链路上。

这里我想特别说一下keepalive 5 3参数的计算。报文间隔5秒，重试次数3次，理论上检测时间最长是5秒乘以3次，也就是15秒。如果你觉得这个检测速度太慢，可以把间隔改成3秒，重试次数改成2，但注意：太激进的keepalive在长链路、高延迟的专线上可能产生误判，因为keepalive报文本身也需要PPP链路转发，链路过忙时偶发丢包就会导致隧道抖动。所以生产环境建议keepalive间隔不小于5秒，重试次数不小于3次。

另外一个容易忽略的点：GRE keepalive报文是走隧道内部通道的，也就是它在Tunnel接口上被封装成GRE报文，发给对端的Tunnel接口。所以在配置静态路由指向Tunnel接口时，一定要把对端私网网段的路由下一跳指向对端Tunnel地址，也就是10.1.3.2，这样才能保证业务流量进入Tunnel接口后，被GRE封装发往对端。

4.3 MTU与TCP MSS：1000字节包能通，1500字节包不通的元凶

GRE封装会额外增加一个24字节的外层IP头+GRE头，这导致Tunnel接口能承载的最大MTU只有1476字节（1500减24）。如果你不做任何调整，源端发送1500字节的TCP数据包，进入Tunnel接口后被封装成1524字节，超出物理接口MTU，这个包要么被分片，要么被丢弃。

华为设备默认对GRE封装后的报文有分片处理，但TCP的MSS协商机制会导致另一个问题：TCP三次握手时双方协商MSS，默认取接口MTU减40字节。在Tunnel接口上，TCP认为MTU是1500，协商MSS为1460，但实际隧道承载能力只有1476，减去TCP和IP头40字节后是1436，收到1460字节的段之后封装成1484字节，还是会超过1500，触发分片或者丢包。

解决办法有两个：一是把Tunnel接口的MTU调整为1476，二是针对VLANIF或物理接口调整TCP MSS。在华为AR上这样配置：

# 在Tunnel接口下调MTU interface Tunnel0/0/0 mtu 1476 # # 在物理接口/二层接口下调TCP MSS（如果内网终端通过交换机接入） interface GigabitEthernet0/0/0 tcp adjust-mss 1400

tcp adjust-mss是华为设备上非常实用的命令，它会在TCP三次握手报文经过该接口时，把MSS字段改写成指定值，从而避免端到端大包穿越GRE隧道时被分片。我实测过，如果在GRE隧道两端都不调MSS，FTP传大文件偶尔能传，但SSH登录和网页访问会频繁卡顿；调完之后业务流量稳定得多。这个点也是HCIP实验考试里经常被忽略的隐藏得分点，考官会在你"所有路由都通"的基础上，加上大包Ping测试，如果MTU和TCP MSS没调，1500字节的Ping就会失败。

4.4 隧道两端的路由注入

GRE隧道建立之后，总部和分支的私网路由要互相告诉对方。最简单的做法是写静态路由：

# R1上写去往分支内网的路由 ip route-static 192.168.104.0 255.255.255.0 Tunnel0/0/0 # R2上写去往总部内网的路由 ip route-static 172.16.0.0 255.255.255.0 Tunnel0/0/0

注意下一跳是Tunnel接口还是对端Tunnel地址。如果你的写法是ip route-static 192.168.104.0 255.255.255.0 10.1.3.2，那么在路由表里这条路由的下一跳是10.1.3.2，数据包要到达10.1.3.2需要查找直连路由，而直连路由指向Tunnel0/0/0，所以数据最终还是进入Tunnel。两种写法在结果上等价，但建议使用明确的接口写法（Tunnel0/0/0），因为华为设备的递归路由在某些场景下可能依赖下一跳可达性判断，如果Tunnel接口协议状态Up但实际路径有问题，路由会一直保留，行为不如直接绑定接口那么直观。

在路由这一层，也有一个容易踩的坑：R2上如果同时有默认路由指向互联网出口（为了做NAT），那么写ip route-static 172.16.0.0 255.255.255.0 Tunnel0/0/0时，一定要确保这一条静态路由比默认路由更优先。华为设备上默认路由优先级是60，静态路由默认优先级也是60，两条静态路由到达目标网段时会根据最长掩码匹配原则选择更具体的路由，所以172.16.0.0/24必然比0.0.0.0/0优先，这里一般不用特地去调优先级。但如果总部内网有多个分散网段，比如172.16.1.0/24、172.16.2.0/24，你就需要写多条明细静态路由，或者配置一条汇总路由指向Tunnel接口，否则部分流量会走默认路由掉进NAT，导致访问不到总部服务器。

5. NAT静态映射与回流：一条"reversible"命令引发的思考

5.1 分支出口的动态NAT配置

分支内网的192.168.104.0/24网段终端访问互联网时，需要在R2的出接口上做源地址转换。华为AR路由器上按接口做NAT，基本配置如下：

# R2 出接口NAT（假设出接口IP是202.100.1.2） acl number 3000 rule 5 permit ip source 192.168.104.0 0.0.0.255 quit # interface GigabitEthernet0/0/1 ip address 202.100.1.2 255.255.255.252 nat outbound 3000

nat outbound 3000的意思是，当数据包从GigabitEthernet0/0/1发出时，对符合ACL 3000规则的源地址做NAT转换，转换后的地址是出接口的IP地址。这是动态NAPT，所有分支终端共享202.100.1.2这一个公网IP，通过端口号区分不同会话。

但这里有个非常关键的点：如果分支终端访问的是总部内网服务器，也就是走GRE隧道的那部分流量，它的出接口是Tunnel0/0/0，根本不经过GigabitEthernet0/0/1，所以不会被NAT转换。这正是GRE隧道的一个"隐藏福利"——私网路由走隧道时，源地址保持原样，对端见到的就是客户端的真实IP，不需要任何NAT。反过来，如果总部和分支之间有重叠网段，那就必须在隧道和NAT之间做更精细的流量调度，但这就超出本文的讨论范围了。

5.2 静态NAT与reversible参数的实战含义

再来说标题里那条命令：nat static outbound 192.168.104.70 172.16.115.134 reversible。在很多HCIP题库和真实企业配置里，都会出现类似的静态NAT配置。它的完整含义是：把内网私网地址192.168.104.70一对一地映射为公网地址172.16.115.134，并且加上reversible参数后，公网地址172.16.115.134也可以主动访问内网主机192.168.104.70。

华为AR路由器上配置静态NAT，要在接口视图下做：

# R2 出接口静态NAT interface GigabitEthernet0/0/1 nat static outbound 192.168.104.70 172.16.115.134 reversible nat static enable

nat static enable是华为AR上启用静态NAT功能的开关，忘了这条命令，后面配置的static outbound不会生效。少写reversible的话，外网主动发起访问会被拒绝——因为设备只维护了"内网到外网"方向的转换表项，外网发来的流量无法通过NAT映射回到内网主机。

reversible参数（有的设备写作reverse，意思相同）是这个场景的灵魂。举个实际例子：分支有一台视频监控服务器，192.168.104.70，管理部门需要在总部或者互联网上直接访问它。如果不做NAT，公网侧根本没有到192.168.104.70的路由，访问不了；如果做普通静态NAT，只允许服务器主动向外访问，外网发的包进不来；加了reversible，数据包双向都能转换，服务器既能看到外部客户端，外部客户端也能看到服务器。

5.3 NAT回流：内网通过公网地址访问内网服务器的经典问题

与静态NAT相伴的还有一个经典问题，叫NAT回流（NAT Roaming或NAT Hairpin）。分支内网的终端通过公网地址172.16.115.134去访问192.168.104.70这台服务器时，数据包从终端发到R2，R2查找路由，发现目的地址是172.16.115.134，这属于公网地址，于是交给出接口处理。但如果出接口上没有对应的NAT回程规则，数据包就被丢弃或者路由循环，终端就上不去了。

华为AR路由器上，nat static outbound ... reversible通常能直接支持回流，因为静态NAT表项是双向的。但如果你用的是动态nat outbound做端口映射（nat server），回流往往需要额外配置。华为USG防火墙上的做法是在NAT策略和安全策略里同时放行：先创建NAT策略，把内网访问公网地址的流量也用一对一的映射转换回内网；再在安全策略中允许"内网-内网"在特定服务上的访问。很多人在USG6500上配置了NAT回流失败，排查的重点要放在安全策略和NAT策略的顺序上——USG是包过滤加状态检测的机制，NAT转换发生之后，安全策略的匹配是基于转换后地址的，所以你既要在NAT策略里允许回流，又要在安全策略里放行对应源目的，缺一个都通不了。

5.4 GRE流量与NAT流量的分流逻辑

回到综合拓扑里，R2上同时存在两种出接口：Tunnel0/0/0和GigabitEthernet0/0/1。分支终端访问总部服务器时，流量进GRE隧道，不经过NAT；分支终端访问互联网时，流量走GigabitEthernet0/0/1，被NAT。这个分流完全靠路由表完成。

但我见过一个真实翻车案例：有人为了省事，把R2的ACL规则写成了rule 5 permit ip，也就是允许所有源地址做NAT。结果分支终端访问总部服务器时，因为下一跳是Tunnel接口，数据进入GRE封装后，外层IP头是10.1.1.2到10.1.1.1，这个外层报文在物理链路上传输时，如果出接口GigabitEthernet0/0/1的NAT策略也处理它，就会把GRE外层源地址转换成公网地址，导致对端R1收到GRE报文后，发现源地址不是预期的10.1.1.2，无法正确解封装。轻则隧道抖动，重则GRE报文被NAT设备直接丢弃。

所以，凡是GRE隧道跨越NAT设备（或者与NAT在同一个出接口上），必须把GRE流量排除在NAT之外。ACL规则要写成只匹配内网终端访问互联网的流量：

acl number 3000 rule 5 permit ip source 192.168.104.0 0.0.0.255 destination 202.100.0.0 0.0.0.0 rule 10 deny ip source 192.168.104.0 0.0.0.255 destination 172.16.0.0 0.0.0.255

如果源地址和目的地址都不好穷举，更稳妥的办法是在物理出接口上只做nat outbound而不要做全地址的静态NAT，同时用ACL把私网到私网的流量deny掉。这个坑我会在排错章节里再详细讲一次。

6. 综合排错实录：我在这张拓扑上踩过的四个坑

6.1 坑一：CHAP认证显示的"用户名找不到"，其实是domain问题

第一次在这张拓扑上做双向CHAP，R1和R2的PPP认证怎么都不通过。我打开debugging ppp all，R1上输出的报错是CHAP user r2@default not found in the local database。当时我很奇怪，local-user里明明配了local-user r2，为什么显示的是r2@default？

后来才明白，华为设备上AAA的本地用户总是挂在某个domain下，默认域名是default。客户端发送的用户名如果没有显式带@domain，服务器端会把它自动补成r2@default。而我在local-user里配置的是local-user r2，没有指定domain，按理说也能匹配上，但问题出在认证方式上——如果设备开启了全局domain的默认认证域，且这个域的认证方式不是local而是RADIUS，那么即使本地用户存在，认证也会先发给RADIUS服务器，RADIUS不可达就会失败。

解决方式有两种。第一种是确认客户端发送的用户名格式，直接把客户端改成ppp chap user r2@default；第二种是确认服务器端domain的认证方案，执行display domain name default看认证方式，确保是authentication-mode local。这个坑在纯eNSP实验里不容易触发，因为eNSP默认就是local认证，但在真实设备和HCIP考试的环境里，网络环境往往已经配了RADIUS，所以看到"用户名找不到"先别急着加用户，查查domain配置。

6.2 坑二：GRE隧道协议Up，但路由总是不进Tunnel

另一个很有意思的坑：Tunnel接口协议状态是Up，但R1上Ping不到总部服务器。我查路由表，发现到172.16.0.0/24的路由下一跳不是Tunnel0/0/0，而是不知道从哪冒出来的直连路由。

原因在于我一开始在R1上写的静态路由是ip route-static 172.16.0.0 255.255.255.0 10.1.3.2，而10.1.3.2是Tunnel接口的地址。当Tunnel接口协议Down时，这条静态路由会变成inactive，这不奇怪。但问题是，我同时还在R1上配置了一条去往10.1.3.0/30的静态路由，下一跳指向Serial接口，结果形成了递归路由环路——去往10.1.3.2的流量要先查找10.1.3.0/30的静态路由，而这条路由的下一跳又是指向Tunnel接口，于是路由表出现环。

修正方式是删除那条多余的静态路由，让10.1.3.0/30的直连路由直接由Tunnel接口提供，同时把业务静态路由的下一跳直接写成Tunnel0/0/0接口名。这样路由表非常干净，不会出现递归环路。这也是我建议直接用接口做下一跳的原因之一。

6.3 坑三：NAT回流测试失败，检查方向还是检查安全策略

分支终端通过公网地址172.16.115.134访问内部服务器192.168.104.70，第一次测试直接超时。我检查了静态NAT配置没问题，display nat session也能看到转换表项，但数据包就是不通。

后来我在R2上开启了流量统计，发现从终端进来的包确实匹配到了NAT规则，也被转换了，但回程包在出接口上找不到对应会话，被设备丢弃。原因是我在配置nat static outbound ... reversible之后，又在同一个接口上配置了一条nat outbound 3000，两条NAT规则对同一个目标地址产生了冲突。动态NAPT优先处理了回程流量，把本该回到内网的包又重新转换了一次，导致状态混乱。

解决方式是把ACL 3000中的目标地址排除掉，也就是上一节提到的分流规则落地。具体做法是加一条高优先级的deny规则，明确拒绝私网到公网映射地址的NAT处理。这个坑在华为AR上是典型的"NAT规则顺序冲突"，排查思路是：先display nat rule看规则列表，再display nat session看会话表，最后看ACL匹配计数，三步下来基本能定位。

6.4 坑四：Ping大包不通，不是GRE是MTU，也不是路由，是中间设备的ICMP分片策略

GRE隧道和路由都正常，Ping小包通，Ping 1476字节的包也通，但Ping 1500字节的包不通。我一度以为是MTU配置没生效，检查Tunnel接口MTU确实是1476。后来用debugging ip icmp看，发现是中间运营商设备在收到超过MTU的GRE封装报文后，返回了ICMP Fragmentation Needed报文，但R2没有正确处理，导致源端不知道应该分片。

问题根因是GRE封装后外层IP头设置了DF标志（不分片标志），而中间某台设备（模拟器里是R3）的入接口MTU是1500，GRE封装后1524字节的报文被丢弃，同时回了一个ICMP错误。理论上源端应该根据ICMP错误自动降低报文大小，但华为AR上对GRE隧道入口的ICMP错误报文处理机制有前提条件——必须在Tunnel接口上开启icmp unreachable或调整策略，否则源端拿不到分片通知。

这个坑的通用解法就是前面提到的tcp adjust-mss。TCP应用可以通过调整MSS来规避大包，但ICMP Ping大包本身不带MSS协商，所以如果想彻底解决Ping大包问题，还得在业务路径的所有关键接口上把MTU调成一致，或者干脆放弃Ping大包验证，用TCP业务流实测。生产环境中我基本只做MSS调整，不再纠结Ping大包，因为实际业务流量都是TCP/UDP，MSS调整到位就没有分片问题。

7. HCIP实验答题顺序：从物理层到策略层的推进节奏

7.1 拿到综合实验题，先理清依赖关系

备考HCIP的人面对这种综合实验题，最怕的不是不会配，而是配的顺序乱，导致前面配完的东西被后面误改。我的经验是先理清依赖链：GRE隧道依赖PPP链路提供的IP连通性，私网路由依赖GRE隧道，NAT策略依赖出接口IP和路由可达。所以配置顺序一定是：先物理层（PPP认证），再隧道层（GRE），然后路由层（静态路由），最后策略层（NAT和ACL）。

这个顺序不是出于强迫症，而是每一步都可以独立验证。PPP配完，用display interface Serial确认链路层Up；GRE配完，用display interface Tunnel确认隧道协议Up；路由配完，用display ip routing-table确认私网路由存在；NAT最后配，因为NAT正确处理的前提是流量能到达出接口。如果你先做了NAT再调路由，一旦路由写错，NAT会话表里全是奇怪的转换记录，会严重干扰排错。

7.2 这道题的高频得分点与失分点

以这张拓扑为例，HCIP实验考官常考的得分点有这么几个：

一是CHAP认证的配置完整性。local-user的密码、service-type、ppp chap user的匹配、双向认证时用户名互换，这些都是实打实的配置题，错一个就丢一部分分。

二是GRE隧道封装和keepalive参数的合理性。有人配GRE忘了写tunnel-protocol gre，有人把keepalive配得不合理（比如keepalive 1 1），考官会通过修改链路状态来验证你的隧道能否快速感知故障。合理的keepalive 5 3能在15秒左右切换链路，这是标准答案的参考值。

三是MTU和TCP MSS的联动配置。很多考生把GRE隧道配通就万事大吉，考官如果加大包验证一下子露馅。mtu 1476和tcp adjust-mss 1400这两个参数必须成对出现，它们的设置逻辑我在4.3节里已经讲过了。

四是NAT的reversible语义。实验题如果要求外网主动访问内网服务器，就必须在静态NAT后加reversible，或者用nat server做端口映射。只写nat static outbound不带reversible，外网访问必然失败，这是非常典型的失分点。

失分点方面，最常见的三个：一是静态路由下一跳写法错误导致路由不生效；二是ACL规则配得过大把GRE流量也纳入NAT导致隧道断开；三是配置NAT时忘了nat static enable，静态映射根本不生效。这三条我在前面的排错章节都实际踩过，你可以对照着回顾一下自己的配置习惯。

7.3 实验验证方法：不要只靠Ping

在这类综合实验里，验证手段一定要分层。Ping只是最低级的验证，它只能告诉你通不通，不能告诉你哪里不通。我建议每次配置完一个阶段，都做一次对应的状态检查：

• PPP阶段：display ppp link看状态机，display aaa online-user看在线用户。
• GRE阶段：display interface Tunnel看协议状态，display ospf peer或者display bgp peer如果有动态路由协议，看邻居关系；纯静态路由就看display ip routing-table。
• NAT阶段：display nat session看会话转换记录，display nat rule看规则命中次数。

最后一句话送给备考和做项目的人：这张拓扑里看似最不起眼的往往是最容易翻车的。很多人觉得PPP认证配好链路自然通，GRE隧道配好路由自然通，NAT配好上网自然通，但实际把它们叠在一起，每一个环节的"小差异"都会在边界处放大。我写这么多，就是希望你能在动手配这张拓扑之前，先把每个技术点的边界画清楚，然后按依赖链一层一层往上搭。这样搭出来的网络，才是真正"任你折腾都不乱"的企业互联网络。