网络实验课里最让人又爱又恨的一类配置PPPoE绝对排得上号。爱的是它把拨号上网这件事从抽象概念变成了看得见摸得着的报文交互恨的是它牵扯的东西太多——链路层封装、会话建立、地址协商、NAT转换、默认路由任何一环掉链子现象都是网不通排查起来像在黑暗里摸开关。这次期末大作业我选的就是在思科模拟器里把PPPoE从零搭起来从拓扑规划到抓包验证完整走了一遍中间踩的坑比预想的多得多。这篇就把整个搭建过程、每一步背后的原理、以及那些文档里不会写的实操细节摊开讲清楚适合正在做同类实验、或者想搞明白PPPoE到底怎么跑起来的朋友参考。哪怕你之前只配过静态路由和DHCP跟着这个思路也能把实验跑通。1. 先把实验目标和拓扑想明白再动手很多人一上来就打开模拟器拖设备连线配到一半发现地址规划乱了、接口选错了只能推倒重来。我在动手前花了大概二十分钟把这个实验到底要验证什么想清楚后面省下的返工时间远不止二十分钟。1.1 这个实验真正要验证的四件事PPPoE实验表面上是让两台PC能互相ping通但真正有价值的是它串起来的四个机制我在设计拓扑时就是围绕这四点来安排的PPPoE会话的建立过程从PADI、PADO、PADR到PADS四个阶段的报文交互这是PPPoE区别于普通以太网的核心必须能抓到包看到。PPP的链路协商LCP协商和IPCP地址分配理解为什么客户端能自动拿到一个地址而不是手工配。认证环节PAP或CHAP认证这是运营商拨号场景里绕不开的一步也是实验里最容易配错的地方。地址转换与出口PPPoE客户端拿到私网或公网地址后内网主机怎么通过NAT出去默认路由怎么指。把这四件事拆开看拓扑的结构就自然浮现了内网侧需要至少一台主机和一个网关中间是PPPoE客户端模拟家用路由器拨号对端是PPPoE服务器模拟运营商接入设备服务器后面再挂一个外网目标用于验证连通性。提示如果你的实验只要求能ping通那很容易糊弄过去但如果答辩或报告里要讲清楚报文流程拓扑里就必须留出能抓包的位置这一点提前规划好。1.2 拓扑结构与设备角色分配我最终用的拓扑是四段式从左到右依次是内网PC、内网网关同时充当PPPoE客户端、PPPoE服务器模拟运营商、外网目标主机。设备选型上模拟器里用两台路由器分别扮演客户端和服务器两台PC作为两端主机中间用串行或以太链路连接。设备角色模拟器设备类型关键接口作用内网主机PC以太网口发起内网访问验证NAT内网网关/PPPoE客户端路由器内网口 外网口拨号、NAT、默认路由PPPoE服务器路由器面向客户端的口分配地址、认证外网目标PC或路由器以太网口连通性验证终点这里有个容易被忽略的点PPPoE客户端和服务器之间的链路必须是同一广播域因为PPPoE的发现阶段靠的是以太网广播。模拟器里如果中间隔了三层设备PADI报文根本发不出去会话建立会直接卡死。我一开始图省事在中间加了一台路由器做转发结果客户端一直停在正在拨号查了半天才发现是广播域被切断了。1.3 地址规划别小看这一步地址规划我建议在纸上先写清楚尤其是PPPoE这种地址是动态分配的场景很容易和静态配置的网段打架。我的规划是这样的内网网段用192.168.10.0/24网关地址192.168.10.1配在客户端路由器的内网口上。PPPoE服务器上建一个地址池范围200.1.1.10到200.1.1.20掩码/24用于分配给拨号客户端。服务器自身面向客户端一侧可以配一个200.1.1.1作为对端标识外网目标主机配200.1.1.100。这样规划的好处是内外网段彻底分开NAT的转换关系一目了然抓包时也能一眼看出哪个地址是拨号拿到的、哪个是内网私有的。地址池留了余量而不是只给一个地址是为了后面如果想接第二台客户端做对比实验时不用改配置。2. PPPoE服务器端的配置逻辑与顺序服务器端是整个实验的地基它决定了客户端能不能拨上来。我把它放在第一步配是因为服务器配好之后客户端那边出问题时就能快速判断是客户端配置错还是服务器没响应。2.1 先建地址池还是先配虚拟模板这个问题我纠结过。正确的顺序是先建本地地址池再配虚拟模板接口因为虚拟模板里要引用地址池的名字。如果顺序反了虚拟模板引用一个不存在的池虽然模拟器不一定立刻报错但客户端拨上来时会拿不到地址现象是IPCP协商失败。配置地址池的命令很直接ip local pool PPPOE_POOL 200.1.1.10 200.1.1.20这里PPPOE_POOL是池的名字后面跟起始和结束地址。我建议池名用大写加下划线和接口名区分开后面引用时不容易看错。2.2 虚拟模板接口的关键参数虚拟模板Virtual-Template是PPPoE服务器的核心它相当于一个模板每来一个拨号客户端就克隆一份出来。配置时几个参数必须配对interface Virtual-Template1 ip unnumbered FastEthernet0/0 peer default ip address pool PPPOE_POOL ppp authentication chap逐条解释一下为什么这么配ip unnumbered让虚拟模板借用某个物理接口的IP省得单独给它配地址。这里借的是面向客户端那个口逻辑上说得通。peer default ip address pool指定对端客户端从哪个池拿地址这是IPCP阶段分配地址的依据。ppp authentication chap开启CHAP认证比PAP安全也是实验里更常考的点。注意ip unnumbered借用的接口必须是up状态否则虚拟模板起不来。我一开始借了一个还没配地址的接口结果模板一直是down客户端拨号直接超时。2.3 绑定物理接口与认证账号虚拟模板配好后还要在物理接口上把PPPoE服务挂上去并指定用哪个虚拟模板interface FastEthernet0/0 no ip address pppoe enable pppoe-client dial-pool-number 1等等这里要分清——服务器端用的是pppoe enable加协议绑定客户端才用dial-pool-number。服务器端完整的绑定是interface FastEthernet0/0 no ip address pppoe enable然后在虚拟模板上通过pppoe enable的另一种形式关联或者用protocol pppoe在虚拟模板上声明。不同模拟器版本命令略有差异我用的这个版本是在虚拟模板下加pppoe enable即可。认证账号用本地数据库username user1 password 0 pass123用户名密码要和客户端拨号时填的一致大小写敏感这点后面踩坑章节会细说。2.4 服务器端配置的验证方法配完不要急着去配客户端先在服务器上show pppoe session看一眼正常情况下此时应该是空的还没人拨号。再show ip local pool确认地址池状态正常。如果地址池显示不可用多半是池名拼错或者地址范围写反了。我习惯在服务器端配完后先自己ping一下本地接口地址确认接口是up的再往下走。这个习惯帮我挡掉过好几次接口没起来就去怪客户端的误判。3. 客户端拨号配置dialer接口是灵魂客户端这边是整个实验里配置最绕的部分因为涉及dialer接口、拨号池、绑定物理口三个层面的配合。我把它拆成建拨号池—配dialer接口—绑物理口三步来记逻辑就顺了。3.1 dialer接口与物理接口的分工很多人搞不清dialer接口和物理接口的关系。打个比方物理接口是电话线插口dialer接口是拨号软件里的那个连接配置。物理口负责把PPPoE报文发出去dialer接口负责承载PPP协商和IP地址。两者通过拨号池dialer pool关联起来。配置顺序上先建dialer接口interface Dialer1 ip address negotiated encapsulation ppp dialer pool 1 ppp authentication chap ppp chap hostname user1 ppp chap password 0 pass123 ip nat outside几个关键点ip address negotiated告诉路由器地址是协商来的不是手工配的这是PPPoE客户端的标志性配置。dialer pool 1把这个dialer接口和编号为1的拨号池绑定。ppp chap hostname和ppp chap password填的是服务器上建的那个账号必须完全一致。ip nat outside标记这是NAT的出口方向。3.2 物理接口如何挂到拨号池物理接口这边配置很简洁但每一句都不能少interface FastEthernet0/1 no ip address pppoe enable pppoe-client dial-pool-number 1pppoe enable开启PPPoE功能pppoe-client dial-pool-number 1声明这个物理口作为PPPoE客户端加入1号拨号池。这样物理口收到PPPoE报文后就知道该交给哪个dialer接口处理。提示物理口上一定不能配IP地址配了会和dialer接口的协商地址冲突现象是拨号成功但路由表里出现两条奇怪的直连路由。3.3 内网口与NAT的配合客户端路由器的内网口配置相对简单interface FastEthernet0/0 ip address 192.168.10.1 255.255.255.0 ip nat inside然后配NAT规则让内网流量从dialer接口出去时做地址转换access-list 1 permit 192.168.10.0 0.0.0.255 ip nat inside source list 1 interface Dialer1 overload这里overload就是PAT多个内网地址复用dialer接口那一个协商来的地址。用interface Dialer1而不是写死地址是因为拨号拿到的地址是动态的写死的话地址一变NAT就失效。3.4 默认路由指向dialer接口最后一步默认路由ip route 0.0.0.0 0.0.0.0 Dialer1注意这里下一跳写的是接口而不是IP因为对端地址是动态的没法写死。这条路由让所有未知流量都从dialer接口出去配合NAT完成内网到外网的访问。配到这里理论上show pppoe session应该能看到会话建立show ip interface brief里dialer接口应该拿到地址了。如果没拿到就进入下一章的排查环节。4. 拨号失败的排查链路我踩过的五个坑这一章是整篇的重点。实验过程中我前后遇到五次拨号失败每次现象都差不多网不通但根因完全不同。我把排查过程完整还原出来你遇到类似问题时可以照着这个链路走。4.1 坑一CHAP认证失败但报错很隐蔽第一次拨号show pppoe session显示会话建立了但dialer接口一直拿不到地址。看debug ppp negotiation才发现CHAP认证失败。原因是服务器上账号是user1客户端ppp chap hostname也写的user1但密码我手滑多打了一个空格。CHAP认证失败的现象特别隐蔽因为会话层是通的只是网络层协商不过去。排查时用这条命令最直接debug ppp authentication它会打印出认证的收发过程能看到CHAP: O CHALLENGE和CHAP: I FAILURE这样的字样一眼定位。注意debug命令在模拟器里输出很快建议先logging console打开或者用terminal monitor否则可能刷屏错过关键行。排查完记得undebug all不然CPU会被拖垮。4.2 坑二地址池耗尽或范围写错第二次是换了个客户端做对比实验结果新客户端拨不上来。show ip local pool一看池里只剩一个地址而前一个客户端还占着一个没释放。PPPoE的地址分配是占用式的会话不断开地址就不回收。解决办法有两个要么扩大地址池范围要么在服务器上手动清理旧会话clear pppoe session all另外地址范围写反也是常见错误ip local pool后面起始地址必须小于结束地址写反了池会建不起来但不一定报错容易漏看。4.3 坑三物理接口没开PPPoE或绑错池第三次现象是客户端连PADI都发不出去debug pppoe events里一片空白。查了半天发现物理接口上漏了pppoe enable只配了pppoe-client dial-pool-number。这两条命令是配套的少一条都不行。还有一种情况是拨号池编号对不上物理口写的是dial-pool-number 1dialer接口写的是dialer pool 2两边对不上报文发出去没人接。这种错误配置时不容易发现因为命令本身不报错只能靠show running-config逐行核对。4.4 坑四NAT方向标反导致内网出不去第四次比较冤拨号成功了dialer接口也拿到地址了客户端自己能ping通外网目标但内网PC ping不通。问题出在NAT的inside和outside标反了内网口标成了outsidedialer接口标成了inside。NAT方向判断有个简单口诀流量从内网出去的方向是inside到outside。内网口是inside出口是outside。标反了之后NAT表里根本不会生成转换条目show ip nat translations是空的。排查时先看NAT表有没有条目没有就回头查接口的inside/outside标记这是最快的定位路径。4.5 坑五默认路由缺失或指向错误第五次是内网PC能ping通网关但ping不通外网。路由表里没有默认路由或者默认路由指向了一个不存在的下一跳。PPPoE场景下默认路由必须指向dialer接口因为对端地址动态变化。用show ip route确认有没有S* 0.0.0.0/0这一条下一跳是不是Dialer1。如果没有补上ip route 0.0.0.0 0.0.0.0 Dialer1即可。把五个坑整理成排查表方便对照现象最可能原因首查命令会话建立但无地址CHAP/PAP认证失败debug ppp authentication新客户端拨不上地址池耗尽show ip local poolPADI发不出去物理口未开PPPoEshow running-config客户端通内网不通NAT方向标反show ip nat translations内网通外网不通默认路由缺失show ip route5. 抓包验证让报文流程看得见配置跑通只是及格线能把PPPoE的报文流程讲清楚才是这个实验的加分项。我在关键链路上做了抓包把发现阶段和会话阶段的报文都截了下来这部分内容写进报告里说服力很强。5.1 发现阶段的四个报文PPPoE发现阶段是典型的广播请求、单播响应模式四个报文依次是PADIPPPoE Active Discovery Initiation客户端广播发出目的MAC是全F寻找可用的PPPoE服务器。PADOPPPoE Active Discovery Offer服务器单播回应告诉客户端我在这里并带上自己的服务名。PADRPPPoE Active Discovery Request客户端从多个PADO中选一个单播请求建立会话。PADSPPPoE Active Discovery Session-confirmation服务器确认分配一个Session ID会话正式建立。抓包时在客户端物理口上抓过滤条件用pppoe或者直接看以太网类型0x8863发现阶段和0x8864会话阶段。模拟器的抓包功能可以直接按协议过滤很方便。提示PADI是广播如果拓扑里有多台PPPoE服务器客户端会收到多个PADO这时PADR发给谁取决于客户端的选择逻辑。实验里只有一台服务器所以看不到这个分支但报告里可以提一句体现理解深度。5.2 会话阶段的PPP协商会话建立后PPP的LCP和IPCP协商在0x8864类型的帧里进行。LCP负责链路参数协商比如最大接收单元、认证方式IPCP负责IP地址分配。抓包能看到LCP Configure-Request/Ack的往返以及IPCP的地址协商过程。这部分报文比较密集建议抓包后按会话过滤只看自己这条会话的流量否则容易被其他广播报文淹没。我在报告里把LCP协商和IPCP协商各截了一组配上文字说明老师反馈说这部分做得比较扎实。5.3 抓包时容易忽略的细节有两个细节值得注意一是PPPoE帧里有一个PPPoE头部包含Session ID和长度后面才是PPP帧再后面才是IP报文层层封装抓包工具展开时要注意层级二是MTU的问题PPPoE因为多了8字节头部有效MTU比以太网小实验里如果传大包可能会分片这也是实际组网中要调MTU的原因。我在抓包时特意发了一个大包ping观察到了分片现象把这个写进报告里作为PPPoE对MTU的影响的实证算是把实验做深了一层。6. 几个让实验更稳的实操习惯做完整个实验我总结了几个习惯看起来是小事但能显著减少返工和误判。6.1 配置前先存一份基线模拟器里配置容易乱我习惯在配PPPoE之前先把基础连通性配好并存档比如用模拟器的快照功能这样一旦PPPoE配崩了回滚到基线重来比逐条删命令快得多。这个习惯在反复试错阶段特别有用。6.2 用show命令代替猜遇到问题先别急着改配置先用show命令把现状摸清楚。我常用的几条show pppoe session看会话状态和Session ID。show ip interface brief看dialer接口有没有拿到地址。show ip nat translations看NAT有没有生成条目。show ip route看默认路由在不在。show running-config interface Dialer1核对dialer接口配置。这五条命令基本能覆盖80%的排查场景比盲目debug高效得多。6.3 认证密码的坑要提前防CHAP密码大小写敏感、不能有隐藏空格这是最容易翻车的地方。我的做法是配置完后用show running-config把服务器和客户端的账号密码逐字符对一遍确认完全一致再拨号。另外模拟器里有时候复制粘贴会带入不可见字符手工敲一遍反而更稳。6.4 报告里把为什么写清楚实验报告如果只贴配置和截图分数不会高。我在每个配置段后面都补了一段为什么这么配比如为什么用ip unnumbered、为什么默认路由指向接口而不是IP、为什么NAT要用overload。这些解释体现的是理解而不是照抄答辩时也经得起追问。整个实验从规划到跑通大概花了三个多小时其中一半时间花在排查那五个坑上。但正是这些坑让我真正理解了PPPoE不是配几条命令就完事而是发现、会话、认证、地址、路由、NAT六个环节环环相扣。如果让我给正在做这个实验的人一句建议那就是每配完一个环节就用show命令验证一次别等全配完再一起调这样出问题时能立刻定位到是哪一环而不是面对一堆配置无从下手。