合并还是分离 VPN 网关：按故障域选择

两台设备看起来比一台更可靠，直到你注意到它们共用同一条电源插排、同一个虚拟机管理程序和同一条上游链路。数盒子回答的是没人问过的问题；真正有用的问题是哪些部件会同时失效。先写下故障契约，再让它来选择拓扑。下面的运行手册产生的就是这份记录。

一次重启会停掉什么

对于合并式网关，列出在重启、更新失败或硬件故障期间消失的东西。如果互联网访问和私有连接同时中断，这种共担的中断现在就是你可用性要求的一部分，不管有没有人把它写下来。同样的练习也适用于一台承担多个角色的设备：它拖垮的服务清单才是真正的规格。

对于分离式网关，列出仍然共享的部分：电力、虚拟化宿主机、上游链路、身份提供方、管理网络。一台故障交换机后面的两台设备是一个带两个主机名的故障域。忽视这些依赖的分离只是图，不是设计。

还要把维护归属算进去。另一台设备会带来配置、监控、备份和第二套恢复流程，而这些都不是免费的。

跟踪一个数据包从客户端到私有资源再返回，标出每个策略生效的位置。第二台路由器会增加一个点，在那里路由优先级、转换或连接状态可能与第一台不一致。双网关设计中最难解释的故障大多就活在这道接缝上。

ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443

写下 VPN 保护在哪里结束、内部策略从哪里开始。如果两台设备之间的路径是放行的，第二台盒子并没有造出边界；它只是挪走了边界可能所在的位置。在单一平台上，不同的策略分区仍然可能有效，其有效性应当从规则来评估，而不是因为硬件共享就否定。

如果说不清哪台设备在执行关键规则，就停下来。这个空白就是发现，不是以后再定的细节。

只有当穿过它的路径被限制在另一侧真正需要的东西上时，分离的设备才真正隔离了入侵。如果两台设备互相接受任意流量，落到其中一台的攻击者拥有的范围与之前相同。隔离的主张属于规则集，不属于资产清单。读规则，说清允许哪些流，再判断这次拆分买到了什么。

同样的逻辑适用于用户。因为来自某个网络就信任一个 VPN 用户，是在信任位置而不是身份，NIST 的零信任指南描述了替代方案：对每个请求都针对资源做认证和授权。无论哪台机箱终止隧道，这条原则都成立。

如果拆分是为了满足合规线而不是改变流量，就在记录里说明。没人能解释的控制，是压力之下第一个被拿掉的。

问一问任一侧角色死亡时，哪条恢复路径还能存活。当到达坏掉的 VPN 网关的唯一路径要经过该网关时，别处的备用设备帮不了那个必须修它的管理员。带外路径、控制台和成文的回滚，才是让设计可恢复的部分。

systemctl status strongswan
nft list ruleset
ip -brief address

按完整受支持的工作负载来确定设计规模，而不是按孤立的加密数字，因为过滤和检测消耗的是同一块硬件。用厂商文档和你自己的测量，而不是假设分离更快或更慢。然后写下决策记录：允许哪些流、哪些依赖是共享的、维护窗口会停掉什么、你有何容量证据、每个恢复步骤归谁。这份记录短到可以评审，也具体到可以回看。

当故障契约写下、转发路径对每条规则有一个具名的执行点、隔离以流而不是以设备数量来描述、恢复能从故障组件之外进行时，运行手册就结束了。选择满足这些要求的更简单方案。