服务器锁定配置文件在 TLS 反向代理后失败：哪一代？
Access Server 2.8 与 2.9 生成服务器锁定配置文件的方式不同。在更换前端之前，先判断代理会破坏哪条路径。
同一天、同一个门户，一名用户可以连接，另一名却不能。两人的配置文件都属服务器锁定类型，都运行同一个 Access Server 构建，唯一的区别是配置文件生成的时间。这个模式值得识别，因为“服务器锁定”命名的是一种策略，而不是连接序列。Access Server 已经发布了该产物的两代版本，而 TLS 反向代理只挡在其中一条路径前面。三个条件决定你处在哪一枝上。
两代产物，两条连接序列
在沿用至 2.8 的旧设计里，导入的文件是一个伪配置文件。OpenVPN Connect 用它通过 HTTPS 向 Access Server 的 Web API 认证，取得临时用户锁定配置文件和会话令牌，然后才建立 VPN。两种传输依次运行，第一种是普通的 Web 请求。
随 2.9 引入的格式不做这种逐连接引导。它是原生配置文件，可被兼容的 OpenVPN 客户端使用，而不只是 OpenVPN Connect。下载或通过 URL 导入仍可能涉及 HTTPS——那是发布环节，不是每次连接都去取临时配置文件。
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
升级不一定重写已经签发的配置文件，所以当前服务器版本仍可能发放旧产物。服务器构建说明的是什么是可能的，而不是这名用户导入了什么。
决定你所在分支的三个条件
第一个条件是产物的代次。索取文件，查看它是如何生成的，并记录导入它的客户端版本。如果无法从文件判断代次，为测试账户新签发的配置文件会告诉你服务器今天生成什么，这与失败用户手里的信息不同。
第二个条件是前端实际终止了什么。卸载 TLS 的第七层 HTTP 反向代理，与第四层 TCP 转发器不是同一个对象，UDP 转发器也一样。Access Server 在 443 端口上的常见布局会让 OpenVPN TCP 守护进程识别浏览器流量并交给 Web 服务，所以在前面插入一个无关的 HTTPS 终止器并不能保留该守护进程的协议处理。共用 443 这个数字并不让两种设计等价。
第三个条件是失败发生在哪里。VPN 之前的失败与控制通道失败，在只会说“正在连接”的客户端里看起来相似，但留下的证据位置不同。如果涉及旧格式，引导过程就是嫌疑对象。如果涉及新格式，Web 访问日志为空是预期现象，两个方向都证明不了什么。
当产物是旧代次：引导最先失败
要读客户端的真实错误，而不是它的最终状态。值得关注的字段是 HTTPS 错误、客户端期望的服务器身份、请求去往的目的地，以及证书校验是否完成。然后把它们与服务器端的 Web 服务和代理日志对照。
浏览器能到达登录页，并不能证明这个客户端的 API 认证成功。它们是不同的请求，证书期望不同，主机名也常常不同。如果门户正常提供而客户端仍然失败，分歧就在引导路径上，而不在用户密码里。
不要通过关闭 TLS 校验或放宽认证策略来让对比通过。那会把可诊断的配置不匹配变成一条能跑通却未经校验的路径，而正是这种改动把临时测试变成长期漏洞。Access Server 关于连接配置文件的文档 描述了两代产物和临时配置文件流程，在假定代理有问题之前，应当先查这份参考。
当产物是新代次：转而读控制通道
使用 2.9 风格的配置文件时，客户端直接前往原生 VPN 端点。检查配置文件里的端点、使用的传输，以及控制通道错误。如果客户端从不发出 HTTP 请求，那与设计一致，不是症状。
代理问题的形态也在这里改变。HTTPS 卸载无法破坏它从未见到的纯 TCP 流，但它仍可能破坏发布配置文件的下载，而纯 TCP 转发器根本不会承载 UDP。在断定前端无关之前，先确认配置文件要求哪种传输。
单条流的 TLS 透传是一种狭窄的布置。它不提供 UDP 转发，也不复现守护进程自身在 443 上的服务转发行为。如果你的前端做了其中一件事，请说明是哪一件，因为补救方式不同。
保持狭窄的补救
侵入性最小的检查是为测试账户生成一份新的受支持配置文件，并用相同的认证要求通过预期的原生端点连接。如果这能成功，而保留下来的旧配置不能，你就用一步把产物与服务器、与代理分开了。
分发用户锁定配置文件 完全移除了对遗留引导的依赖，因为不存在可能失败的临时配置文件交换。它必须签发给目标用户，绝不能从管理员那里复制，而且它改变了客户端被授权做什么，所以要把它当作策略决定，而不是绕行办法。
然后修正发布布局，让每条必需路径都存在：用于下载和门户使用的 Web 路径，以及配置文件所期望的传输上的原生 VPN 路径。让代理的职责停留在单一层次。可用的用户锁定隧道证明那条路径可用；它不证明每种代理布置都支持每一代，而旧的引导失败也不否定较新的格式。
- 在动代理之前先确定产物的代次。
- 判断失败发生在隧道之前，还是在隧道之内。
- 确认前端终止的是什么：HTTP、TCP 流，还是 UDP。
- 在策略不变的情况下，用新签发的配置文件对照原生端点测试。