Azure P2S 客户端认证：Entra、证书还是 RADIUS

安装程序能运行，配置文件能导入，连接却在登录这一步失败。这类工单大多不是客户端缺陷：一个兼容 OpenVPN 的应用可以承载隧道，却完全不知道如何执行 Microsoft Entra 登录。避免绕圈的顺序是：方法、客户端、配置文件。先选网关已配置的认证方法，再选微软为该方法记录的客户端，然后才生成该客户端期望的配置文件。下文全部遵循这个顺序。

从方法开始，而不是从安装程序开始

网关配置了一种或多种隧道类型和认证方法。决定支持哪些客户端的是这个组合，而不是桌面上的文件扩展名。

下载任何东西之前先把这个组合写下来，因为支持矩阵很窄，一开始选错就会浪费一下午。

下面是我记在部署笔记里的对应关系：

把这张表当成约束，而不是菜单。每一行都是经过记录的组合，把一行的客户端与另一行的方法混用，正是本文要避免的失败。

Entra ID 意味着 OpenVPN 加 Azure VPN Client

对于点到站点的 Entra 认证，受支持的组合使用 OpenVPN 隧道类型和 Azure VPN Client。通用的用户名和密码对话框不能替代这种集成，Windows 原生 IKEv2 也不是执行同一次登录的可互换方式。如果第三方客户端提供 Entra 或 Azure AD 选项，请对照微软当前的文档核实，而不是看标签。标签是营销，经过记录的组合才是契约。

在 macOS 上，Azure VPN Client 同样是该方法有记录的路径。

证书需要客户端凭据，而不只是一个根

证书认证是另一套受支持的模型，它适用于微软记录的 OpenVPN 客户端，也适用于受支持平台上的 Azure VPN Client。在 Windows 上，Azure VPN Client 并非只用于 Entra：它也有经过记录的证书工作流。它需要的是带可用私钥、被网关信任的目标客户端证书。网关的受信任根不是客户端凭据，签发者的签名密钥永远不属于客户端包。

调试配置文件之前先检查证书链。由网关不信任的根签发的证书会产生一种失败，看起来像配置文件有问题，实际却是信任问题。

在平台允许的地方让私钥不可导出，并用当前用户实际安装的证书进行测试。

RADIUS 是一种后端选择，有自己的组合

RADIUS 把凭据决策移到你自己运行的服务器上，并且针对特定隧道类型和客户端有记录。仅仅因为环境里有多种操作系统，它并不会自动成为正确答案。在更改网关的认证策略之前，先确定实际客户端能提供什么，因为把网关切换到 RADIUS 并不会让每个现有配置文件都适配。客户端仍然必须能够请求或提供这些凭据。

如果原因是混合环境，就按平台分别解决，而不是为所有人削弱网关策略。

2026 年预览版退役之后的 Linux

微软的 Linux 退役指南 把 2026 年八月31 日定为 Linux 版 Azure VPN Client 预览版的退役日期，所以在 2026 年十一月，那个预览版已经过去。现有安装也许还能继续工作，但不再获得支持、更新或安全修复。不要把旧的 Linux 安装程序当作受支持的新部署分发。这是客户端的退役，不是 Azure VPN Gateway 或 Windows、macOS 客户端的退役。

有记录的 Linux 替代方案是使用证书认证的 OpenVPN 客户端，或使用 IKEv2 加证书或 RADIUS 认证的 strongSwan。两者都是需要组织批准的另一种配置，而不是把旧的 Entra 配置文件改个名字就能完成的转换。

如果出于策略原因必须使用 Entra 登录，负责人必须选择受支持的平台或经批准的替代设计。这是决策，不是绕行。

生成配置文件并执行四项检查

组合确定后，从目标网关生成客户端配置，并导入为该客户端和方法记录的形式。通用 OpenVPN 文件夹与 Azure VPN Client XML 配置文件不能互换。如果网关有意启用多种认证类型，请选择匹配的配置文件和凭据路径，而不是指望一个连接满足全部。然后按这个顺序执行检查：

• 受支持的客户端导入生成的配置文件而无需编辑。
• 目标身份用该配置文件期望的方法完成认证。
• 所需的路由与解析器策略出现在客户端上。
• 被允许的应用程序能够访问其私有资源。

导入成功既不能证明认证兼容性，也不能证明私有资源授权，所以这四项检查始终分开。