从基于 PPP 的 VPN 迁出，而不复制它的假设

VPN 迁移的完成标志是用户、目的地、域名解析和故障行为都仍然正确，而不是新客户端亮起了绿灯。旧的 PPP 部署带着从未写下的假设：一个同时充当唯一身份校验的共享密钥、一个被防火墙列入白名单的固定地址池、一个由服务器下发的 DNS 后缀。不把这些假设清点清楚就更换协议，得到的是一个能完成握手的隧道和一条并不存在的边界。下面的顺序就是我用的顺序，最后一步正是团队最常跳过的那一步。

第 1 步：清点旧连接提供了什么

清单要写下来，而不是靠记忆。记录受支持的客户端、认证角色、地址池、受保护的网段、DNS 要求，以及每类用户所需的服务权限。

对 L2TP/IPsec，要明确区分两层。IPsec 对端身份认证的是机器；PPP 认证的是用户，通常用 CHAP 或 MSCHAPv2。

旧部署的假设恰恰藏在这条分界里。 每个客户端共用的预共享密钥认证的是一个组，而不是一台设备，而且它往往是唯一被轮换过的东西。如果 PPP 账户才是真正的按用户控制点，就要说出来，因为替代方案必须用某种不是共享字符串的东西重建这项控制。固定源地址和本地网络例外也要记下来，因为这些依赖在断掉之前没人会写文档。

第 2 步：有意识地设计替代方案

选择替代方案就是逐条需求做映射：选一个组织支持的协议和一个仍在维护的客户端，让每条身份与访问需求落到真实机制上。共享密钥并不自动等于按设备的密钥或证书，按用户的 PPP 账户也不等于设备证书。

地址范围要最先协调，因为与家庭或办公 LAN 重叠的替代地址池造成的故障，跟加密强度毫无关系。用你为旧服务建的那份清单核对地址池，再加上新客户端默认假定的内容。确认受保护网段的回程路由，并确认新客户端能下发或记录旧客户端下发的 DNS 后缀。这两件事产生的迁移工单比协议变更本身还多。

第 3 步：分阶段实施，并同时验证放行与拒绝

先用一个代表性用户和一个代表性应用做试点。测试里必须包含私有 DNS 解析，因为能到达地址却解析不了内部名称的隧道，只算迁移了一半。还要包含预期的不可用状态：隧道断开时应当发生什么，以及客户端是否强制执行。

然后测试一个本应继续被拒绝的目的地。一条宽泛的临时放行规则可能让新隧道看起来一切正常，同时悄悄拆掉了旧服务执行的授权边界，而且直到审计才有人发现。从同一客户端、在同一会话里，并列比较放行与拒绝的结果。在两列都与设计一致之前，保持旧服务继续运行。

在迁移管理员访问之前，确认你有一条不依赖正在更换的隧道的、已获授权的恢复路径。

第 4 步：让旧身份退场

正确退场旧身份，是指通过拥有它的服务吊销过期的用户与设备凭据，然后在没有遗留依赖时移除旧配置文件和监听器。删除一个本地文件并不能吊销别处的副本，而一个仍然接受旧共享密钥的旧监听器就是一扇无人看守的门。

这一点值得放慢。笔记本上一个已停用的客户端配置文件并不是已吊销的凭据；凭据活在服务器上，直到服务器不再接受它才失效。要去找旧配置的其他副本，比如测试设备、被遗忘的手机、有人留着的安装包，并把关闭监听器当作旧服务真正结束的时刻。在此之前，这次迁移有两扇前门。

验收记录就是第一步的清单再加一列：新设计对每一行做了什么，以及你如何验证。这样就把一次协议升级变成了带证据的服务需求。

把结果绑在服务需要什么上，而不是绑在协议名称上，因为把旧假设照抄进去的现代协议，只是换了更好听的说法，风险依旧。 RFC 3193 描述了 L2TP 如何承载在 IPsec 之上，这也提醒我们：这两层从来都是分开的决策。如果清单里有一行你解释不了，就停下来弄清楚它牵动着什么。当这份清单变得乏味时，迁移才算完成。