把机器从 VPN 迁到车间而不弄丢它

一台机器离开客户现场，抵达车间，资产身份保持不变，而网络位置彻底改变。这次搬迁需要多少规划，取决于三个条件。客户是否重复使用你在内部也在使用的地址，车间网段是否与员工网络隔离，以及旧路径能否被抑制，而不只是被更高的优先级压过。第一条弄错，你排查的就是一台本来没问题的机器。

身份不是地址

资产清单与命名应当承载资产、客户与工单。地址承载的是机器此刻接在哪里，这个事实会随搬迁而改变。把两者混为一谈，就会犯下从数字里读出含义的经典错误。

把序列号编码进最后一个八位组，看上去整齐，但对路由器什么也证明不了。前缀长度决定主机认为哪些地址是本地链路，再朗朗上口的编号也改变不了这个算术。

如果你希望地址暗示客户，那是一种约定；约定本身没问题，只要没人拿它来制定策略。在资产清单里按资产去搜，而不是按地址去搜，车间搬迁就不再是一场翻箱倒柜的搜寻。它还能扛过每个站点迟早都要经历的重新编号。

使用 10.0.0.0/8 这类宽掩码的设备，会把该范围内的每个地址都当作在链路上，于是发往相隔两个网络的客户机器的流量根本到不了路由器。机器只是一直在为一个无法应答的邻居广播。

RFC 4632 按长度来定义前缀，而不是按点分数字看上去的样子。你的方案需要为每个接入组给出明确长度：一个服务网段、一个客户上下文、一个车间工位。先把这些组命名，长度就显而易见了。

实用的规则是：设计能覆盖一个接入组的最短前缀，并在该组内处处使用它。地址文本是给人看的；掩码才是内核据以行动的东西。

客户 A 和客户 B 都可以运行 192.168.10.0/24，在他们各自的楼里，两边都是对的。这不是靠给别人的厂区重新编号来解决的问题。

把两个上下文分开，或者通过一个有文档记录的设计提供明确的别名，说明哪个地址在哪个时刻属于哪个客户。全局资产清单是区分机器身份的正确工具；它并不能证明这些地址全球唯一。别名路径需要一条书面的失效规则，否则它会活得比创建它的那个工单还久。

你必须避免的是两个上下文同时可达却没有任何标记。两个活动路径上出现两个相同地址，正是会把固件更新发给错误机器的失效模式。症状很少看起来像错误；它看起来像是别人重新配置过某台设备。先立标记，再谈可达性。

送来维修的客户设备应放进一个明确允许访问的服务网段，而不是因为工作台上正好空出一个端口，就插进员工网络。

把不熟悉的工业设备当作另一个信任域。记录哪台工程主机可以访问它、那台主机需要哪些服务、哪些凭据属于这个工单。把客户的文件和客户的工单放在一起，而不是放在谁都能读的共享盘上。

隔离还必须扛过工单中最无聊的那段中间时间：在它被更新时，在它过夜停放时，在它等着快递来接时。

通常，中心路由器通过客户的隧道到达这台机器。当机器上了工作台，车间路径就成为该前缀的归属路径；如果你只需要一项服务，也可以是更窄的目的地址。

搬迁之前写下三件事：旧路径、新路径，以及这次变更如何回滚。只存在于某人记忆里的交接不算交接。

小心度量值。更低的度量值只在选路过程真正比较的那些路由之间才有意义，而更具体的前缀或一条策略规则，完全可能在度量值被参考之前就决定了结果。

把陈旧会话纳入计划。一条经旧路径建立的连接，可能在路由改变之后仍在投递命令，而这恰恰是一个地址出现两份副本会造成真正破坏的场景。明确关闭旧路径，不要等它超时。

恢复应有的远程路由，撤销临时授权，并在你认为被选中的那个端点上确认资产。然后从客户一侧验证，而不只是从车间验证。

名称解析与资产清单在这里承担面向操作者的工作：一个稳定的名称和一条可搜索的资产记录让任务变得可预期，同时网络方案对机器今天在哪里保持诚实。

好的交接的检验标准是：一个从没见过这个工单的同事，能读你的记录并回答一个问题：如果这台机器现在应答，这个应答是从哪条路径来的？如果记录回答不了，那交接只是被记录下来了，并没有完成。