IP 白名单与已批准笔记本：两种不同的控制

“只允许已批准的笔记本连接”这类规则请求，最后常常变成一条针对办公室公网地址的防火墙条目。这条规则现在放行了该地址后面的所有设备。需求和实现并不是一回事。请把策略想要的东西与地址能够证明的东西分开。

一个策略请求里的三个问题

把请求拆成三部分：连接来自哪里、它可以到达哪个服务、哪台电脑出示凭据。源地址规则回答第一个问题，目标服务规则回答第二个。两者都无法识别物理机器，因为它们都作用于许多设备共享的网络字段。第三个问题需要一张签发给该设备、且不能被悄悄复用的凭据。

把三个答案分别写下来。一条防火墙规则无法满足一个点名三件事的需求。

源地址能告诉你什么

地址转换是源地址规则过度放行的常见原因。同一个办公室出口后面的所有设备都呈现为同一个公网地址，于是这条规则放行了整个群体。VPN 内部的固定地址在另一处有同样的弱点：它是绑定在会话上的分配，而不是硬件的属性。任何持有被接受凭据的设备都可以打开那个会话。把地址当作网络限制，并按这个定位来描述它。

这仍然有助于限制暴露面，但它不是设备认证。

把访问绑定到已注册的凭据

如果需求是限制设备，就使用 VPN 支持的按设备注册，并给每台电脑一个独立身份。

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

存储列表会显示证书以及是否存在私钥，验证则显示证书链是否通向预期的锚点。证书证明的是在既定策略下持有被接受的私钥；当私钥可以被导出和复制时，它并不能证明是哪台物理机器持有它。用笔记本的名字给配置文件命名，秘密的可携带程度和以前一模一样。在平台支持的地方，带证明策略的硬件保护密钥能提供更强的绑定，而注册仍然必须决定谁可以拿到这张凭据。

测试边界，然后规划移除

评估两种情况：已批准的笔记本和用户应该能连接，而只持有用户账号的另一台设备不应该能连接。如果设计同时要求用户检查和设备检查，要核实所选方法在同一次会话中同时执行两者，而不是假设两个独立设置会自动叠加。

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

吊销必须移除被接受的设备身份，而活动会话的处理值得单独测试。TPM 或受管设备标记并不是机器上每个进程的清白证明。

把网络限制、设备凭据和注册决定记录为三项控制，各有各的负责人。这样边界才可审查，而这正是一个地址永远无法提供的。