登记 VPN 用户：先找到身份的所有者

有人申请 VPN 访问权限，第一反应是在服务器上执行 adduser。这种反应只在一小类部署中成立。在创建任何东西之前，先打开服务器配置，弄清上面运行的是哪款产品、在哪里校验凭据，因为账号可能存在于产品数据库、身份提供方，或主机自身的认证栈中。创建了错误类型的账号，人虽然有能用的登录，却没有隧道。

写明 OpenVPN 的客户端配置只说明协议，不说明它背后的身份系统。

从服务器开始，而不是从 adduser 开始

先确认产品。Community OpenVPN 是守护进程加上你接入的任何认证，而 Access Server 是带有自己用户层的产品。索取配置、unit 名称和软件包列表，并检查是否存在用于用户管理的 Web 界面。然后看部署的配置期望客户端用什么证明身份：证书、用户名加密码，或两者都要。这个答案就点明了拥有账号的系统。

只有到这时，创建用户这句话才有意义。在只有证书的部署中，它意味着通过既定流程签发设备身份，Unix 登录不改变任何东西。在密码部署中，它意味着真正校验密码的那个后端。

四种后端，四个创建账号的地方

Access Server 的本地认证把账号保存在自己的数据库里，所以创建账号的界面属于产品，而不属于主机。PAM 把校验交给操作系统的认证栈，正因如此，当服务选择的正是该栈时，本地 Unix 账号可以成为登记的一部分。LDAP、RADIUS 和 SAML 把校验移到外部服务，开户、密码策略和 MFA 都在那里。在这四种情况下，Access Server 仍然可以保存每个用户的证书和权限，这正是让划分变得混乱的原因。

要检查这个具体用户的实际生效方式，而不是全局默认值。Access Server 2.10 及更高版本可以按组或按用户应用不同的认证方式，所以默认值是本地并不能证明眼前这个账号是在本地校验的。

授权是另一个决定

认证回答这个人是谁；授权回答他能到达什么。把两者保持为两步，因为登录成功不等于授予权限。有意分配预期的路由、资源权限和管理权限，并确认不相关的访问仍被拒绝。在部署支持个人身份的地方，为每个人单独签发，而不是转发别人的配置，因为共享配置无法只为一个人吊销。

客户端材料同样重要。自动登录配置和交互式用户登录代表不同的认证关系，互换两者会改变服务器实际校验的内容。

吊销访问权限是登记的一部分

在创建用户时记下三个所有者：谁校验账号、谁批准 VPN 访问，以及哪个设备或配置代表这条连接。这三者可能是三个不同的系统，只点名其中一个的吊销方案会留下一条通路。当这个人离职时，从对应的所有者那里移除授权，并在其所有者处吊销每一份已签发的凭据。删除下载的文件不是吊销；如果外部身份仍然通过认证，删除本地条目也不是吊销。

然后像攻击者那样测试这次登记：用新身份连接一次，确认能访问预期资源，并确认不相关的资源仍然拒绝。第一次连接成功，再加上一次否定测试，才算完成登记。

把记录和它所属的配置放在一起。下一位审计员会问某个月里谁能连上，答案就在那三个所有者身上。