VPN 证书并不能保护 LDAP 链路

对目录校验凭据的 VPN 登录涉及两条彼此独立的网络连接。用户到网关的连接由 VPN 自身的证书和协议配置保护。网关到目录的连接是另一条会话，有自己的 TLS 设置、自己的信任库和自己的失效方式。前者再严密，也不能保证后者。

这种不对称，正是“看起来已加密、却仍以明文发送 bind 密码”的登录背后的机制。

两条连接，两个信任决定

外层会话是用户所见的部分：绑定到 VPN 主机名的证书、由客户端校验、承载认证交换。内层会话属于网关内部的目录客户端，它自行建立连接，并决定是否协商 TLS。双方各自用另一份配置文件中的材料校验对端。内层链路配置有误时，从用户一侧完全看不见，因为外层链路照常运转。

所以故障是无声的，而不是响亮的。从不校验目录证书的网关依然能正确认证用户；只不过它是在一条未经验证的通道上认证。

StartTLS 与 LDAPS：有意的选择

StartTLS 以普通 LDAP 开始并在原地升级，通常使用 389 端口。LDAPS 在建立连接时即启动 TLS，通常使用 636 端口。两者都正当，适配器必须与目录实际提供的方式一致。强制要求 StartTLS，与“尝试升级、失败后继续”是两回事，而 bind 密码恰恰可能从这个差别中泄露。请配置严格模式，不要为密码 bind 保留未受保护的退路。

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ 选项正是关键：查询会直接失败，而不是在未升级的情况下静默继续。该行中的名称与账号均为示例。OpenLDAP 的 TLS 文档介绍了其背后的信任设置。

LDAP 客户端读取哪一个信任库？

OpenLDAP 客户端库读取的是它自己的信任配置，可能来自系统文件，也可能来自某个插件专属设置。VPN 的 CA 指令只作用于 VPN 对端，并不能证明 LDAP 库读取同一文件。请使用证书真正覆盖的目录主机名，以及库所信任的签发链。在 Active Directory 中，应部署用途正确的目录服务证书，而不是凭显示名称去推断。

每一个故障转移目标都必须满足同一身份策略。主节点经过校验、备节点没有校验的环境，比没有故障转移更糟，因为较弱的那条路径只会在故障时才被发现。

bind 账号仍是独立的问题

保护传输并不能缩小 bind 账号的权限范围。目录搜索范围、组授权和服务账号的权限是彼此独立的决定；启用了 TLS 之后，一个宽泛的 bind 账号依旧宽泛。请使用集成所需的最窄服务账号和搜索基准，并把端点、TLS 模式、信任归属和续期流程与 VPN 配置一并记录。

出现证书不匹配时，应部署正确的证书或证书链。关闭校验只会把看得见的不匹配变成看不见的问题，并让第二重信任关系始终未经验证。

两条连接、两位负责人、两个续期日。在文档中把它们分开记录，才能让登录保持诚实。