VPN 清单：预期接入、生成的配置、实时会话
隧道名只是一次观测，不是服务记录。在停用任何东西之前，先把租户、已部署配置和计费证据对齐。
每个隧道名看起来都像一行清单，直到你追问它属于谁。名字告诉你此刻有东西连着；它说不出这项服务归谁、他们被允许访问什么，也说不出产生这条隧道的配置是不是你批准的那一份。在编队规模下，这三个问题本身就是清单，而隧道只是最新的一次观测。
一项服务，三份记录
预期服务是租户有权享有的东西：身份、前缀、资源，以及生命周期状态。已部署配置是应当实现它的那份生成策略。被观测到的会话，是某物已接入的运行时证据。把它们当成一张表，就等于把三种不同的真相压进同一行，而这一行同时错在三处。
| Record | Answers | Goes stale when |
|---|---|---|
| Intended service | Who may reach what | A contract changes and nobody edits the record |
| Deployed configuration | What the gateway was told | A device is edited by hand |
| Observed session | What is running now | Telemetry stops or a session ends |
实用的检验，是每份记录都能单独回答的那个问题。问这个前缀归谁，预期服务记录会答。问网关持有什么策略，已部署记录会答。问这周有没有人用过，会话记录会答。答不上自己那个问题的列，就是该最先修的一列。
记录租户，而不是记录接口
给每项服务一个能熬过重连的标识符。临时隧道接口或会话编号会因为与客户毫无关系的原因而变化，以其中之一为键的清单，只要链路一抖动就会多出一行。应当改为以租户和服务为键，再把观测挂到这个键上。
记录需要责任租户和操作者、被接受的对端或用户身份、指向凭据的引用而非凭据副本、受保护的前缀、路由上下文、被允许的资源，以及预期生命周期状态。凭据材料属于受支持的密钥库；一份携带私钥的清单，已经变成环境的第二份、保护更差的副本。
生成的配置有归属，也有版本
自动化让这件事更容易，也藏得更好。生成器跑成功，只证明模板渲染过，并不证明每台设备都与输出一致。总有人会在事故中手工改动某台网关，而那次改动才是最值得留存的，因为后续任何一次运行都不会再复现它。
记录哪一次修订产生了已部署策略，并把直接改动保存为需要核对调和的差异，而不是悄悄覆盖它们。调和才是这里的产品：生成器的成功与设备的实际状态是两个必须比较的事实，不能假定相等。
会话是证据，不是授权
在部署使用 RADIUS 计费的地方，RFC 2866 给出了可用的具体字段。Acct-Status-Type 区分开始与停止，属于同一会话的记录共享 Acct-Session-Id。有了这些字段，你不必信任仪表盘的汇总，就能重建会话何时开始、何时结束。
计费标识是运行时证据。它并不界定某个子网归哪个租户，也不授予任何访问权。把它与网关和服务身份关联起来，再把采集时间放在观测旁边。报告缺失可能是遥测故障，而不是没人使用；旧记录也不能证明访问此刻仍然有效。
下线用的是同一种关联
移除一项服务，意味着按同样的顺序移除预期接入、凭据和实时会话，并且都要经过各自的归属方。然后再确认过时的配置已经从设备上消失，其被允许的路径也不再解析。上个季度离开的客户，不该因为删了隧道名却没删路由，还留在前缀表里。
这一切都不要求每种功能一台设备，也不要求某个特定的自动化产品。真正的运维要求更窄、也更难：客户、其预期接入、已部署策略和当前的运行时证据，必须能在不依赖某人对隧道名的记忆的情况下关联起来。先建好这三份记录，再去挑选维护它们的工具。