1. PPP协议为什么到现在还没被淘汰1.1 “点对点”这个特性到底意味着什么在接手网络运维之前我对PPP协议的理解一直停留在教科书里那几行字Point-to-Point Protocol点对点协议。直到在HoRain云这边做专线接入梳理时我才发现自己对它的误解有多深——它远不是“拨号上网时代的遗物”那么简单而是一套应用范围极广、设计得相当精巧的二层链路控制协议至今还在你的家庭宽带、企业专线和我日常调试的路由器上默默工作。先说清楚“点对点”的含义。以太网解决的是“一堆设备怎么共享一条链路各说各话还能不冲突”的问题它靠MAC地址、交换机转发表、ARP广播这些机制来搞定。而PPP面对的场景更原始链路两端只有两个设备一根线就只连接你我不需要MAC寻址不需要广播争执只需要保证“两端的配置达成一致数据能往上跑就能用”。这种单线场景在今天的网络里依然很常见家庭宽带的光猫到运营商BRAS之间的PPPoE链路、企业租用的数字专线两端、两台路由器直接通过串口或光纤对接——这些都是典型的点对点拓扑。这个特性决定了PPP的设计重心和以太网完全不同。以太网的重点是“寻址和防冲突”PPP的重点是“链路建立、身份确认、参数协商、状态监测”。它更像两个人在正式对话之前先握手寒暄先确认你听到我吗、我们用多大声音说、你是什么身份、说完正事怎么结束。后面拆解协议流程时你会发现PPP的每一个设计决策都指向这些问题。1.2 今天的网络里PPP藏在哪些地方很多人觉得PPP已经过时是因为他们在大学课本之外再没见过它。但实际上你家里的宽带上网只要是用PPPoE拨号的就离不开PPP。运营商在光猫背后搭建的那条逻辑链路从你的路由器WAN口到局端BRAS设备协商用户名密码、分配IP地址、保持链路在线状态全部走的是PPP这套流程。企业侧更常见的是专线场景。企业向运营商租用一条从A点到B点的物理链路两端设备通过PPP对接再通过IPCP协商一个固定IP地址或者通过认证后获取地址。这种场景下PPP承担了“把一条物理线路变成一条可以跑IP且身份可信的逻辑链路”的职责。在云网络和混合云的规划里这类专线接入往往还是要面对PPP链路层的各种问题。嵌入式设备和移动通信里PPP也有它的影子某些物联网模块、工业数传设备仍然使用PPP作为承载通道。一句话总结任何需要“点对点、拨号连接、身份认证”的场景PPP依然是最成熟的方案之一。这也是为什么我认为网络工程师有必要把PPP从原理到实战彻底吃透而不是学完应付考试就扔到一边。1.3 我学习PPP时的三个认知误区第一个误区认为PPP就是“传输数据的”。其实PPP是控制链路状态的真正承载IP数据的字段在PPP帧的信息域里而协议栈的工作大头在建立和维护链路这件事上。第二个误区认为PPP自带加密。PPP的认证机制PAP/CHAP解决的是身份验证问题不是传输加密问题。CHAP虽然不在线路上传明文密码但它防的是重放和窃听数据本身仍然是明文传输。这一点在选型时必须想清楚。第三个误区认为PPPoE就是PPP。PPPoE是“PPP over Ethernet”的封装方式它要先解决一个“会话建立”的问题才能承载PPP报文两个阶段完全不同。这个我在后面的章节单独展开。把这些误区掰正之后再去看RFC 1661、RFC 2516这些文档你会发现整个人都通透了。2. PPP链路建立的完整谈判过程2.1 LCP阶段双方先约定“怎么讲话”PPP链路建立的第一步不是配置IP不是认证身份而是让两端的链路控制协议LCPLink Control Protocol先达成共识。LCP做的事情相当接地气先发几个配置请求报文把两边能够接受的参数互相报一遍能同意就同意不能同意就协商替代值。LCP协商的常见参数我再举几个在实战中会碰到的MRU最大接收单元默认1500字节。如果其中一端能力不足比如某个老设备只能收1492字节它会在Configure-Request里明确写出来另一端就会按这个值发送数据。魔术字Magic Number用来检测环路。如果链路出现了回环两端的魔术字冲突设备就能通过收到跟自己相等的魔术字来判断物理环路异常。认证协议选项协商接下来用PAP还是CHAP或者干脆不认证。压缩选项比如PFC/ACFC协议字段压缩、地址控制字段压缩在低速链路上能省下几个字节的开销。LCP的协商过程本质上是三次握手的状态机Configure-Request、Configure-Ack接受、Configure-Nak或Reject拒绝。请求方发出配置报文对端如果完全接受就回Ack链路进入下一阶段如果只是想改个别参数就回Nak双方重新协商改过的项如果认为某个选项根本不支持就回Reject请求方就必须删掉这个选项重新发请求。我在实际调试时经常靠“看到Configure-Request被Nak还是Reject”来快速判断问题Nak说明双方在同一个维度上对话只是数值不一致调一下就行Reject说明有一个设备对某个选项根本不认识这时候要考虑协议不兼容而不是简单调数值。2.2 认证阶段链路已经通了但你现在还不能用LCP状态的链路只是物理和配置层面的通路真正决定这个链路能不能传数据的是认证阶段。PPP链路建立流程中认证发生在LCP协商完成后、NCP阶段开始前这个顺序很重要必须先确认你是谁再给你分配网络资源。认证阶段可选也就是说在私网内部两台上行设备直接对接的场景如果信任度高可以完全不认证LCP协商完成后直接进入NCP。但任何面向公网或跨运营商边界的场景都建议开认证——否则这个链路上任何人都可以接入你的网络后面的一切安全措施都无从谈起。PPP认证有两种常见机制PAP和CHAP。PAP极其简单粗暴客户端把用户名和密码以明文形式发给服务器端服务器端回答通过或拒绝。整个过程只发生两次报文交换所以叫两次握手。CHAP则复杂一些服务器端先向客户端发送一个随机挑战值客户端用这个挑战值加上自己的密码做散列计算把结果返回服务器端用同样的方法计算比对。这个过程是三次握手不会在线路上传输明文密码。两种机制的细节我在下一章单独展开。从实操者的角度看认证阶段最常见的故障就是“服务器端配置了require-chap客户端却以为自己在跑PAP”两边对不上链路反复断开又重建。这个问题在后面的故障复盘里你会看到完整案例。2.3 NCP阶段给链路配上IP认证通过之后PPP链路开始进入网络控制协议NCPNetwork Control Protocol阶段。NCP不是一个协议而是一族协议负责为不同的网络层协议建立和配置各自的参数。最常用的是IPCPInternet Protocol Control Protocol。IPCP协商的内容主要是两端要跑在哪个IP网段、谁拿什么地址。在宽带拨号场景下通常是客户端请求动态地址服务器端分配一个公网或私网IP。在专线场景下两端通常配置静态IP地址IPCP阶段只是互相确认一下地址配置。IPCP的协商流程和LCP非常像也是配置请求、确认、否定的三件套。很多人在排查“为什么PPP链路看起来通了但业务上不去”时会在NCP阶段找到答案要么是IP地址配置段冲突要么是服务器端没有为这个用户配置地址池。一个小细节IPCP还会协商DNS服务器地址某些拨号用户抱怨“拨上去了但打不开网页”往往是IPCP阶段没有拿到DNS或者DNS下发错误。2.4 链路关闭与保活机制PPP链路并不是建立之后就一直傻乎乎地保持它有一套状态监测和拆除机制。LCP支持Echo-Request和Echo-Reply报文用于检测链路是否仍然存活。一端周期性地发送回显请求另一端回复回显响应如果连续多次收不到响应本地就会认为链路已经失效主动发起拆除流程。这里有个很容易被忽视的生产事故点LCP Echo的超时时间、重试次数、对端响应延迟在不同设备厂商和不同配置下差异很大。如果链路中间某个设备出现短暂拥塞回显报文只是延迟了而不是丢了某些实现就会直接判定链路down触发重新拨号。这种“明明链路没问题却反复重连”的故障我排查过不止一次。后面第6章会有一个完整的复盘。链路拆除阶段同样走LCP的Terminate Request和Terminate Ack报文。这个过程看起来简单但在生产环境的调试里区分“哪一端先发起的拆除”是定位故障方向的关键线索。3. PAP和CHAP在实际项目里的安全边界3.1 PAP为什么是“不可靠但简单”PAP的流程一句话就能说完客户端向服务器端发送包含用户名和密码的Authenticate-Request报文服务器端验证后返回Authenticate-Ack或Authenticate-NAK。用户名和密码以明文方式出现在PPP帧里任何在链路上抓到包的人都能直接看到密码内容。那它为什么还能在现实中存活因为简单、兼容性极好、实现极少出错。在可信程度较高的内部链路、或者链路本身已经通过其他加密机制保护的场景里很多人宁愿牺牲这套明文的优雅换取对接时的低成本和低故障率。在实验室做链路联调时我经常先临时用PAP验证两端路由可达性和业务路径确认没有问题后再切换到CHAP或更严格的认证方式。另一个关键点PAP的认证方向也可以配置成单向或双向。客户端认证自己是一个方向服务器端也需要向客户端证明自己的身份是另一个方向。这个细节在专线对接时一定要先确定好否则会出现“客户端认证通过了服务器端却被客户端拒绝认证”的奇葩现象。3.2 CHAP挑战应答机制的细节CHAP的安全性核心在于“绝不传输密码本身”。我用自己的理解翻译一下整个流程服务器端生成一个随机挑战值Challenge连同本次会话的ID一起发给客户端。客户端用MD5将“会话ID 密码 挑战值”拼接计算出一个摘要用Challenge-Response报文返回。服务器端从自己的身份数据库里取出同一个用户的密码按照同样的算法重新计算一遍把计算结果和客户端返回的摘要比对。一致则返回Authenticate-Ack不一致则返回NAK并断开链路。这个机制防了什么首先防了监听。对于同一个挑战值攻击者即使抓到响应报文也无法反推密码。其次防了重放攻击。每次挑战值都不一样上一次的合法响应报文拿到下一次也用不了。第三因为不传输密码密码本身也不会在抓包中被直接暴露。CHAP还有一个细节值得注意它支持周期性重新挑战。也就是说认证成功后服务器端可以随时发起新的挑战来重新确认客户端身份。这对于“一整个月都不关机的拨号链路”来说很有价值可以防止线路被窃听后伪造身份长期存活。不过在实际部署CHAP时也有坑。不同设备对密码存储方式要求不一样有些设备要求配置明文密码有些设备允许配置的是密码的散列值。如果对端算法和本地计算方式存在偏差就会出现“两边密码文本明明一模一样CHAP校验却一直失败”的诡异问题。这种问题不看协议文档只看表面配置查几天都查不出来。3.3 按场景选认证方式的经验准则拿我在HoRain云这边规划网络项目时的经验来说选认证方式我一般按下面这些问题来权衡这条链路的物理介质是否可信如果是运营商专线经过中间节点有限风险相对可控如果是跨公网拨号必须重点考虑密码保护。对端设备的兼容范围是什么老旧的工业设备对CHAP的支持可能不完整甚至有的只支持PAP那就别硬上CHAP。链路本身有没有叠加其他加密如果已经用了加密通道内层再用CHAP意义不大反而增加调试负担PAP可能就够用了。是否需要双向认证有些场景只要求客户端向服务器端自证身份有些场景两端都是核心节点互不信任双向CHAP就很有必要。实践中我给出的建议是能上CHAP就上CHAP成本几乎为零确实遇到老设备兼容问题用PAP顶一段时间可以做但一定要加访问控制列表只允许特定源IP建链并且把日志拉起来。安全边界要讲清楚PPP认证不是传输加密就算CHAP也不能保护后续的IP数据。如果数据本身敏感你仍然需要在网络层或更高层做加密这个认知一定要刻在脑子里。4. PPPoE的发现阶段与会话阶段全拆解4.1 为什么PPP不能直接跑在以太网上直接回答这个问题以太网是一个多路访问网络链路上可以挂很多设备而PPP设计时假设的是两个端点一对一。如果把PPP帧直接塞进以太网帧里发出去接收方怎么知道这些PPP帧是发给谁的谁来界定哪些以太网帧属于这条PPP链路多路并发时会话之间怎么隔离所以就有了PPPoE这套封装和会话机制。它本质上是在以太网之上建立一条虚拟的点对点通道通道两端通过一个会话ID来标识。有了这个会话ID之后多台客户端可以同时从一个汇聚设备拨号而每条PPP链路互不干扰。家庭宽带场景下一个局端BRAS设备可以同时服务成千上万个用户全靠会话ID区分。这也是为什么PPPoE既保留了PPP的成熟协议栈——认证、IPCP分配地址、LCP保活——又能适配以太网的物理承载。4.2 PADI到PADS的四个包发现阶段拆解PPPoE数据包分为发现阶段Discovery Stage和会话阶段Session Stage。发现阶段最终目的是拿到一个会话ID。PADIPPPoE Active Discovery Initiation客户端广播发出去目的MAC是广播地址目的是告诉局域网里的PPPoE服务器“我想PPPoE拨号上网谁能接我”。PADOPPPoE Active Discovery Offer能提供服务的服务器单播回应告诉客户端“我能为你服务”同时带上服务器的名称和服务类型。PADRPPPoE Active Discovery Request客户端从收到的多个PADO中选一个单播发送给选中的服务器表示“就你了给我建立会话”。PADSPPPoE Active Discovery Session-confirmation服务器单播回应附带一个会话ID从这一刻起两边进入会话阶段。这四个包的名字确实很像绕口令但记住一条主线就行广播找、单播答、点名选、发令牌。发现阶段跑完之后后面的所有PPP报文都封装在以太网帧里携带同一个会话ID一直到PPP链路被拆除或者会话超时为止。排查PPPoE拨不上号时我在Wireshark里经常直接看有没有PADI、有没有对应的PADO。如果抓到了PADI但一直没有PADO说明服务器端根本没响应问题可能出在汇聚侧的限流量策略或者协议没启用如果PADR发出去了但没有PADS大概率是BAS侧会话资源耗尽或策略拒绝。4.3 会话阶段的封装与MTU陷阱会话阶段的每一个报文都在以太网帧里多套了一层以太网头目的MAC、源MAC、EtherType 0x8864 PPPoE头会话ID、长度 PPP协议字段 PPP载荷。这一层封装直接导致了一个知名问题MTU变小。原来的以太网MTU是1500字节PPPoE封装要多占8个字节PPPoE头6字节加PPP协议字段2字节所以承载IP数据包的最大长度就被压缩到了1492字节。这就是为什么你在宽带拨号环境下如果把路由器的MTU设成默认的1500大包会直接碎成一片或者被丢弃网页打开慢、某些大包应用根本不通。正确操作是把拨号接口的MTU设为1492同时让内网机器的MTU保持1500再由路由器在拨号接口做分片处理。还有一个常见陷阱PMTU黑洞。如果你在内网有一台服务器把MTU配置成了1500以上比如9000巨型帧对外通信时它发出的包超过了拨号链路能承载的1492中间又没有正确的分片反馈机制链路就可能出现“小包通、大包不通”的诡异故障。遇到这种症状时第一反应不是查路由表而是用ping带DF标志测不同包大小定位MTU断点。5. 在Linux上把PPPoE跑起来配置命令与踩坑记录5.1 用pppoeconf快速拉通一个客户端Linux在PPPoE客户端场景中最常用的工具是rp-pppoe体系下的pppoeconf和pppd。Debian系系统安装pppoe包后直接运行pppoeconf它会交互式地探测以太网接口让你输入宽带账号密码自动生成pppd配置文件然后拨号。我在调实验室环境时通常按这个顺序操作apt install pppoeconf pppoeconf eth0工具会自动在/etc/ppp/peers/下生成一个dsl-provider配置文件然后把账号密码写进/etc/ppp/chap-secrets如果选了CHAP认证或/etc/ppp/pap-secrets如果选了PAP认证。之后拨号命令就一句话pon dsl-provider用plog查看拨号日志用ifconfig ppp0确认接口IP。绝大多数情况下这一步做完宽带就通了。5.2 手动配置pppd的关键参数与思路pppoeconf能覆盖大多数场景但如果你要调试、要调整认证方式或MTU直接手写pppd配置会更有掌控力。下面这个配置是我的常用模板# /etc/ppp/peers/broadband plugin pppoe.so eth0 # 物理网卡 user 宽带账号 mtu 1492 mru 1492 persist # 拨号断了自动重拨 maxfail 0 # 永不放弃尝试 holdoff 5 # 重拨间隔5秒 debug # 输出调试日志 logfile /var/log/pppd.log几个关键点解释一下persist配合maxfail 0是家庭场景的保命组合。没有这两行链路一旦抖动掉线pppd会直接退出进程你回家发现网络断了根本不会自动恢复。mtu 1492和mru 1492必须一致这是PPPoE环境的硬性要求忘了设就等于给自己埋雷。debug在排查时打开日常运维建议关闭因为日志量非常大会把磁盘写满。user、密码存放在/etc/ppp/chap-secrets或pap-secrets里不要写进配置文件本身避免权限问题时密码泄露。手动配置时最常出的问题在于pppd默认行为是“本地要求对方认证自己”也就是既当客户端又当服务器端。每当拨号时你要明确告诉pppd你是纯客户端在peer配置里用noauth声明“我不需要对方认证我”同时用user和密码文件完成对方对我的认证。如果没有noauthpppd会等一个永远不会来的认证请求链路卡在等待状态日志里全是timeout。5.3 服务端侧怎么搭一个能用的骨架作为对照我给一个极简的PPPoE服务端搭建思路。Linux上最常被我使用的是accel-ppp或者pppoe-serverrp-pppoe自带。以pppoe-server为例pppoe-server -I eth0 -L 192.168.100.1 -R 192.168.100.10 -N 10这条命令在eth0接口上启动PPPoE服务服务器端IP是192.168.100.1为每个拨号客户端分配的起始IP是192.168.100.10最多支持10个会话。账号密码同样管理在/etc/ppp/chap-secrets里。如果你需要的规模更大、要对接Radius做计费和认证accel-ppp是更合适的工具它专门为运营商级别的高并发PPPoE接入设计。不过对于学习原理和实验室验证pppoe-server已经足够跑通全流程。5.4 我记录在案的高频问题这三个问题是我在实际调试中反复遇到的全部有迹可循认证成功但拿不到IPIPCP协商失败。检查服务器端的地址池配置确保剩余地址数量足够同时确认用户没有绑定固定IP导致的冲突。拨号成功但上不了网路由表问题。pppd会在创建ppp0接口时自动生成一条默认路由但如果系统里还有其他默认路由就会出现路由覆盖冲突查路由优先级、查metric设置。链路反复重置LCP Echo超时被强制断开。把日志里的“Echo-Request”和“Link terminated”两个特征串起来看基本就能锁定是保活机制引发的伪故障。6. 一次生产链路故障现场从抓包到定位的完整复盘6.1 故障现象链路反复断连有一次在给云网专线侧做链路巡检时现场反馈一条通过PPP对接的专线每隔十几分钟就断开一次断开后几秒内又自动恢复。业务表现是远程连接频繁中断监控图上像锯齿一样。现场工程师的第一反应是查物理线路光衰正常、接口没有CRC错误物理层完全健康。这种“物理链路没事但PPP层反复重置”的现象非常典型。如果只是在业务层看到断连就怀疑硬件会浪费大量时间。正确的路径是直接进日志层看。6.2 从LCP Echo到认证阶段的不正常痕迹我在peer配置里打开了pppd的debug和logfile然后抓了一段时间的日志和抓包同时进行。日志里的模式非常有规律链路建立成功进入认证阶段认证成功IPCP分配地址业务跑了大概10分钟紧接着是LCP Echo-Request发出去后没有收到Echo-Reply的记录然后连续几次超时后pppd主动发出Terminate Request链路断开随即persist触发重拨。从日志看像是LCP保活超时但为什么Echo-Reply会丢失这个时候再配合抓包分析就清楚了。Wireshark的过滤表达式pppoe || ppp抓包结果显示了两个叠加因素第一链路繁忙时对端的Echo-Reply会被排在大量数据报文之后响应延迟不稳定第二我在客户端配置的LCP Echo重试次数太少只需要连续几次延迟超标就被判定为链路死亡。也就是说链路根本没真正断开只是我们的存活检测机制太敏感。6.3 根因与修复参数校准和MTU叠加问题进一步观察还发现链路繁忙时有大块数据包丢失原因是专线中间经过了某个MTU限制更小的网段而我们的路径PMTU探测被安全策略禁止导致超过限制的大包直接被丢弃。小包尤其LCP Echo这种只有几十字节的报文大部分能过去但一旦碰上网拥塞和队列丢弃就会被重新排队甚至丢掉。最终修复做了三件事调整LCP Echo的发送间隔从默认的每秒一次改为每3秒一次并把重试次数从3次提升到6次容忍度显著提高。整个PPP链路和中间网段的MTU统一收敛到安全值拨号接口设置MTU后同步调整内网接口的转发策略从根上消除大包丢弃风险。在监控侧增加了针对PPP连接的专用探测脚本不再只依赖设备自带的Echo机制而是每60秒主动做一次业务级连通性测试防止故障被保活机制的宽容掩盖。修复后链路连续运行了两周没有再出现一次意外的断连。这个案例给我的最大启示是PPP链路看似简单但“链路层不通”和“链路层活着但业务层受损”是两种完全不同的问题排查时必须分清楚是在哪一个环节断的。6.4 从这次故障里我带走的东西Paas排查PPP链路故障我有一个固定的递进思路按照这个思路走基本不会漏掉环节第一层看物理层接口状态、光功率、误码率。物理层有明显问题就先解决物理层不要在协议层浪费精力。第二层看LCP能不能建立链路、Echo是否正常、协商参数是否符合预期。如果LCP都建立不了检查配置请求被Nak还是被Reject。第三层看认证PAP/CHAP的报文是否正常交换认证是单向还是双向两边算法是不是一致。第四层看NCPIPCP是否拿到IP和DNS地址池是否充足路由是否被正确写入系统。第五层才是业务测试大包小包分别测MTU和PMTU的问题在这一层暴露。按照这个顺序排查绝大多数PPP故障能在30分钟内在日志和抓包数据里找到明确指向。链路抖动不一定就是线路问题多数时候是协议层的某个参数设置过于苛刻导致的连锁反应。最后再分享一个我长期用的习惯任何PPP链路在交付业务前我都会强制压测一次“长时间业务流量LCP Echo抖动”的叠加场景。具体做法很简单在一个终端上持续ping大数据包在两端的PPP链路上人为制造一次短暂的拥塞或者策略抖动观察保活机制会不会误判。做过这个测试之后线上出幺蛾子的概率会大幅下降。协议这个东西理解了它抗干扰的边界才能真正把它工程化地用稳。