WireGuard 5G 分支机构：让分支主动请求中心

当分支位于不断变化的蜂窝地址之后、而中心拥有稳定名称时，把分支指向中心只是这套设计里较容易的一半。此时中心从经过认证的流量中认识分支，而不是从你必须不断维护的记录里。约定很简单：永远由分支发起。

要有意识地配置，然后验证人们想当然认为能工作的那部分。两步都只需几分钟，而这类设计通常在第二步失败。

哪一侧掌握稳定的端点

分支配置写明中心的端点和公钥。中心配置写明分支的公钥及其允许的内部前缀，它完全可以不写端点，因为身份来自密钥，而不是来自最后一个报文的源地址。这种不对称正是整套机制，它把一整类发现问题从中心一侧彻底移除。

当分支发出经过认证的报文时，中心会记录它来自哪个源，并用这层映射来回复。此后蜂窝链路重新编号除下一次握手外不产生任何代价，而你不再需要的每个组件，都是切换时不会出问题的组件。这个性质值得在计划变更时测试，而不是在事故期间测试。请趁有人能同时观察两端时完成。

给分支一份能经受重新编号的配置

把端点和 keepalive 留在分支上，让中心的对方条目不含硬编码地址。keepalive 让翻译后的映射保持打开足够久，好让中心在空闲之后仍能发送未被请求的流量。

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

二十五秒是常被引用的例子，用来保持 NAT 映射存活，而不是每个对方都必须如此。请按你实际观察到的映射超时来设置，并记住只要接口处于开启状态，它就会在按流量计费的链路上产生流量。

在中心，分支对方的允许前缀必须覆盖分支将发送的一切。缺少前缀 在远端表现为路由失败，且两侧都不会产生任何告警，所以值得在第一个真实报文之前复核一遍。请在第一次连接前把中心的允许前缀与分支的接口地址逐条对照。

验证映射与切换

确认握手能够完成、中心能列出分支当前的端点、且分支的内部地址可以通过隧道到达。这条就是基线，应当在任何人触碰蜂窝链路之前记录下来。两行输出就够了。请把时间戳一并留在工单里。

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

然后测试这套设计存在的理由本身。拔掉主 WAN，确认分支通往中心的底层路由现在从蜂窝接口出去。隧道无法修复断掉的物理路径，因此仍然指向已失效上行链路的外部路由会产生握手超时，看起来与中心的问题一模一样。

如果外部路径被显式绑定或按策略路由，切换就必须把它包含在内。能读懂的设计与能扛住故障的设计之间的这道落差，通常就是唯一缺少的东西。

这套设计解决不了什么

这里没有任何东西允许从外部连入分支。如果总部有东西必须拨入蜂窝站点，那么对这个需求来说隧道方向就是错的，而动态 DNS 也只能更新一个名字。提供商的地址转换、入站策略以及客户端对端点的刷新都还在路上，而记录变了也打不开运营商级 NAT。

把分支的前缀与其他任何站点区分开，并限制它的网关会转发什么。稳定的中心端点简化了发现，但对路由设计、地址规划，以及哪些应用路由能在切换后存活这个问题，它什么也没做。

在运行手册里写四件事：谁发起、允许哪些前缀、keepalive 有多长、主链路中断时会怎样。凌晨三点真正需要的那几行，就是这些。