星型还是全网状：哪种 VPN 拓扑适合你的站点

两个分支机构整天互相通信，而它们之间的隧道却绕经另一个区域的数据中心。每次请求都要为这趟绕行付两次代价，直到文件同步开始感觉不对，才有人察觉。拓扑问题正是从这里开始的：不是哪种图示看起来更健壮，而是你在为哪种流量模式付费。两种设计都能用，也都以不同方式、不同代价失败。

先数清对等关系的数量

有 N 个站点时，全网状需要 N 乘 N 减一除以二条隧道；中心节点只需要 N 条。五个站点时是十对五，听起来还能应付。十五个站点时就是 105 对十五，差别已经不属于算术，而属于人手。

每一条关系都带着你必须维护的状态。在 IPsec 里意味着安全关联、身份、密钥或证书、对端失效检测，以及每个远端前缀至少一条路由。在 WireGuard 里意味着每个对端一个公钥和一个 AllowedIPs 块；单对端更便宜，但完全没有发现机制：新增站点无论如何都要改动每一个已有站点的配置。

让流量构成来决定，而不是让图纸来决定

如果分支流量主要是访问中心 ERP 或文件集群的请求，中心节点不是妥协，而是正确的形状：流量本来就想去那里，而一个策略点比一张成对规则网更容易审计。当分支之间互相交换数据时，全网状才配得上它的复杂度：两个办公室之间的复制、站点之间的语音、十多位工程师整天打开的 CAD 共享。

尴尬的情况都在中间，而它们占多数。先测量再争论，不要对着组织架构图猜。

把这张表当作决胜依据，而不是规则。四行中有三行指向同一侧，通常就能定案；出现分裂就意味着混合方案，而多数成熟网络最终跑的就是它。

必须明确告诉中心节点去转发

两条能通的站点到中心隧道，并不会自动产生站点间访问。中心节点需要开启 IP 转发、为每个分支网络配一条路由、一条允许中转的防火墙规则，并把回程路径算清楚；每个分支需要一条通往另一站点前缀的路由。在 Linux 中心节点上，这就是 net.ipv4.ip_forward=1 加上一条不会悄悄丢弃这对流量的 FORWARD 链；在基于策略的 IPsec 里，则是两端都要列出远端分支网段的流量选择器。strongSwan 的 转发说明 正好覆盖缺的正是这一层时的内核与防火墙一侧。一个便宜的测试是：从一个分支向另一个分支上的服务发流量，同时盯住中心节点的计数器；一条计数从不增长的规则说明问题出在顺序，而不是路由。

中心策略也是有用的那部分。可以允许分支访问共享服务，却不允许它们互相访问，而这份访问矩阵值得明确写下来。缺失的路由替代不了一条人能读懂的规则。

小心做了一半的版本：分支 A 经中心节点路由到分支 B，中心节点双向路由，而中心防火墙允许来自 A 的新连接，却不允许来自 B 的。第一个方向测着正常，第二个方向卡住，看起来像路由故障，其实不是。

先设计故障，再设计正常路径

单个中心节点是共享依赖，也是中转瓶颈，而冗余恰恰是中心式设计最常出错的地方。两个中心节点意味着每个分支都要持有两条隧道，而回程路径必须与去程一致；一旦不一致，有状态防火墙会丢掉回包，症状就是连接建立后随即死掉。更大的部署用隧道之上跑路由协议来取代静态前缀，机器更多，但不用再猜。无论选哪种，都要把回程路径写在去程路径旁边，因为没人测的正是回程那一半。

全网状把这种风险摊开：一个站点的链路中断不会孤立其他站点。但它也让路径选择可能出人意料的地方成倍增加，而应用会话依然无法在路径切换时自行存活。

两种设计都不能凭自己让 TCP 会话在切换中存活。如果应用无法重连，拓扑就不是你的问题。

按变更成本来选，然后验证路由

从中心节点开始，因为选错它的代价更低，再为流量足以证明其合理性的站点对增加直连隧道。那种混合不是没能做决定，而是多数组织一年之内都会收敛到的设计。关键在于每条直连都有明确的理由和负责人。

然后验证两张图，而不是一张。正常路径：从每个站点对每个服务前缀运行 traceroute，确认跳数与图纸一致。故障路径：关掉一条隧道再重复一遍，因为只在一切正常时才可用的路由不是设计出来的，只是配置出来的。

把两张图与访问矩阵放在一起保存，并在新增站点时回看它们；你管理的成本是下一次变更的成本，而不是当前这张图有多优雅。