做企业网络项目或者正在备考华为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。具体接口规划如下设备接口IP地址用途R1Serial1/0/010.1.1.1/30连接运营商PPP认证ServerR1Tunnel0/0/010.1.3.1/30GRE隧道本端R1GigabitEthernet0/0/0172.16.0.1/24总部内网网关R2Serial1/0/010.1.1.2/30连接运营商PPP认证ClientR2Tunnel0/0/010.1.3.2/30GRE隧道对端R2GigabitEthernet0/0/0192.168.104.1/24分支内网网关R3Serial1/0/010.1.1.2/30模拟运营商侧接口注意R3不仅仅是一条直连线路我在R3上还加了另一条链路连到R2的另一个Serial接口专门用来做NAT出互联网的实验。这样拓扑就分成了两个维度总部和分支之间走GRE隧道分支上互联网走NAT。两条路径互不干扰但都在R2这一台设备上汇聚正好能测试流量的分流逻辑。2.2 地址规划里的三个不要做这个实验地址规划上我有三个教训分享出来给你避坑。第一隧道的源地址和目的地址不要用Loopback地址。很多教材喜欢用Loopback做隧道源因为Loopback稳定不掉线。但在PPP链路上你如果还没把物理接口的PPP认证调通Loopback地址虽然能Ping通对端但是GRE隧道依然起不来——因为GRE要求源和目的之间的IP连通性而PPP认证失败会直接导致物理链路DownLoopback地址根本路由不出去。所以老老实实用物理接口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 xxxCHAP的客户端配置是ppp chap user xxx配合ppp chap password xxx两种协议的密码配置命令完全不同。3.2 服务器端与客户端的完整配置R1作为CHAP认证的服务器端认证方配置如下# R1 认证方配置 sys sysname R1 # aaa local-user hcip password cipher HUAWEI123 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 chapR2作为被认证方配置如下# 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 HUAWEI123这里有三个细节值得注意。第一个细节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认证那客户端就必须写成userdomain的格式。这个在实际项目中很常见企业网络往往用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认证R2R2也认证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接口到keepalive4.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接口做了入方向的流量过滤必须放行协议号为47GRE的流量。4.2 keepalive隧道链路的心跳线GRE隧道配置里有一行keepalive 5 3很多人不知道它到底管什么。它的含义是本端每5秒向对端发送一次GRE keepalive报文如果连续3次没有收到对端的回应就认为隧道链路不可用将Tunnel接口的协议状态置为Down。这个机制的实际价值体现在物理链路断了Serial接口会DownTunnel接口也会跟着Down这是理想情况。但真实网络中还有另一种情况——物理链路没断但中间的一段网络路径出现了单向故障比如运营商侧发生了路由黑洞Serial接口依然Up但实际上GRE报文已经过不去了。没有keepaliveTunnel接口会一直显示Up静态路由一直存在业务流量持续黑洞有了keepaliveTunnel接口会在几十秒内自动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 MSS1000字节包能通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 1400tcp adjust-mss是华为设备上非常实用的命令它会在TCP三次握手报文经过该接口时把MSS字段改写成指定值从而避免端到端大包穿越GRE隧道时被分片。我实测过如果在GRE隧道两端都不调MSSFTP传大文件偶尔能传但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 3000nat 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 enablenat 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这台服务器时数据包从终端发到R2R2查找路由发现目的地址是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问题第一次在这张拓扑上做双向CHAPR1和R2的PPP认证怎么都不通过。我打开debugging ppp allR1上输出的报错是CHAP user r2default not found in the local database。当时我很奇怪local-user里明明配了local-user r2为什么显示的是r2default后来才明白华为设备上AAA的本地用户总是挂在某个domain下默认域名是default。客户端发送的用户名如果没有显式带domain服务器端会把它自动补成r2default。而我在local-user里配置的是local-user r2没有指定domain按理说也能匹配上但问题出在认证方式上——如果设备开启了全局domain的默认认证域且这个域的认证方式不是local而是RADIUS那么即使本地用户存在认证也会先发给RADIUS服务器RADIUS不可达就会失败。解决方式有两种。第一种是确认客户端发送的用户名格式直接把客户端改成ppp chap user r2default第二种是确认服务器端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是1500GRE封装后1524字节的报文被丢弃同时回了一个ICMP错误。理论上源端应该根据ICMP错误自动降低报文大小但华为AR上对GRE隧道入口的ICMP错误报文处理机制有前提条件——必须在Tunnel接口上开启icmp unreachable或调整策略否则源端拿不到分片通知。这个坑的通用解法就是前面提到的tcp adjust-mss。TCP应用可以通过调整MSS来规避大包但ICMP Ping大包本身不带MSS协商所以如果想彻底解决Ping大包问题还得在业务路径的所有关键接口上把MTU调成一致或者干脆放弃Ping大包验证用TCP业务流实测。生产环境中我基本只做MSS调整不再纠结Ping大包因为实际业务流量都是TCP/UDPMSS调整到位就没有分片问题。7. HCIP实验答题顺序从物理层到策略层的推进节奏7.1 拿到综合实验题先理清依赖关系备考HCIP的人面对这种综合实验题最怕的不是不会配而是配的顺序乱导致前面配完的东西被后面误改。我的经验是先理清依赖链GRE隧道依赖PPP链路提供的IP连通性私网路由依赖GRE隧道NAT策略依赖出接口IP和路由可达。所以配置顺序一定是先物理层PPP认证再隧道层GRE然后路由层静态路由最后策略层NAT和ACL。这个顺序不是出于强迫症而是每一步都可以独立验证。PPP配完用display interface Serial确认链路层UpGRE配完用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配好上网自然通但实际把它们叠在一起每一个环节的小差异都会在边界处放大。我写这么多就是希望你能在动手配这张拓扑之前先把每个技术点的边界画清楚然后按依赖链一层一层往上搭。这样搭出来的网络才是真正任你折腾都不乱的企业互联网络。