托管 VPN 的公网出口究竟从哪里出去

在方案说明这批流量从服务商网络的哪一点离开之前，你无法判断到底是谁在过滤某个分支的公网流量。打包进托管 VPN 的互联网接入是第二项服务，它走的是一条拥有自己的网关、自己的地址转换和自己的升级队列的路径。多数合同详细描述私网一侧，却用一句话打发公网一侧。下面这些核对会把那一句话变成一份你能守住的图纸。

每个站点追踪一个公网目的地

选一台分支主机，追踪一个公网目的地，记下最后一个属于服务商的地址和第一个属于互联网的地址。这两个地址之间的那一跳就是出口，而它常常离发包的站点很远。标出执行转换的那台设备，因为决定什么能出去的过滤器就在它身上。再从第二个站点重复一次追踪并比较出口地址，因为账单上看起来相同的两个分支，可能经由不同城市的不同网关出去。

同时记下目的地实际看到的源地址，因为转换可能发生在你从未画过的那一跳上。把实测到的答案写在图纸答案旁边，两者之间的差距就是第一次事故的来源。拿不出某个站点出口地址的服务商工程师，其实已经告诉了你一件关于设计的有用的事。

三种出口安排，各自把什么集中起来

你自建的集中出口把公网流量拉到你自己的网关上，这让你拿到过滤策略和日志，却把每个站点的负载压到一条线路上。服务商运营的出口把策略和日志挪到合同边界之外，运维因此简化，同时也把可见性一并拿走。每个站点各自出口让公网流量留在本地，却让必须保持一致的策略面成倍增加。

在把清单当成菜单之前，先问服务商真正提供的是三种里的哪一种，再问一个站点能否在不新增线路的情况下在它们之间切换。迁移的答案把合同层面的事和纯技术层面的事分开。还要记下源地址转换归谁所有，因为这决定了合作方该把什么加进白名单。共享网关也意味着共享容量，有时还意味着共享声誉，这会改变合作方对待你这些地址的方式。容量同样值得单独一问，因为共享网关在同一时刻还在服务别的客户。

过滤、转换和加密各有各的归属

路由只建立可达性，对检查一字不提，所以请把两者当成归属不同的两个问题。对每一条被通告的默认路由，点出负责过滤的设备、负责认证的设备、负责转换的设备和负责检查的设备，再说出每一台归谁管。服务商的路由隔离并不说明加密在哪里终止，私网服务可以在一个边界结束隧道，而公网出口在另一个边界结束。要问转换发生在服务商边缘、共享网关还是你自己的出口，还要问有没有会话日志、保存多久。数一数答案里有几个归属方，因为把四项工作都指给同一方的合同，通常有三项是没写文档的。

一条宽泛的默认路由 被引入私网路由上下文 也值得同样审视，因为引入是刻意的约定，而不是无害的方便。 RFC 4364 第 11 节 梳理了 BGP/MPLS VPN 的几种互联网接入安排，并把 VPN 上下文与服务商默认转发上下文之间的路由交换，正视为这类约定。要问是什么阻止公网流量误走私网路径，并且把答案要到位，放在路由策略旁边，而不是放在幻灯片里。

签约前必须谈妥的两种故障情形

把两项测试写进合同：失去互联网出口，以及失去一条私网连接。对每一项，列出必须继续工作的内部资源、本地互联网服务和管理路径。然后列出必须保持阻断的备用路径，因为绕过集中管控的路径比干净的停摆更糟。把两项测试都交给服务商，并要求书面给出预期结果，包括检测和通知。

从一个试点站点跑同样的探测，再和那份书面答复对比。两者不一致的地方，说明合同描述的是另一张网，而不是你买的那张。两条命令覆盖常见情况：一条显示公网目的地走过的路径，另一条显示它看到的地址。

traceroute -n 203.0.113.10
curl -s https://example.net/ip

把可用性承诺挂在你实测的那一段上，而不是挂在服务名称上。本地线路、服务商骨干和共享网关各自承担不同的义务，也有各自不同的升级团队。L2VPN、L3VPN 和 MPLS 这几个字母描述的是转发机制，不是端到端的保证。

证据胜过方案里的形容词

冗余、安全、有韧性这类词描述的是意图，不是设计。你该要的是设备清单、出口位置、转换方案和通知路径。能拿出这四样的服务商才有设计；拿不出的只有幻灯片。把答案留在服务文档里而不是邮件串里，并在每次合同变更时重新过一遍。

随着服务商合并网关，出口安排会悄悄移动，所以三年前的图纸是负担。当合作方报告一个陌生的源地址时，你应该能在几分钟内说出它来自你的设计，还是来自一次没人通告的变更。活过第一次故障的，正是这种能力，而不是那些形容词。