为什么QuickQ的WireGuard ppp over UDP不行

本文目录导读：

1. MTU/PMTU 的连锁崩溃（最常见原因）
2. 协议层冲突：PPP 的可靠性与 UDP 的不可靠性
3. 性能与并发限制
4. QuickQ 固件的具体限制
5. 总结与解决方案

QuickQ 的 WireGuard 在 PPP over UDP 场景下表现不佳，通常并非 WireGuard 协议本身的问题，而是由 PPP over UDP （PPPoUDP） 这种封装方式的特性与 WireGuard 的隧道机制、MTU 处理、以及 QuickQ 设备固件/内核的兼容性共同导致的。

PPP 协议假设它是一个点对点链路，而 UDP 数据报是一个不可靠的、无序的数据报服务，将 PPP 封装在 UDP 中进行传输，会引入额外的复杂性和冲突。

以下是几个核心技术原因：

MTU/PMTU 的连锁崩溃（最常见原因）

这是导致隧道“能连接但无数据”或“间歇性断流”的元凶。

• 正常 WireGuard：WireGuard 隧道有一个固定的 MTU（通常为 1420 字节，受底层物理网络 MTU 1500 限制），传输数据时，WireGuard 会根据这个值对上层数据进行分片。
• 加入 PPP over UDP：你构建的链路是：用户数据 → PPP → UDP → WireGuard → （物理网络）。
• 问题：
  1. 每个数据包在传输前,需要经过两次封装（PPP 头部 + UDP 头部 + WireGuard 头部），假设物理网络 MTU 是 1500，WireGuard 自身开销约 60 字节（含 IP/UDP/WireGuard 头），留给上层的数据已不足 1440 字节。
  2. PPP + UDP 头部（PPP 有 2-8 字节，UDP 有 8 字节）会进一步占据空间，这意味着 PPP 链路的 MTU 实际上被压缩到了大约 1400-1420 字节 甚至更低。
  3. 如果上层应用（如 TCP）发送了一个 1500 字节的包，它会在 PPP 层被分片，或者触发更大的问题——路径 MTU 发现 (PMTUD) 黑洞，WireGuard 默认不处理路径 MTU 发现的 ICMP 消息，导致大包发送者永远收不到“需要分片”的信号，最终连接超时或永久卡死。
• QuickQ 设备：很多 QuickQ 设备（尤其是低端路由器或带机量小的型号）的内核 PMTU 处理较为简陋，不善于处理这种双层封装导致的 MTU 动态变化，经常直接丢弃大包。

协议层冲突：PPP 的可靠性与 UDP 的不可靠性

• PPP 的假设：PPP 协议设计之初，是为物理链路（如同步串行线）设计的，链路本身是连续的、有序的、且没有随机丢包，PPP 的 LCP（链路控制协议）会协商并维持一个简单的“序号”和“确认”机制（如 LCP Echo Request/Reply）。
• UDP 的实际情况：UDP 不保证顺序，不保证可靠性，当 PPP Echo 包通过 UDP 发送时，如果网络抖动导致丢包或乱序，PPP 层会认为链路“断开”，从而触发重置，而在公网（尤其是移动网络或跨国线路）上，UDP 丢包和乱序是常态。
• 后果：PPP over UDP 链路会频繁断开和重建，导致上层应用反复重连，体验极差，QuickQ 的固件通常没有针对这种场景进行参数调优（如延长 PPP Echo 超时时间）。

性能与并发限制

• 顺序交付依赖：PPP 是一个严格的顺序协议，而 UDP 允许乱序，WireGuard 隧道本身因为多路复用或内核调度导致包乱序（这在多核 CPU 或高并发下常见），PPP 层会误判为错误并丢弃乱序帧，导致大量重传。
• 无状态与有状态冲突：WireGuard 本身是无状态的（除了密钥），PPP 是有状态的（会话协商、认证、压缩等），QuickQ 通常有硬件 NAT 或状态检测，这种“有状态协议跑在无状态隧道里”会导致 QuickQ 的连接跟踪表很快溢出或错误匹配，因为 WireGuard 隧道内部的 PPP 会话 IP 和端口是不断变化的虚拟地址。

QuickQ 固件的具体限制

• WireGuard 实现不完整：QuickQ 使用的 WireGuard 内核模块（通常是 wireguard-go 用户态实现或较旧的内核版本）可能不支持 FwMark （防火墙标记）或碎片重组，当你尝试 PPP over UDP 时，生成的 UDP 数据包大小不稳定，如果碎片标记处理不好，WireGuard 隧道会直接丢弃这些碎片。
• 硬件 offload 干扰：QuickQ 的低端 CPU 或网卡驱动开启 RPS（接收包分流）或 GRO/LRO，可能将 PPP 的 Echo 包合并，破坏其校验逻辑。
• 无健康检查/保活优化：理想情况下，PPP over UDP 需要在应用层做保活（Keep Alive），但 QuickQ 固件通常没有针对这种奇葩场景的优化。

总结与解决方案

如果你想在 QuickQ 上实现类似功能，建议不要直接使用 PPP over UDP 封装 WireGuard，而是考虑以下替代方案：

1. 如果目的是连接旧式 PPPoE 网络：在 WireGuard 隧道内部直接跑静态路由或 GRE，而不是跑 PPP。
2. 如果必须用 PPP：降低 PPP 链路的 MTU，将 PPP 接口的 MTU 强制设为 1300 或更低（ifconfig ppp0 mtu 1300），并在物理 WireGuard 接口上也设置相同的低 MTU（wg set wg0 mtu 1360），这能避免分片和 PMTU 黑洞。
3. 优化 PPP 参议：在 QuickQ 的 PPP 连接配置中（如果有），将 lcp-echo-interval 设为较大值（如 60 秒），lcp-echo-failure 设为较大值（如 10 次），防止丢包导致的假断开。
4. 弃用 PPP over UDP：如果你只是在 WireGuard 隧道上再套一层 UDP 封装（为了穿透 NAT？），这通常没有必要，直接使用 WireGuard 的默认 UDP 端口即可，它本身就是一个封装在 UDP 中的 VPN，再叠一层 PPP over UDP 纯属画蛇添足，且破坏了 WireGuard 的简化优势。

这不是 WireGuard 的失败，而是 PPP 协议的古老假设与现代 UDP 网络的网络现实不兼容，加上 QuickQ 设备固件缺乏对这类“二次封装”的底层优化导致的。