老规矩, 先看维基: 远端用户拨入验证服务（RADIUS, Remote Authentication Dial In User Service）是一个AAA协议，意思就是同时兼顾验证（authentication）、授权（authorization）及计费（accounting）三种服务的一种网络传输协议（protocol），通常用于网络存取、或流动IP服务，适用于局域网及漫游服务。
https://zh.wikipedia.org/wiki/RADIUS
上面的介绍来自维基百科. 说的权威,但是不太好懂. 我们这里再详细介绍以下几个问题, 希望能给初次接触radius的小伙伴有所帮助:
1) Radius 到底是什么.
2) Radius 应用和工作方式.
3) Radius 的协议细节.
一. Radius 到底是什么.
上面维基百科 说的很具体了, Radius 远程拨入服务, 它集成了 认证, 授权 和计费功能. 怎么理解这个问题呢. 举个不是十分贴切的栗子, 宽带 ADSL 拨号上网的后台认证和计费系统就可以用radius, 或者 V-P-N 系统的后台验证计费系统就是radius 的使用场景.
当然, 并不能把 radius 的概念限制在 “拨号”, 实际上, 不光是这种 “拨号” 服务, 其他几乎任何服务, 都可以使用 radius 来进行认证,授权和计费服务.
二. Radius 的工作方式.
我们以搭建 V-P-N 为例, 介绍radius的工作方式.
图中有三个角色, v-p-n(下面简称XXX服务器)服务器, 客户端 和radius 服务器.
Radius 主要工作在 xxx 服务器和 Radius 服务器之间, 客户几乎直接接触不到.
对于radius 协议来说, xxx 服务器实际上是 一个client, 而 radius 服务器是真正提供服务的server.
(如果看英文文档的话, rfc有专门解释 client 和server 的章节.)
这样看起来, radius 更像是 C/S 模式的协议.
所以后面的讨论主要集中在 xxx 服务器和 radius 服务器之间, 请自行脑补.
三. Radius 的协议细节.
这里还是介绍一下大体的细节, 重点介绍如何阅读rfc. 有了方向,再读rfc就容易多了. 不会详细介绍每个字节如何生成, 这是rfc的责任.
作为参考, 这是 radius 的rfc : https://tools.ietf.org/html/rfc2865
1) 首先, radius 是基于udp的协议, 所有数据包都是封装在udp协议中.
至于为什么是udp,而不是tcp, 请参看 rfc 的解释: Why udp?
2) radius 协议包的格式.
基本上, radius 协议有四种包:
Access-Request Access-Accept Access-Reject Access-Challenge
这四种包都有统一的格式: https://tools.ietf.org/html/rfc2865#page-13
这四种包在 xxx服务器和radius 服务器之间通信,来完成整个过程.
上图中, 前面三个交互是必须的, 后面两个绿色的带星号的交互不是必须的.
首先, xxx 服务器向radius发送 Access-Request 数据包, 包含用户信息和密码哈希等等信息用于认证.
此时服务器有四个选择:
第一, 如果认证通过,就返回一个 “Access-Accept” 数据包, 认证完成.
第二, 如果认证不通过,则返回 “Access-Reject”,认证失败.
第三, 如果服务器认为必要, 可以返回一个”Access-Challenge” 数据包, 让用户提供更多的附加信息以完成认证. 而xxx服务器在收到 “Access-Challenge” 消息之后, 需要向用户索要必须的附加信息,然后组成一个新的 ” Access-Request” 数据包发给radius服务器来继续认证. 此时服务器可以重复第一,或第二.
第四, 如果 “Access-Request” 数据包有问题, 服务器还可以采取 “静默丢弃”(silently discard) 的方式, 不做任何反应.
这就是主要的通信流程了.
一般来讲, 作为 radius 的客户端, “Access-Request” 数据包的格式比较重要. 他负责将认证信息加密传输给radius 服务器.
我们再介绍一下 “Access-Request” 数据包的格式:
https://tools.ietf.org/html/rfc2865#page-17
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Request Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
我们现在介绍后面的 “Attributes” 数据区. 这里包含了用户的密码信息.
radius 协议将用户名,密码等等身份信息 都封装成一个一个的 attribute.
举个栗子, 可能最少需要两个 attribute, 一个是用户名, 另一个是password hash. 这是最简单的方式了.
https://tools.ietf.org/html/rfc2865#page-22
目前, radius 的密码封装方式有两种,
一种是: User-Password, https://tools.ietf.org/html/rfc2865#page-27
另一种是: CHAP-Password, https://tools.ietf.org/html/rfc2865#page-28
两种方式只是密码的hash计算方法不一样而已. 具体生成方法比较明确. rfc 写的很明显,就不多说了.
到这里, radius 认证协议的客户端过程基本完成了. 至于服务端, 一般不用自己来写. 可以使用开源的现成服务端.
欢迎访问我的个人独立博客: https://blog.byNeil.com
来源：https://www.cnblogs.com/shuidao/p/4175316.html