VPN 网关、核心交换机、企业级无线 AP……这些底层网络设备在做身份验证时，几乎清一色只认 RADIUS 协议。在 authentik 统一身份认证 的四种接入方式里，RADIUS 专门负责把这些硬件设备也纳入统一的账号版图。它的核心目标很简单：让员工能用统一的账号连上办公区 Wi-Fi 或远程 VPN，离职时瞬间切断网络访问权限。
本篇我们将拆解 RADIUS 的基础概念和认证时序，聊聊为什么在密码认证时 authentik 只能被迫选择最原始的 PAP，以及在配置共享密钥和来源网段时，如何才能把安全措施真正做到位。内容基于 authentik 2026.8 的官方文档。
TL;DR
- RADIUS 的“客户端”是网络设备（NAS），不是员工电脑；authentik 的 RADIUS outpost 监听 UDP 1812，只做认证不做计费。
- 密码认证只支持 PAP：authentik 只存不可逆的密码哈希，CHAP、MS-CHAPv2 都用不了。
- PAP 的保护很弱：每台设备用独立的长随机共享密钥，RADIUS 只走内网，Client Networks 只填设备地址。
- MFA 要拼在密码后面：
密码;123456。 - 先问 VPN 支不支持 SAML 或 OIDC：支持的话走浏览器单点登录，体验和安全都更好；RADIUS 是兜底方案。
Table of contents
Open Table of contents
1. 快速看懂 RADIUS
RADIUS 是网络设备在做身份验证时事实上的标准协议。要搞懂它，只需明确以下几个核心概念：
- 谁是客户端？：VPN 网关、交换机等网络设备。在 RADIUS 的语境里，客户端被称为 NAS（Network Access Server）。切记，客户端指的是硬件设备，而不是员工自己的电脑。
- 谁是服务端？：authentik 的 RADIUS Outpost 组件，默认监听在 UDP 1812 端口。
- 共享密钥（Shared Secret）：每台设备与服务端之间都会事先约定好一串复杂的密码。它用来向 authentik 证明“这个请求确实来自那台合法的 VPN 设备”，同时也被用来简单保护传输中的密码字段。
- 请求与响应：设备向 authentik 发送
Access-Request；authentik 验证后，要么返回Access-Accept（放行），要么返回Access-Reject（拒绝）。
另外要注意的是：authentik 的 RADIUS 只支持认证（Authentication），不支持计费（Accounting）。 员工什么时候连上的 VPN、用了多少流量、什么时候断开，authentik 这里全都没有，你只能去查 VPN 设备自己的日志。
2. 认证时序与原理
我们以 VPN 登录为例，看看密码是如何流转的：
就像 LDAP 里的问题一样，密码会先原样交给 VPN 设备，因此员工不能飞书扫码，必须提前在 authentik 里设置好内部专用的密码。
当 Outpost 收到 VPN 设备转发来的请求后，它会在 authentik 内部跑一遍 Bind Flow。那些被禁用、未设密码，或是压根不在当前 RADIUS 应用权限绑定（Binding）范围内的账号，会在这里被直接拒之门外。
3. 为什么密码认证只支持最原始的 PAP？
RADIUS 有很多种传输密码的模式。像 CHAP、MS-CHAPv2 这些看起来高级一点的模式，都要求服务端必须能拿到用户的明文密码或者特定格式的可逆哈希，这样服务端才能算出比对结果。
但是，authentik 出于绝对的安全底线，数据库里只保存不可逆的密码哈希算法（如 Argon2）。因此，当使用密码认证时，authentik 只能被迫支持最古老、最原始的 PAP 模式。
在 PAP 模式下，密码在网络传输时，仅仅是用“共享密钥”做了一层基于 MD5 的简单混淆。这种保护极其脆弱，这也是为什么你在配置时必须遵守以下铁律：
- 每台设备必须使用独立、超长的随机共享密钥。绝不能多个设备复用一个。
- RADIUS 流量必须且只能走安全内网。Outpost 的 UDP 1812 端口绝对不能暴露在公网上。
- 必须严格收敛来源网段。在 Provider 的
Client Networks里，老老实实把合法的 VPN 和网络设备的 IP 填进去，绝不要填0.0.0.0/0图省事。
EAP-TLS（证书认证） 是更高阶的玩法：员工设备上安装客户端证书，用证书代替密码完成认证。但这是 authentik 企业版的专属功能，开源版无法使用。此外，这套方案不仅需要企业版 License，还需要企业自建一套完善的 CA 来给设备签发证书。
4. MFA 怎么拼？厂商属性怎么下发？
关于 MFA：
如果在 Bind Flow 里加入了 Authenticator Validation 步骤，MFA 就会生效。员工输入密码时，需要硬核地把动态码拼在密码后面，例如：密码;123456。它同样只支持 TOTP、Duo 和静态恢复码，不支持短信验证。
下发厂商特有属性：
通过 RADIUS Provider 的 Property Mapping，你可以让 authentik 在同意放行（Access-Accept）时，附带下发一些厂商自定义的属性（Vendor-Specific Attributes）。比如，告诉 VPN 网关“这个员工是研发，给他下发研发组的路由和 IP 地址池”。能下发哪些属性完全取决于你的网络设备品牌，具体格式请参考厂商手册（官方文档里提供了一个 Cisco AV-Pair 的示例）。
实战建议：先问一句你的 VPN 支不支持 SAML 或 OIDC。 现代的企业级 VPN（比如部分商业防火墙）其实早就支持了浏览器跳转式的单点登录，员工可以直接扫码，也能用上原生的二次 MFA 验证界面。相比之下，RADIUS 只能手拼动态码的体验确实很糟糕。RADIUS 应该只作为不支持现代协议的老旧 VPN 和底层网络设备的最后兜底方案。
5. 排障指南：那些常见的报错
| 现象 | 最可能的原因 |
|---|---|
| 设备发了请求，但收不到任何响应 | UDP 1812 网络不通；设备的 IP 不在 Client Networks 允许名单里；或者你前面挂的负载均衡根本没有配置 UDP 监听。 |
| 认证一直被拒绝，但 authentik 后台没记录 | “共享密钥”配置不一致；或者 VPN 设备死活要用 CHAP 或 MS-CHAPv2，请去设备端把认证协议强制改为 PAP。 |
| 认证一直被拒绝，authentik 后台有失败记录 | 员工没设内部密码；不在 RADIUS 应用的权限绑定范围内；开启了 MFA 但员工没按 密码;动态码 的格式输入。 |
6. 生产环境的取舍与防坑经验
已建立的 VPN 连接不会因账号被禁用而自动断开。 authentik 仅仅在 VPN 连接建立的那一瞬间做一次认证。员工离职账号被禁用后，他发起的新连接会被立刻拒绝；但他只要不断开，那条已经连上的 VPN 隧道通常会一直存活。遇到紧急情况，你必须登录到 VPN 设备后台，手动把该用户强行踢下线（完整的离职处理见 架构与接入方式选型）。
VPN 如果完全依赖 authentik，故障时就成了死循环。 如果 authentik 突然宕机，运维在家里连不上 VPN，就进不去内网；进不去内网，就没法去修 authentik。所以，VPN 设备上必须预留一个不走 RADIUS 的本地应急管理员账号，凭据封存在保险箱里，定期演练“破窗接入”。
RADIUS Outpost 需要多副本，且负载均衡必须支持 UDP。 RADIUS 走的是 UDP，但很多传统的七层负载均衡器并不支持转发 UDP 流量。上线前请务必确认 1812 端口的健康检查和 UDP 转发都配置正确；另外，大部分商业网络设备也支持配置主、备两个 RADIUS 服务器地址，建议直接把两个 Outpost 实例的 IP 填进去做冗余。