把 IoT 传感器放到 VPN 后面的三个地址决策

在每个 IoT 经 VPN 接入的方案里，三个地址会纠缠在一起，而它们并不是同一类决策。一个是如何让远程运维找到隧道端点，一个是如何让站点证明自己就是这个站点，还有一个是传感器的服务究竟在哪个地址上监听。按这个顺序回答，设计基本会自然成形。如果把三者当成一个问题来回答，你最后会给根本不需要公网地址的设备分配公网地址。位于出站站点隧道之后的传感器，即使没有任何指向它的入站规则，也能被授权运维访问。

先确定由谁发起

由谁拨号几乎决定了下游的一切。当站点主动连接枢纽时，站点不需要任何入站可达性，而枢纽需要一个站点能够解析的名字或地址。仅仅这一个选择，就能在争论开始之前消除大部分关于静态公网地址的讨论。

三个角色随后干净地分开，下面的表格就是决策的最短形式。

每一行的所有者都不同，这才是真正的要点。枢纽属于运行 VPN 服务的人，站点对端属于网络团队，传感器的地址属于设备的所有者。

枢纽地址是引导，不是目的地

一个能解析到受维护公网地址的名字，对枢纽来说就够了。DNS 记录可以跟随端点迁移，而不必手工修改每一个站点配置。DNS 做不到的是创造可达性或刷新缓存了旧答案的客户端，而这是两个独立的问题，各有各的解决办法。

如果你运行的是没有枢纽的站点到站点隧道，同样的逻辑以另一种形式成立：一侧需要可达的端点，或者两侧都拨向第三方。无论哪种，仍然得有人拥有那个地址以及它的续期。

站点对端是带前缀的身份

对端首先是一个身份，其次才是一个前缀。用 WireGuard 的术语，对端持有一对密钥，枢纽的 AllowedIPs 条目把该密钥绑定到站点的前缀上。用 IKEv2 的术语，证书或预共享密钥标识站点，其流量选择器说明它可以承载什么。只改其中一半就会破坏这套安排，所以地址变更绝不能被当作身份变更。

把密钥或证书的所有权留在站点一侧，而不是枢纽运营方，这样更换服务商就不会变成更换身份。

前缀是最容易被忘记规划的部分。枢纽必须把传感器子网关联到正确的对端，而运维的客户端需要一条通往它的路由；只存在于客户端上的路由会把流量送进一条默默丢弃它的隧道。把前缀写在站点记录里、紧挨着密钥指纹，这样被替换的网关就不会在无人察觉的情况下带着不同的覆盖范围上线。

传感器的地址属于应用

站点规划里的私有地址就够了，它需要的是稳定性而不是公网可达性：DHCP 保留、静态分配，或站点自己区域里的名字。如果设备无法重新编号，站点网关上的地址转换也是正当答案，前提是转换有文档记录，并且回程流量跟随它。

还有一个值得保持的习惯：不要把枢纽的公网地址粘到传感器主机的下一跳字段里。VPN 会安装自己的路径，而到公网端点的普通以太网邻接只是一种虚构，只会产出看起来很像样的配置。

回程是最容易被跳过的一半。设备必须把应答送回隧道方向，要么经过通往运维客户端的路由，要么经过当初转换请求的那同一个网关。默认网关配错的传感器会接受请求却把应答发进虚空，而转发说明解释了为什么到达和应答路由是两项要求而不是一项。

先决策，再写下边界

在任何人连接之前，先把访问边界写下来。把网关限制在 IoT 网段和运维实际需要的具体服务上，因为一条能用的路由很容易在无意中变成通用访问。把只读监控和配置权限保持为两个角色、两套身份，并指定合同结束时负责收回访问的人。

审批归网络所有者，身在 DMZ 并不构成访问策略。

部署后的测试枯燥但结论明确：允许前缀内的一条请求成功，网关上计数器增加，前缀外的一次蓄意尝试失败。