常开 VPN：把路径、权限与会话分开看

让隧道昼夜不停地保持连接，是一种设计选择：它有正当的版本，也有粗心的版本。分支机构全天需要访问中心应用，夜里还要跑备份任务，这就有了理由。而一台在酒店房间里连续挂了三天没人管的笔记本，则是一场事故。

两种情况都显示同一个绿色图标，问起隧道开了多久，答案也一模一样。那个数字并不重要。真正要紧的是：这条连接让什么保持可用、对谁可用，以及究竟是什么把它结束掉。

三个各自运行的时钟

第一种状态是路径。一条隧道及其策略让一组服务变得可达，而一条没有流量的链路依然可以为下一个请求保持就绪。它能就绪多久，是实现层面的决定，而不是某个通用的计时器。

第二种状态是权限。一个被接受的标识或设备可能被授权使用这条路径。当角色变化、设备失踪或怀疑被入侵时，这项授权就应当改变；它与数据包是否在流动无关。

第三种状态是应用自身的会话。数据库客户端、远程桌面或网页应用各自独立认证，并各自维持自己的状态。关闭隧道并不必然结束其中任何一个。

把这三者当成同一个问题来审阅，最后只会争论空闲计时器。三者各自都可以是健康的，也可以是坏掉的；在一个地方发现问题，对另外两个说明不了什么。三条的检查表胜过围绕一个超时值的辩论。请把每种状态的答案分开写。

隧道是路径，不是徽章

一条已建立的隧道只能证明两端之间存在一条受保护的路径。它不能证明任一端后面的每个进程都应当访问另一端的每项服务。

NIST 的零信任指引从相反方向说了同一件事：不应把网络位置当作隐含的信任。站点链路是一个传输层面的事实，而允许某台主机使用某个应用，是一项有各自责任人的独立决定。

被攻陷的对端仍然可以借助它被允许访问的服务尝试有害操作。过滤与监控能降低特定风险，却抹不掉端点被攻陷的后果。按路径来设计，按服务来授权。

为常设站点链路给出理由

常开方案站得住脚的版本，会准确写明它的用途：哪些源、哪些目的、哪个方向，以及每一条记录由谁负责。某分支机构防火墙若允许该分支的每台主机访问每个中心子网，那它就不是为某个具名用途保留链路，而是为任何人日后想到的任何事保留链路。

如果对端无法达到所需的信任级别，就收窄边界或改变安排。指望偶尔手动断开是一种流程控制，而流程控制恰恰在事故让它变得麻烦时最不可靠。

把理由与配置放在一起。写明用途的永久例外可以被审阅和废止；没有用途的例外，默认就会永久化。

换密钥不等于吊销

按计划更换密钥维持着保护的周期：它更新密钥材料，保住机密性。但它并不撤销某个端点的授权。

如果该端点仍持有有效凭据，且存在接受它的访问策略，那么下一次协商就会恢复同一条被许可的路径。这就是为什么每小时轮换一次密钥不能回答设备丢失的问题：只要身份仍被信任，丢失的设备也会跟着轮换。先查授权，再查计划。轮换是卫生，吊销是访问决定。

吊销是另一种机制，有它自己的延迟：吊销的证书、停用的账户、变更的组、移除的网络规则。每一种都在不同的时点生效，对已经建立的会话也各有不同的表现。

结束已经在运行的东西

要问实现方式在撤销访问时对已建立的会话做了什么。它可能终止这些会话，可能等它们到期，也可能采取某种介于两者之间、有文档说明的行为。不要以为明天的准入变更会关掉今天的应用连接。

对交互式访问，应把会话限制和非活动规则交给身份与 VPN 的所有者，而不只是网络团队。对站点服务，则要规定维护、故障或安全事件用来停用访问的流程。

然后再测三种结果：被允许的工作仍然可用；无关的服务被拒绝；移除流程产出文档中写明的结果。只有当用途、授权和关停能力都被写下来并且演练过，常开设计才是可接受的；否则它只是一种活得比理由更久的便利。