Mac VPN 证书:网关看到的究竟是谁的账户?
配置文件名、凭据和账户字段回答的是不同的问题。改动任何名称之前,先沿着主体追到网关上的映射。
配置文件显示的是你的名字,证书的显示名称说的是另一回事,而网关日志记录的又是第三个标识。三者都没有说谎,问题恰恰在这里:三个不同的字段被当成在回答同一个问题。连接会同时出示一份凭据、一个 IKEv2 标识和一个账户,而由网关决定其中哪一个授权了什么。
一条连接里的三重身份
可见的配置文件名只是给人看的标签。它只负责选择一条连接,仅此而已。证书是一份凭据,它能否证明任何东西,取决于客户端有没有配套的私钥。账户字段是对某个主体的主张,而服务器完全可以把该主体映射到另一个本地身份。
认证失败时,先问清楚错误指的是三者中的哪一个。凭据被拒、标识不认识、账户被禁用会产生不同的信息,把它们统统当成一个「证书问题」,只会把你送到错误的控制台。
按职责理解这些原生字段
在受管的原生 IKEv2 配置中,Apple 的载荷参考把各个值分开,而认证方式决定需要哪一组组合:
| Field | Identifies | Common misreading |
|---|---|---|
| AuthName | Username for the configured arrangement | Assuming it is the certificate subject |
| LocalIdentifier | IKEv2 client identifier | Assuming it must equal the username |
| PayloadCertificateUUID | Referenced credential payload | Assuming any installed certificate will do |
证书与 EAP 登录可以在同一条连接里承担不同角色。不要因为其中一个这样填,就强迫每个字段都填同样的文本;也不要以为改了一个就会覆盖其他几个。第三方 VPN 应用可能完全使用另一套模型;应当采用它文档中说明的身份选择方式,而不是把原生字段名硬套进去。
服务器证书不是客户端身份
用来验证网关的证书是信任锚。它证明你连到的确实是预期中的服务器。客户端身份则是另一个对象:它包含对私钥的访问权,用来证明发起连接的一方确实是自己声称的那个人。给可见账户改名并不能把两者互相转换。
好心修错的地方就在这里。把网关的 CA 证书导入客户端存储,对客户端认证毫无帮助;给那条记录贴上用户名,也不会让它变成用户身份。这两个对象分别存在于配置文件的不同部分,回答的是不同的问题。
沿着主体追到网关上的映射
先确认凭据是签发给谁的:是这位用户、这台设备,还是一个共享角色。Mac 的登录账户并不自动等于那个主体;从另一台机器复制来的证书,保留的仍是它当初被签发时所属机器的身份。
然后比对真正的凭据,而不是名称。签发者、序列号和指纹能让你和管理员确认双方谈的是同一个对象。显示名称可以随意修改,也经常重复,因此在事故处理过程中,它是最糟糕的标识。
最后一步在网关上。请网关的负责人把某一条连接与它出示的标识、以及消费这些标识的账户映射规则对应起来。客户端一侧的名称无法证明服务器做了什么决定;一条把证书映射到已禁用账户的规则会一直报错,而客户端的每个字段看起来都正确。
修好拥有这处不一致的那一层
如果配置文件指向了错误的凭据,就改正它的引用或选择。如果凭据属于别的主体,就走签发方的重新登记流程,而不是去改名称。如果网关把有效凭据绑到了错误的账户,那必须由它的策略负责人来修映射。这是三种不同的改动,需要三种不同的审批人。
续期同样需要这份谨慎。更换证书、修改它的显示名称、把人从一个账户体系迁移到另一个,对映射的影响未必相同。请记下你改的是三者中的哪一个,因为下一次故障从客户端看会一模一样,在网关日志里却不一样。
只分享支持工作所必需的最小公开标识。私钥或完整的身份包永远不属于这种交换,无论它能让诊断变得多方便。