尧图网页设计 
HCIP备考阶段很多人会陷入一个误区单点技术练得滚瓜烂熟把题库里的PAP、CHAP、GRE、NAT命令背得一字不差但一到综合实验就卡壳。原因其实很简单——真实网络里的故障很少是单一技术造成的而是链路认证失败、隧道起不来、路由递归、NAT回流等多点问题叠加在一起。今天这套实验就是把PPP认证、GRE隧道和NAT三个HCIP高频考点串在同一个拓扑里从需求拆解到完整配置再到验证排错全部过程记录一遍。适合正在备考HCIP RS的人也适合那些想把“会背命令”变成“会排错”的新手网工。1. 实验需求与整体拓扑设计1.1 需求梳理为什么要把PPP认证、GRE隧道、NAT放在一起做先说清楚这个实验要解决的问题。三块技术单独练都很简单但放在真实场景里是强关联的分支机构的私网用户要访问总部的私网服务器中间隔着运营商网络链路层用PPP承载必须做认证来防止非法设备接入私网地址不能直接在公网上路由需要NAT转换总分支之间又要跑私有协议或业务不能靠公网地址直连于是用GRE隧道把两端的私网“缝合”起来。用一句话概括需求总部和分支通过串行链路相连中间模拟运营商公网分支内网用户需要访问总部内网服务器同时分支还要通过GRE隧道与总部内网互通全程要求链路做了PPP认证私网地址经过NAT转换并且隧道流量不经过NAT。这个需求拆分下来正好覆盖HCIP考试里的三个高频知识点PPP认证链路层安全接入控制PAP明文传输、CHAP密文挑战握手GRE隧道在三层公网之上叠加一层虚拟私网通道解决异网段私网互通NAT私网访问公网的地址转换包括静态NAT、动态NAT和回流NAT hairpin问题。如果你对照HCIP考试大纲看这三个知识点其实分布在“路由交换”和“网络安全”两个方向里单考都好过合在一起就考察你对协议栈的理解深度——PPP跑在物理链路之上GRE跑在三层之上NAT又工作在转发路径上三者会互相影响。很多人在实验里遇到的问题恰恰是“配置单看都对但串起来就不通”。1.2 拓扑规划接口、地址段和路由走向这个实验建议用华为eNSP或华三HCL搭建如果手头有真机更好。拓扑上用三台路由器就能覆盖全部需求我把设备命名和地址规划写清楚R1总部路由器连接总部内网服务器同时作为GRE隧道一端和对端PPP认证方R2分支路由器连接分支内网用户作为GRE隧道另一端和PPP被认证方R3运营商模拟路由器模拟中间公网不跑动态路由只提供转发通道。地址规划可以这么做设备接口地址用途R1Serial 1/0/010.0.0.1/30PPP链路与R2对接R1GigabitEthernet 0/0/0192.168.1.1/24总部内网R1Tunnel 0/0/0172.16.1.1/24GRE隧道口R2Serial 1/0/010.0.0.2/30PPP链路与R1对接R2GigabitEthernet 0/0/0192.168.2.1/24分支内网R2Tunnel 0/0/0172.16.1.2/24GRE隧道口R2GigabitEthernet 0/0/1203.0.113.2/30连接运营商公网R3GigabitEthernet 0/0/0203.0.113.1/30公网侧这里有两个细节容易被新手忽略。第一PPP链路两端必须配置相同的封装协议华为接口默认就是PPP但你把接口改成HDLC再改回来时认证配置会丢失后面我们会踩到这个坑。第二GRE隧道需要两端都有到对端物理地址的路由这个路由可以是静态的也可以是动态的但前提是物理链路要能通。所以这个实验的正确顺序是先配PPP认证确保物理链路UP再配GRE隧道口最后配NAT和路由。1.3 路由设计与流量路径分析路由是这个实验的灵魂。我特意设计了两条流量路径用来区分“走GRE”和“走NAT”的差异分支内网用户192.168.2.0/24访问公网服务器模拟外网走NAT在R2出接口上用动态NAT把私网地址转换出去分支内网用户访问总部内网服务器192.168.1.0/24走GRE隧道R2把流量封装进GRE头源目IP分别是R2和R1的公网地址R1与R2之间的管理流量走PPP物理链路不封装直接跑IP。这意味着R2上必须做路由策略区分目的地址是192.168.1.0/24的流量扔进Tunnel接口其他流量走默认路由出公网。很多人在这一步会犯迷糊——如果不加明细路由隧道流量和NAT流量就会混在一起导致从分支ping总部时回包被NAT转换给丢弃。用一句话理解路由的核心GRE隧道是“逻辑接口”它不关心物理链路是什么只管把私网报文封装后扔给对端公网地址NAT是“转发行为”它只处理穿越接口的IP报文不处理被GRE封装后的内层报文。所以GRE隧道口和对端地址之间的流量一定不能用NAT转换否则内层私网地址被改写隧道建立后也无法通信。2. PPP链路层认证PAP与CHAP的配置与踩坑2.1 先从最简单也最容易踩坑的PAP说起PAP认证是PPP协议里最简单的认证方式全程只有两次握手被认证方把用户名和密码明文发给认证方认证方核对后返回通过或拒绝。它的配置只有三行在R1认证方上[R1] interface Serial 1/0/0 [R1-Serial1/0/0] link-protocol ppp [R1-Serial1/0/0] ppp authentication-mode pap [R1-Serial1/0/0] quit [R1] aaa [R1-aaa] local-user hcip password cipher Hcip123 [R1-aaa] local-user hcip service-type ppp在R2被认证方上[R2] interface Serial 1/0/0 [R2-Serial1/0/0] link-protocol ppp [R2-Serial1/0/0] ppp pap local-user hcip password cipher Hcip123配置完成后把R1的Serial接口先shutdown再undo shutdown让PPP链路重新协商。看到接口状态变成“*down / up”才是真正常规状态——PPP链路跟物理链路不同物理UP不代表链路层UP只有协商完成、认证通过链路层才会出现UP。我来说说PAP的几个坑。第一PAP的密码是明文传输的抓包能看到所以华为设备默认用cipher保存本地密码但传输过程中仍然是明文这一点考试可能不会问实战中却很重要。第二PAP认证是“先认证后配置”最容易被坑的地方——如果你在R1上配置了认证模式但R2上没有配用户名密码链路会反复协商失败接口一直down。第三PAP认证通过后链路层状态显示为UP但很多人会忽略验证命令。验证命令很关键[R1] display ppp link [R1] display interface Serial 1/0/0如果PPP认证配置无误你会看到接口状态为Serial1/0/0 current state: UP。如果认证没通过状态会停在DOWN同时display ppp link里看不到对端信息。2.2 CHAP认证三次握手才是真正的考点CHAP和PAP最大的区别在于密码不进链路。CHAP是三次握手认证方向被认证方发送一个随机挑战值被认证方用MD5算法把挑战值加密码一起计算出一个响应值返回认证方再做同样的计算比对一致就通过。整个过程里密码只存在于两端设备本地链路上传的只有挑战值和摘要。配置CHAP认证认证方R1[R1] interface Serial 1/0/0 [R1-Serial1/0/0] ppp authentication-mode chap [R1-Serial1/0/0] quit [R1] aaa [R1-aaa] local-user hcip password cipher Hcip123 [R1-aaa] local-user hcip service-type ppp被认证方R2[R2] interface Serial 1/0/0 [R2-Serial1/0/0] ppp chap user hcip [R2-Serial1/0/0] ppp chap password cipher Hcip123这里有个华为特有的坑CHAP认证下R2上配的用户名要和R1本地用户一致如果两边不一致或者用户名一致但密码不同都会认证失败。另外CHAP的随机挑战值是每帧都会变的所以即使抓到数据包也无法重放或反推出密码。我还想多说一句CHAP的“双向认证”问题。很多资料里会说“CHAP是双向认证”这个说法有歧义。华为设备默认只做单向认证——只验证对端身份。要做双向认证需要在两端都配置ppp authentication-mode chap并各自维护对方的用户表。实验中常见的画面是你只在R1上配了认证R2没配R1会验证R2但R2绝不会验证R1这是正常的单向认证行为不是配置错误。2.3 认证模式选型差异与地址协商PPP认证模式选PAP还是CHAP在不同的考试题目里有不同套路。就实验本身而言我强烈建议做CHAP因为它的握手机制更复杂涉及验证命令也更多考试出过的概率明显更高。另一个容易出问题的点是IP地址协商。PPP链路两端的IP地址可以是手工配置也可以通过IPCP协商分配。实验里我用的是手工配置两端地址固定为10.0.0.1/30和10.0.0.2/30。如果用IPCP协商需要一端配置remote address另一端配置ip address ppp-negotiate配置复杂度会明显上升。考试题目一般不会让你做IPCP协商但你要能看懂命令。放一个我在实验里实际遇到的问题配置完CHAP后Serial接口一直downdisplay ppp link显示“CHAP authentication failed”。排查下来发现R1的AAA视图里没有创建local-user只配置了认证模式。这个顺序问题很典型——华为设备的ppp authentication-mode chap只是打开认证开关认证凭据必须去AAA里创建两者缺一不可。3. GRE隧道从封装原理到路由联动3.1 为什么GRE隧道需要“隧道口路由”双配置GREGeneric Routing Encapsulation是一个古老又通用的隧道协议。它做的事情很简单把一个完整的IP报文当作载荷外面再套一层新的IP头然后送给对端的物理接口。被套的报文可以是私网地址也可以是组播或广播报文这正是GRE比单纯IP-in-IP更灵活的地方——可以承载路由协议报文。GRE配置有两步是必须的第一步创建Tunnel接口并配置隧道源和隧道目的第二步把需要走隧道的私网路由从Tunnel接口发布。这两步缺一不可因为Tunnel接口只是一个逻辑口它本身不转发报文真正决定报文走向的是路由表。我从一个常见错误说起。有人创建了Tunnel接口配置了IP地址也配置了tunnel-source和tunnel-destination但在R2上ping 192.168.1.1时不通。排查发现路由表里没有到192.168.1.0/24的路由。原因很简单GRE隧道只解决“怎么封装”的问题不解决“往哪儿送”的问题。你必须在R2上加一条静态路由[R2] ip route-static 192.168.1.0 255.255.255.0 Tunnel 0/0/0同时R1上也要有回程路由[R1] ip route-static 192.168.2.0 255.255.255.0 Tunnel 0/0/0加了这两条静态路由后隧道才能承载业务流量。3.2 隧道配置逐步演示R1上的GRE隧道配置[R1] interface Tunnel 0/0/0 [R1-Tunnel0/0/0] ip address 172.16.1.1 255.255.255.0 [R1-Tunnel0/0/0] tunnel-protocol gre [R1-Tunnel0/0/0] source 10.0.0.1 [R1-Tunnel0/0/0] destination 10.0.0.2 [R1-Tunnel0/0/0] quitR2上的GRE隧道配置[R2] interface Tunnel 0/0/0 [R2-Tunnel0/0/0] ip address 172.16.1.2 255.255.255.0 [R2-Tunnel0/0/0] tunnel-protocol gre [R2-Tunnel0/0/0] source 10.0.0.2 [R2-Tunnel0/0/0] destination 10.0.0.1 [R2-Tunnel0/0/0] quit等等这里有个关键细节隧道源地址我用的是PPP链路地址10.0.0.x不是公网接口地址。这是因为实验拓扑里PPP链路本身就模拟了公网链路物理可达性是通过PPP链路建立的。如果你把隧道源写成公网接口地址就必须保证这个地址能被对端路由到。配置完之后关键验证是[R2] ping -a 172.16.1.2 172.16.1.1这条命令的-a参数指定源地址为隧道口地址。如果GRE隧道配置正确这条ping会通如果不通八成是隧道源目的地址配置颠倒或者物理链路出了问题。还有一个更直接的验证方式[R2] display tunnel-info all [R2] display interface Tunnel 0/0/0当隧道口协议状态为UP时你还能看到GRE封装统计信息。用display interface Tunnel 0/0/0查看时如果状态为current state: UP、Line protocol state: UP说明GRE隧道已经建立。如果协议状态是DOWN最常见的原因是隧道源地址或目的地址错了要么就是物理链路没通。3.3 不同厂商互联时的GRE兼容性如果你做实验用的是华三HCL或者公司里混着华为和华三设备要注意GRE隧道参数的兼容性。华为的tunnel-protocol gre和华三的tunnel-protocol gre在基础配置上可以互通但有个细节华三的Tunnel接口需要额外配置gre key enable才能对GRE报文做密钥校验华为则默认不校验。两家对接时要么两边都不配key要么都配相同key否则隧道建立不起来。还有一个厂商差异是keepalive。华为Tunnel接口默认不发送keepalive华三默认也不发但有些思科设备默认会发keepalive报文。如果两边一端发另一端不回就可能出现隧道接口一直UP、实际转发不通的诡异现象。考试不一定考这个但真实割接时你肯定会碰到。我给一个实操建议做这个综合实验时把GRE隧道里的源目地址和路由策略放在最后排查。因为GRE隧道是否UP跟物理链路、PPP认证是强依赖的链路层认证没过隧道协议状态必然DOWN。如果你看到Tunnel口DOWN先去查物理接口状态再查PPP认证最后才查隧道配置本身。4. NAT配置与访问优化4.1 静态NAT和动态NAT的适用场景NAT在这个实验里要解决两件事第一分支内网用户访问公网需要地址转换第二总部内网服务器要被分支用户通过隧道访问时不能被NAT二次转换。搞清楚这两件事NAT配置就不会迷茫。先说静态NAT。它是一对一的固定映射适合对外提供服务的服务器场景。比如把分支内网一台服务器映射为公网固定地址外部访问时就能准确找到它。配置命令很短[R2] interface GigabitEthernet 0/0/1 [R2-GigabitEthernet0/0/1] nat static enable [R2-GigabitEthernet0/0/1] quit [R2] nat static outbound 192.168.2.10 203.0.113.10这条命令的意思是源地址为192.168.2.10的报文出去时NAT转换成203.0.113.10回程报文做反向转换。注意华为NAT静态映射是在接口下使能的如果接口没开nat static enable静态NAT不生效。动态NAT解决的是内网大量用户访问公网的问题。用户数量多、地址有限用地址池方式动态分配通信结束后归还地址。配置分三步定义地址池、配置ACL匹配内网用户、在接口上应用并进行转换[R2] nat address-group 1 203.0.113.20 203.0.113.50 [R2] acl number 2000 [R2-acl-basic-2000] rule 5 permit source 192.168.2.0 0.0.0.255 [R2-acl-basic-2000] quit [R2] interface GigabitEthernet 0/0/1 [R2-GigabitEthernet0/0/1] nat outbound 2000 address-group 1这里ACL 2000是基础ACL只匹配源地址nat outbound在接口出方向做转换。动态NAT有个显著特点它只做源地址转换不固定端口会话结束后地址回收适合内网用户上网场景。4.2 实际NAT配置记录这个实验里我在R2的GigabitEthernet 0/0/1上配置了动态NAT让192.168.2.0/24网段的用户访问公网203.0.113.0/30之外的网络时做地址转换。配置过程如下定义公网地址池用ACL匹配内网用户在出接口应用NAT验证并查看NAT会话。配置完成后用display nat session all可以查看当前会话表看到源地址、目的地址、转换前后地址的对应关系。如果会话表正常生成说明NAT转换生效。有个细节必须强调GRE隧道流量不要做NAT。原因是隧道封装后的报文外层IP头是隧道源目的地址内层才是真正的用户私网地址。如果让NAT处理隧道报文会把外层源地址修改掉隧道对端收到后无法正确回复导致隧道断开。解决办法是用ACL把需要走隧道的流量排除在NAT匹配范围之外。具体来说ACL 2000只匹配192.168.2.0/24访问非隧道目的地址的流量。由于隧道流量在R2上会先匹配明细路由送到Tunnel接口不会走到出接口NAT所以实际上不会冲突。但为了保险你还是要把这段理解清楚路由决定流量走向NAT在出接口上执行同一台设备上流量先查路由表再决定是否经过出接口的NAT处理。4.3 NAT回流问题与处理方法NAT回流NAT hairpin是HCIP考试里一个高频难点也是实验里容易遇到的现象。什么叫回流就是内网用户通过公网地址访问自己内网服务器。比如分支用户通过NAT的公网地址去访问分支自己的服务器流量从内网出发到出接口做NAT回来后又要送到内网形成“U型转发”。华为设备在默认情况下内网访问内网通过公网地址是不通的因为报文到达出接口做NAT时源地址和目的地址都在内网NAT认为这是内部流量不处理导致丢包。要解决回流问题需要在出接口的入方向也做NAT或者开启nat hairpin功能。在实际实验里我建议把回流问题作为思考题考察自己分支内网PC通过203.0.113.10访问分支内网服务器通不通如果不通原因是什么这个问题的答案恰恰是HCIP考试里NAT配置的重要区别——单出口NAT和带回流功能的NAT。还有一个容易被忽略的点NAT和GRE隧道同时启用时隧道流量的回程报文不能做NAT。因为GRE隧道封装后外层IP头的源地址是公网地址比如隧道源如果回程也做NAT会把外层目的地址改成私网地址隧道对端根本无法识别。所以在配置NAT时一定要通过ACL精确匹配需要转换的流量拒绝所有隧道相关流量被NAT处理。实操中怎么确认回流有没有问题在分支内网PC上ping公网地址如果通了再用display nat session all查看会话看到双向会话表正常生成就说明NAT工作正常。如果内网访问公网通但访问总部内网服务器不通别急着查GRE隧道先在R2上确认到192.168.1.0/24的路由是否指向Tunnel接口——这个问题90%出在路由上不是隧道本身。5. 综合验证与排错实录5.1 从物理链路到隧道再到NAT的分层验证综合实验最忌讳的是“哪里不通就怀疑哪里”。我惯用的验证思路是“从低到高分层排查”先看物理与链路层再看三层连通性再看隧道最后看NAT。第一步验证PPP链路状态。[R2] display interface Serial 1/0/0接口状态应该是UP、UP。如果链路层down先去查PPP认证配置如果物理down检查两端接口是否no shutdown、线路参数是否匹配。第二步验证物理链路三层连通性。[R2] ping 10.0.0.1这条命令通了说明PPP链路完全正常PAP或CHAP认证、地址协商都没问题。第三步验证GRE隧道。[R2] ping -a 172.16.1.2 172.16.1.1通了说明隧道封装和解封装逻辑正确。如果不通去查Tunnel口的源目地址、display tunnel-info all和物理链路。第四步验证跨私网通信。[R2] ping -a 192.168.2.1 192.168.1.1通了说明私网路由和GRE隧道整体联动成功。第五步验证NAT。[R2] display nat session all看到有公网地址转换会话就说明NAT生效。这个验证顺序能帮你快速定位问题层级哪一步ping不通问题就在哪一层。如果真的从第四步就失败了不要急着怀疑NAT——先回头确认GRE隧道口是否UP再确认路由表里是否有到192.168.1.0/24的明细路由。5.2 典型故障现象与排查思路速查表我把这次实验中最容易翻车的几个故障整理成了表格方便对照排查故障现象可能原因排查命令解决思路Serial接口downPPP认证未通过display ppp link检查AAA用户配置和密码Serial接口up但ping不通对端IP地址配置错误或两端网段不一致display ip interface brief核对PPP链路两端地址规划Tunnel接口协议down隧道源目地址不可达display interface Tunnel 0/0/0ping通隧道源地址再检查隧道配置Tunnel接口up但私网ping不通缺私网路由或路由指向错误display ip routing-table添加指向Tunnel接口的明细路由分支内网能上网但访问总部不通GRE隧道未承载路由display ip routing-table 192.168.1.0把总部私网路由指到Tunnel口NAT会话表无记录出接口NAT未应用或ACL不匹配display acl all检查ACL规则是否允许内网网段NAT后访问公网通但回程丢包NAT只配置了出方向未配置回程处理display nat session all华为出接口NAT自动处理回程流量检查会话双向状态5.3 三个最容易被忽略的操作细节第一个细节华为接口默认封装是PPP但你在做实验时如果曾经把接口改成过HDLC或帧中继再改回PPP后PPP认证配置会全部丢失。我踩过这个坑——把所有认证命令敲完后链路仍然down排查半天才发现接口封装被改成了HDLCPPP认证命令根本没生效。第二个细节GRE隧道地址和底层物理地址不能同网段。这是华为设备明确禁止的配置逻辑——如果隧道源地址和隧道口地址同一个网段会造成路由递归数据包要出隧道口去往隧道源地址再匹配到同一个隧道口形成环路。实验里我用的是172.16.1.0/24作为隧道地址10.0.0.0/30作为物理链路地址两者隔离就是避免这个递归问题。第三个细节ping测试一定要带源地址。很多人配置完隧道后用ping 172.16.1.1结果系统选择源地址时用了物理接口地址导致报文根本没有进隧道口。正确做法是用ping -a 隧道口地址 对端隧道口地址强制让源地址从Tunnel口发出才能验证隧道的真实连通性。5.4 这个实验后续还可以怎么扩展做完这套综合实验你已经把PPP、GRE、NAT串起来了。如果你想再往上走一步有两条扩展路径特别推荐一是把静态路由换成OSPF。在Tunnel接口之间跑OSPF看看GRE隧道承载路由协议的效果感受一下“逻辑口参与路由计算”的过程——OSPF会认为Tunnel接口是物理链路DR选举、Hello报文、LSA洪泛全部跑在GRE隧道之上比起直连路由观察起来更有意思。二是给GRE隧道加IPSec加密。这也是实际企业组网里最常见的需求GRE负责封装IPSec负责加密两个协议叠加在一起。你会在配置过程中发现GRE隧道建立之后IPSec协商的是隧道内层协议报文的加解密发生在物理接口和隧道口之间这个转发流程画出来比你背十遍协议原理都清楚。最后再分享一点实操层面的体会做这个综合实验我最大的感触是不要按“先把每个技术配完再统一验证”的思路做而是“配一层、验一层”。PPP认证配上就去验证链路链路通了再建GRE隧道隧道通了再加NAT。这样每一层都是基于一个已验证过的底座往上叠加排错范围会被压缩到最小。尤其是GRE和NAT同时存在时一旦顺序乱了故障现象会互相掩盖——你以为是NAT的问题其实路由丢了你以为是路由的问题其实隧道封装有问题。按层次一层的排查习惯比背多少命令都管用。还有一个小技巧配置前先把所有接口的IP地址和路由方向画在一张表上标注清楚哪个流量走隧道、哪个流量走NAT配置时对照着来。这个习惯帮我少走很多弯路考试时也能有效减少失误。 HCIP综合实验：PPP认证、GRE隧道与NAT配置排错实战
HCIP备考阶段很多人会陷入一个误区单点技术练得滚瓜烂熟把题库里的PAP、CHAP、GRE、NAT命令背得一字不差但一到综合实验就卡壳。原因其实很简单——真实网络里的故障很少是单一技术造成的而是链路认证失败、隧道起不来、路由递归、NAT回流等多点问题叠加在一起。今天这套实验就是把PPP认证、GRE隧道和NAT三个HCIP高频考点串在同一个拓扑里从需求拆解到完整配置再到验证排错全部过程记录一遍。适合正在备考HCIP RS的人也适合那些想把“会背命令”变成“会排错”的新手网工。1. 实验需求与整体拓扑设计1.1 需求梳理为什么要把PPP认证、GRE隧道、NAT放在一起做先说清楚这个实验要解决的问题。三块技术单独练都很简单但放在真实场景里是强关联的分支机构的私网用户要访问总部的私网服务器中间隔着运营商网络链路层用PPP承载必须做认证来防止非法设备接入私网地址不能直接在公网上路由需要NAT转换总分支之间又要跑私有协议或业务不能靠公网地址直连于是用GRE隧道把两端的私网“缝合”起来。用一句话概括需求总部和分支通过串行链路相连中间模拟运营商公网分支内网用户需要访问总部内网服务器同时分支还要通过GRE隧道与总部内网互通全程要求链路做了PPP认证私网地址经过NAT转换并且隧道流量不经过NAT。这个需求拆分下来正好覆盖HCIP考试里的三个高频知识点PPP认证链路层安全接入控制PAP明文传输、CHAP密文挑战握手GRE隧道在三层公网之上叠加一层虚拟私网通道解决异网段私网互通NAT私网访问公网的地址转换包括静态NAT、动态NAT和回流NAT hairpin问题。如果你对照HCIP考试大纲看这三个知识点其实分布在“路由交换”和“网络安全”两个方向里单考都好过合在一起就考察你对协议栈的理解深度——PPP跑在物理链路之上GRE跑在三层之上NAT又工作在转发路径上三者会互相影响。很多人在实验里遇到的问题恰恰是“配置单看都对但串起来就不通”。1.2 拓扑规划接口、地址段和路由走向这个实验建议用华为eNSP或华三HCL搭建如果手头有真机更好。拓扑上用三台路由器就能覆盖全部需求我把设备命名和地址规划写清楚R1总部路由器连接总部内网服务器同时作为GRE隧道一端和对端PPP认证方R2分支路由器连接分支内网用户作为GRE隧道另一端和PPP被认证方R3运营商模拟路由器模拟中间公网不跑动态路由只提供转发通道。地址规划可以这么做设备接口地址用途R1Serial 1/0/010.0.0.1/30PPP链路与R2对接R1GigabitEthernet 0/0/0192.168.1.1/24总部内网R1Tunnel 0/0/0172.16.1.1/24GRE隧道口R2Serial 1/0/010.0.0.2/30PPP链路与R1对接R2GigabitEthernet 0/0/0192.168.2.1/24分支内网R2Tunnel 0/0/0172.16.1.2/24GRE隧道口R2GigabitEthernet 0/0/1203.0.113.2/30连接运营商公网R3GigabitEthernet 0/0/0203.0.113.1/30公网侧这里有两个细节容易被新手忽略。第一PPP链路两端必须配置相同的封装协议华为接口默认就是PPP但你把接口改成HDLC再改回来时认证配置会丢失后面我们会踩到这个坑。第二GRE隧道需要两端都有到对端物理地址的路由这个路由可以是静态的也可以是动态的但前提是物理链路要能通。所以这个实验的正确顺序是先配PPP认证确保物理链路UP再配GRE隧道口最后配NAT和路由。1.3 路由设计与流量路径分析路由是这个实验的灵魂。我特意设计了两条流量路径用来区分“走GRE”和“走NAT”的差异分支内网用户192.168.2.0/24访问公网服务器模拟外网走NAT在R2出接口上用动态NAT把私网地址转换出去分支内网用户访问总部内网服务器192.168.1.0/24走GRE隧道R2把流量封装进GRE头源目IP分别是R2和R1的公网地址R1与R2之间的管理流量走PPP物理链路不封装直接跑IP。这意味着R2上必须做路由策略区分目的地址是192.168.1.0/24的流量扔进Tunnel接口其他流量走默认路由出公网。很多人在这一步会犯迷糊——如果不加明细路由隧道流量和NAT流量就会混在一起导致从分支ping总部时回包被NAT转换给丢弃。用一句话理解路由的核心GRE隧道是“逻辑接口”它不关心物理链路是什么只管把私网报文封装后扔给对端公网地址NAT是“转发行为”它只处理穿越接口的IP报文不处理被GRE封装后的内层报文。所以GRE隧道口和对端地址之间的流量一定不能用NAT转换否则内层私网地址被改写隧道建立后也无法通信。2. PPP链路层认证PAP与CHAP的配置与踩坑2.1 先从最简单也最容易踩坑的PAP说起PAP认证是PPP协议里最简单的认证方式全程只有两次握手被认证方把用户名和密码明文发给认证方认证方核对后返回通过或拒绝。它的配置只有三行在R1认证方上[R1] interface Serial 1/0/0 [R1-Serial1/0/0] link-protocol ppp [R1-Serial1/0/0] ppp authentication-mode pap [R1-Serial1/0/0] quit [R1] aaa [R1-aaa] local-user hcip password cipher Hcip123 [R1-aaa] local-user hcip service-type ppp在R2被认证方上[R2] interface Serial 1/0/0 [R2-Serial1/0/0] link-protocol ppp [R2-Serial1/0/0] ppp pap local-user hcip password cipher Hcip123配置完成后把R1的Serial接口先shutdown再undo shutdown让PPP链路重新协商。看到接口状态变成“*down / up”才是真正常规状态——PPP链路跟物理链路不同物理UP不代表链路层UP只有协商完成、认证通过链路层才会出现UP。我来说说PAP的几个坑。第一PAP的密码是明文传输的抓包能看到所以华为设备默认用cipher保存本地密码但传输过程中仍然是明文这一点考试可能不会问实战中却很重要。第二PAP认证是“先认证后配置”最容易被坑的地方——如果你在R1上配置了认证模式但R2上没有配用户名密码链路会反复协商失败接口一直down。第三PAP认证通过后链路层状态显示为UP但很多人会忽略验证命令。验证命令很关键[R1] display ppp link [R1] display interface Serial 1/0/0如果PPP认证配置无误你会看到接口状态为Serial1/0/0 current state: UP。如果认证没通过状态会停在DOWN同时display ppp link里看不到对端信息。2.2 CHAP认证三次握手才是真正的考点CHAP和PAP最大的区别在于密码不进链路。CHAP是三次握手认证方向被认证方发送一个随机挑战值被认证方用MD5算法把挑战值加密码一起计算出一个响应值返回认证方再做同样的计算比对一致就通过。整个过程里密码只存在于两端设备本地链路上传的只有挑战值和摘要。配置CHAP认证认证方R1[R1] interface Serial 1/0/0 [R1-Serial1/0/0] ppp authentication-mode chap [R1-Serial1/0/0] quit [R1] aaa [R1-aaa] local-user hcip password cipher Hcip123 [R1-aaa] local-user hcip service-type ppp被认证方R2[R2] interface Serial 1/0/0 [R2-Serial1/0/0] ppp chap user hcip [R2-Serial1/0/0] ppp chap password cipher Hcip123这里有个华为特有的坑CHAP认证下R2上配的用户名要和R1本地用户一致如果两边不一致或者用户名一致但密码不同都会认证失败。另外CHAP的随机挑战值是每帧都会变的所以即使抓到数据包也无法重放或反推出密码。我还想多说一句CHAP的“双向认证”问题。很多资料里会说“CHAP是双向认证”这个说法有歧义。华为设备默认只做单向认证——只验证对端身份。要做双向认证需要在两端都配置ppp authentication-mode chap并各自维护对方的用户表。实验中常见的画面是你只在R1上配了认证R2没配R1会验证R2但R2绝不会验证R1这是正常的单向认证行为不是配置错误。2.3 认证模式选型差异与地址协商PPP认证模式选PAP还是CHAP在不同的考试题目里有不同套路。就实验本身而言我强烈建议做CHAP因为它的握手机制更复杂涉及验证命令也更多考试出过的概率明显更高。另一个容易出问题的点是IP地址协商。PPP链路两端的IP地址可以是手工配置也可以通过IPCP协商分配。实验里我用的是手工配置两端地址固定为10.0.0.1/30和10.0.0.2/30。如果用IPCP协商需要一端配置remote address另一端配置ip address ppp-negotiate配置复杂度会明显上升。考试题目一般不会让你做IPCP协商但你要能看懂命令。放一个我在实验里实际遇到的问题配置完CHAP后Serial接口一直downdisplay ppp link显示“CHAP authentication failed”。排查下来发现R1的AAA视图里没有创建local-user只配置了认证模式。这个顺序问题很典型——华为设备的ppp authentication-mode chap只是打开认证开关认证凭据必须去AAA里创建两者缺一不可。3. GRE隧道从封装原理到路由联动3.1 为什么GRE隧道需要“隧道口路由”双配置GREGeneric Routing Encapsulation是一个古老又通用的隧道协议。它做的事情很简单把一个完整的IP报文当作载荷外面再套一层新的IP头然后送给对端的物理接口。被套的报文可以是私网地址也可以是组播或广播报文这正是GRE比单纯IP-in-IP更灵活的地方——可以承载路由协议报文。GRE配置有两步是必须的第一步创建Tunnel接口并配置隧道源和隧道目的第二步把需要走隧道的私网路由从Tunnel接口发布。这两步缺一不可因为Tunnel接口只是一个逻辑口它本身不转发报文真正决定报文走向的是路由表。我从一个常见错误说起。有人创建了Tunnel接口配置了IP地址也配置了tunnel-source和tunnel-destination但在R2上ping 192.168.1.1时不通。排查发现路由表里没有到192.168.1.0/24的路由。原因很简单GRE隧道只解决“怎么封装”的问题不解决“往哪儿送”的问题。你必须在R2上加一条静态路由[R2] ip route-static 192.168.1.0 255.255.255.0 Tunnel 0/0/0同时R1上也要有回程路由[R1] ip route-static 192.168.2.0 255.255.255.0 Tunnel 0/0/0加了这两条静态路由后隧道才能承载业务流量。3.2 隧道配置逐步演示R1上的GRE隧道配置[R1] interface Tunnel 0/0/0 [R1-Tunnel0/0/0] ip address 172.16.1.1 255.255.255.0 [R1-Tunnel0/0/0] tunnel-protocol gre [R1-Tunnel0/0/0] source 10.0.0.1 [R1-Tunnel0/0/0] destination 10.0.0.2 [R1-Tunnel0/0/0] quitR2上的GRE隧道配置[R2] interface Tunnel 0/0/0 [R2-Tunnel0/0/0] ip address 172.16.1.2 255.255.255.0 [R2-Tunnel0/0/0] tunnel-protocol gre [R2-Tunnel0/0/0] source 10.0.0.2 [R2-Tunnel0/0/0] destination 10.0.0.1 [R2-Tunnel0/0/0] quit等等这里有个关键细节隧道源地址我用的是PPP链路地址10.0.0.x不是公网接口地址。这是因为实验拓扑里PPP链路本身就模拟了公网链路物理可达性是通过PPP链路建立的。如果你把隧道源写成公网接口地址就必须保证这个地址能被对端路由到。配置完之后关键验证是[R2] ping -a 172.16.1.2 172.16.1.1这条命令的-a参数指定源地址为隧道口地址。如果GRE隧道配置正确这条ping会通如果不通八成是隧道源目的地址配置颠倒或者物理链路出了问题。还有一个更直接的验证方式[R2] display tunnel-info all [R2] display interface Tunnel 0/0/0当隧道口协议状态为UP时你还能看到GRE封装统计信息。用display interface Tunnel 0/0/0查看时如果状态为current state: UP、Line protocol state: UP说明GRE隧道已经建立。如果协议状态是DOWN最常见的原因是隧道源地址或目的地址错了要么就是物理链路没通。3.3 不同厂商互联时的GRE兼容性如果你做实验用的是华三HCL或者公司里混着华为和华三设备要注意GRE隧道参数的兼容性。华为的tunnel-protocol gre和华三的tunnel-protocol gre在基础配置上可以互通但有个细节华三的Tunnel接口需要额外配置gre key enable才能对GRE报文做密钥校验华为则默认不校验。两家对接时要么两边都不配key要么都配相同key否则隧道建立不起来。还有一个厂商差异是keepalive。华为Tunnel接口默认不发送keepalive华三默认也不发但有些思科设备默认会发keepalive报文。如果两边一端发另一端不回就可能出现隧道接口一直UP、实际转发不通的诡异现象。考试不一定考这个但真实割接时你肯定会碰到。我给一个实操建议做这个综合实验时把GRE隧道里的源目地址和路由策略放在最后排查。因为GRE隧道是否UP跟物理链路、PPP认证是强依赖的链路层认证没过隧道协议状态必然DOWN。如果你看到Tunnel口DOWN先去查物理接口状态再查PPP认证最后才查隧道配置本身。4. NAT配置与访问优化4.1 静态NAT和动态NAT的适用场景NAT在这个实验里要解决两件事第一分支内网用户访问公网需要地址转换第二总部内网服务器要被分支用户通过隧道访问时不能被NAT二次转换。搞清楚这两件事NAT配置就不会迷茫。先说静态NAT。它是一对一的固定映射适合对外提供服务的服务器场景。比如把分支内网一台服务器映射为公网固定地址外部访问时就能准确找到它。配置命令很短[R2] interface GigabitEthernet 0/0/1 [R2-GigabitEthernet0/0/1] nat static enable [R2-GigabitEthernet0/0/1] quit [R2] nat static outbound 192.168.2.10 203.0.113.10这条命令的意思是源地址为192.168.2.10的报文出去时NAT转换成203.0.113.10回程报文做反向转换。注意华为NAT静态映射是在接口下使能的如果接口没开nat static enable静态NAT不生效。动态NAT解决的是内网大量用户访问公网的问题。用户数量多、地址有限用地址池方式动态分配通信结束后归还地址。配置分三步定义地址池、配置ACL匹配内网用户、在接口上应用并进行转换[R2] nat address-group 1 203.0.113.20 203.0.113.50 [R2] acl number 2000 [R2-acl-basic-2000] rule 5 permit source 192.168.2.0 0.0.0.255 [R2-acl-basic-2000] quit [R2] interface GigabitEthernet 0/0/1 [R2-GigabitEthernet0/0/1] nat outbound 2000 address-group 1这里ACL 2000是基础ACL只匹配源地址nat outbound在接口出方向做转换。动态NAT有个显著特点它只做源地址转换不固定端口会话结束后地址回收适合内网用户上网场景。4.2 实际NAT配置记录这个实验里我在R2的GigabitEthernet 0/0/1上配置了动态NAT让192.168.2.0/24网段的用户访问公网203.0.113.0/30之外的网络时做地址转换。配置过程如下定义公网地址池用ACL匹配内网用户在出接口应用NAT验证并查看NAT会话。配置完成后用display nat session all可以查看当前会话表看到源地址、目的地址、转换前后地址的对应关系。如果会话表正常生成说明NAT转换生效。有个细节必须强调GRE隧道流量不要做NAT。原因是隧道封装后的报文外层IP头是隧道源目的地址内层才是真正的用户私网地址。如果让NAT处理隧道报文会把外层源地址修改掉隧道对端收到后无法正确回复导致隧道断开。解决办法是用ACL把需要走隧道的流量排除在NAT匹配范围之外。具体来说ACL 2000只匹配192.168.2.0/24访问非隧道目的地址的流量。由于隧道流量在R2上会先匹配明细路由送到Tunnel接口不会走到出接口NAT所以实际上不会冲突。但为了保险你还是要把这段理解清楚路由决定流量走向NAT在出接口上执行同一台设备上流量先查路由表再决定是否经过出接口的NAT处理。4.3 NAT回流问题与处理方法NAT回流NAT hairpin是HCIP考试里一个高频难点也是实验里容易遇到的现象。什么叫回流就是内网用户通过公网地址访问自己内网服务器。比如分支用户通过NAT的公网地址去访问分支自己的服务器流量从内网出发到出接口做NAT回来后又要送到内网形成“U型转发”。华为设备在默认情况下内网访问内网通过公网地址是不通的因为报文到达出接口做NAT时源地址和目的地址都在内网NAT认为这是内部流量不处理导致丢包。要解决回流问题需要在出接口的入方向也做NAT或者开启nat hairpin功能。在实际实验里我建议把回流问题作为思考题考察自己分支内网PC通过203.0.113.10访问分支内网服务器通不通如果不通原因是什么这个问题的答案恰恰是HCIP考试里NAT配置的重要区别——单出口NAT和带回流功能的NAT。还有一个容易被忽略的点NAT和GRE隧道同时启用时隧道流量的回程报文不能做NAT。因为GRE隧道封装后外层IP头的源地址是公网地址比如隧道源如果回程也做NAT会把外层目的地址改成私网地址隧道对端根本无法识别。所以在配置NAT时一定要通过ACL精确匹配需要转换的流量拒绝所有隧道相关流量被NAT处理。实操中怎么确认回流有没有问题在分支内网PC上ping公网地址如果通了再用display nat session all查看会话看到双向会话表正常生成就说明NAT工作正常。如果内网访问公网通但访问总部内网服务器不通别急着查GRE隧道先在R2上确认到192.168.1.0/24的路由是否指向Tunnel接口——这个问题90%出在路由上不是隧道本身。5. 综合验证与排错实录5.1 从物理链路到隧道再到NAT的分层验证综合实验最忌讳的是“哪里不通就怀疑哪里”。我惯用的验证思路是“从低到高分层排查”先看物理与链路层再看三层连通性再看隧道最后看NAT。第一步验证PPP链路状态。[R2] display interface Serial 1/0/0接口状态应该是UP、UP。如果链路层down先去查PPP认证配置如果物理down检查两端接口是否no shutdown、线路参数是否匹配。第二步验证物理链路三层连通性。[R2] ping 10.0.0.1这条命令通了说明PPP链路完全正常PAP或CHAP认证、地址协商都没问题。第三步验证GRE隧道。[R2] ping -a 172.16.1.2 172.16.1.1通了说明隧道封装和解封装逻辑正确。如果不通去查Tunnel口的源目地址、display tunnel-info all和物理链路。第四步验证跨私网通信。[R2] ping -a 192.168.2.1 192.168.1.1通了说明私网路由和GRE隧道整体联动成功。第五步验证NAT。[R2] display nat session all看到有公网地址转换会话就说明NAT生效。这个验证顺序能帮你快速定位问题层级哪一步ping不通问题就在哪一层。如果真的从第四步就失败了不要急着怀疑NAT——先回头确认GRE隧道口是否UP再确认路由表里是否有到192.168.1.0/24的明细路由。5.2 典型故障现象与排查思路速查表我把这次实验中最容易翻车的几个故障整理成了表格方便对照排查故障现象可能原因排查命令解决思路Serial接口downPPP认证未通过display ppp link检查AAA用户配置和密码Serial接口up但ping不通对端IP地址配置错误或两端网段不一致display ip interface brief核对PPP链路两端地址规划Tunnel接口协议down隧道源目地址不可达display interface Tunnel 0/0/0ping通隧道源地址再检查隧道配置Tunnel接口up但私网ping不通缺私网路由或路由指向错误display ip routing-table添加指向Tunnel接口的明细路由分支内网能上网但访问总部不通GRE隧道未承载路由display ip routing-table 192.168.1.0把总部私网路由指到Tunnel口NAT会话表无记录出接口NAT未应用或ACL不匹配display acl all检查ACL规则是否允许内网网段NAT后访问公网通但回程丢包NAT只配置了出方向未配置回程处理display nat session all华为出接口NAT自动处理回程流量检查会话双向状态5.3 三个最容易被忽略的操作细节第一个细节华为接口默认封装是PPP但你在做实验时如果曾经把接口改成过HDLC或帧中继再改回PPP后PPP认证配置会全部丢失。我踩过这个坑——把所有认证命令敲完后链路仍然down排查半天才发现接口封装被改成了HDLCPPP认证命令根本没生效。第二个细节GRE隧道地址和底层物理地址不能同网段。这是华为设备明确禁止的配置逻辑——如果隧道源地址和隧道口地址同一个网段会造成路由递归数据包要出隧道口去往隧道源地址再匹配到同一个隧道口形成环路。实验里我用的是172.16.1.0/24作为隧道地址10.0.0.0/30作为物理链路地址两者隔离就是避免这个递归问题。第三个细节ping测试一定要带源地址。很多人配置完隧道后用ping 172.16.1.1结果系统选择源地址时用了物理接口地址导致报文根本没有进隧道口。正确做法是用ping -a 隧道口地址 对端隧道口地址强制让源地址从Tunnel口发出才能验证隧道的真实连通性。5.4 这个实验后续还可以怎么扩展做完这套综合实验你已经把PPP、GRE、NAT串起来了。如果你想再往上走一步有两条扩展路径特别推荐一是把静态路由换成OSPF。在Tunnel接口之间跑OSPF看看GRE隧道承载路由协议的效果感受一下“逻辑口参与路由计算”的过程——OSPF会认为Tunnel接口是物理链路DR选举、Hello报文、LSA洪泛全部跑在GRE隧道之上比起直连路由观察起来更有意思。二是给GRE隧道加IPSec加密。这也是实际企业组网里最常见的需求GRE负责封装IPSec负责加密两个协议叠加在一起。你会在配置过程中发现GRE隧道建立之后IPSec协商的是隧道内层协议报文的加解密发生在物理接口和隧道口之间这个转发流程画出来比你背十遍协议原理都清楚。最后再分享一点实操层面的体会做这个综合实验我最大的感触是不要按“先把每个技术配完再统一验证”的思路做而是“配一层、验一层”。PPP认证配上就去验证链路链路通了再建GRE隧道隧道通了再加NAT。这样每一层都是基于一个已验证过的底座往上叠加排错范围会被压缩到最小。尤其是GRE和NAT同时存在时一旦顺序乱了故障现象会互相掩盖——你以为是NAT的问题其实路由丢了你以为是路由的问题其实隧道封装有问题。按层次一层的排查习惯比背多少命令都管用。还有一个小技巧配置前先把所有接口的IP地址和路由方向画在一张表上标注清楚哪个流量走隧道、哪个流量走NAT配置时对照着来。这个习惯帮我少走很多弯路考试时也能有效减少失误。