点对点 VPN 仍有中心化依赖

点对点只描述应用数据包如何传输，仅此而已。节点之间仍然需要相互发现、证明身份，有时在无法建立直连路径时还要退回中继。这是三项彼此独立的服务，而一个部署可以在数据面上是点对点的，同时在其余一切方面完全中心化。比较设计意味着比较这些工作，而不是图上的箭头。

一张没有中心转发箭头的图，可能隐藏着注册机构、发现服务和中继，而它们都是运维依赖。

直接路径，共享控制平面

两台直接交换数据包的机器，可能仍依赖一个签发其证书的共同机构，以及一个告诉各自对方在哪里的服务。这两个角色都不转发应用流量，所以拓扑图把它们略去。当该机构或服务不可用时，已有会话可以继续，而新节点无法加入。开始会话与延续会话之间的差别，是对任何设计都要提出的第一个问题。

即使单一主机会完成全部工作，也要把每项工作分开画。否则图只展示了去中心化的数据平面，却掩盖了每个新节点都需要同样两项服务这一运维现实。

发现、信任与中继是三件工作

Nebula 的设计是一个有用的例子，因为它的文档把这三者分开。主机持有标识身份的证书，灯塔回答“在哪里”的问题并协助 NAT 穿透，中继则在无法建立直连路径时转发流量。中继角色刻意不同于灯塔角色，因此灯塔可达并不保证某一对节点能够通话。其他产品把边界画在别处，所以这只是例子，不是模板。

对拟议的部署，写下无法直连的一对节点所支持的兜底路径。一次失败的打洞只是关于一个网络的单个数据点，并不能证明两个位于 NAT 之后的节点永远无法相遇；反过来说直连在任意策略下都能工作，同样没有依据。

每项依赖各自失效在哪里

在被测依赖不可用时，分别评估四种情况：现有节点流量、全新节点连接、端点发生变化的节点，以及刚刚被撤销的访问权限。它们依赖不同服务，失效方式也不同。已有会话可能挺过发现服务中断，而被撤销的密钥仍会被拒绝；新节点也可能因与转发无关的原因失败。要逐项测试，而不是从一个情况推出结论。

挺过一次中断的连接并不能证明无限独立。它只证明你制造的那次中断不是切断该路径的那一个——只要记录下你做了什么，这仍然是有用信息。

问清楚你能承受哪种中断

听起来相似的需求会导向不同的设计。避免单一转发瓶颈，不等于避免由供应商托管的控制平面，两者也都不同于在协调者停机时继续运行。先说明部署必须满足这三者中的哪一个，再检查对应关系。满足第一条却不符合第二条的设计很常见，也并不虚伪，只要没人称它完全去中心化。

记录由谁运营发现、信任和中继，以及各项如何替换。正是这份记录让下一个人能回答一个真实问题：这个网络能承受哪些故障，谁维护仍然共享的状态？

只有列出那些故障，“去中心化”这个词才名副其实。没有这份清单，它描述的是一张图，而不是一个系统。