摘要：
简介处理部分形成驱动服务器策略的引擎。当服务器接收到请求或发送响应时，将执行一个或多个处理部分。服务器的行为和进入任何响应的信息完全取决于如何处... 简介
处理部分形成驱动服务器策略的引擎。当服务器接收到请求或发送响应时，将执行一个或多个处理部分。服务器的行为和进入任何响应的信息完全取决于如何处理这些部分。
处理一个请求取决于以下四项内容：
请求处理部分的内容是Unlang语句。
术语和定义
介绍服务器的处理算法。
许多属性列表与服务器接收到的每个请求相关联。每个列表都有名称。下表给出了这些列表名称的含义。
属性通过列表名、冒号和属性名(例如，request:User-Name或reply:Class)来引用。每个列表都有特定的用途。单个模块可以编辑一个或多个列表;例如，mschap模块将向应答添加MS-CHAP属性。或者，管理员可以使用“unlang”语句直接编辑列表。
每个请求都经过一个或多个处理部分。下表给出了各部分及其含义。
每个处理部分都是要执行的模块列表或要处理的Unlang语句。该列表按从上到下的顺序进行处理。
在某些情况下，跳过列表的某些部分或从处理列表中提前返回是很有用的。例如，如果由于策略规则而发送了一个“reject”，则通常没有理由继续处理该列表。
当一个模块被执行时，返回代码如"reject"， "noop"，或"ok"是结果。这些返回代码控制列表的处理。下表显示了返回代码的名称及其含义。
每个处理部分都有一个对各种返回代码的默认响应列表——例如，“noop”通常会被忽略，“reject”会导致服务器停止处理列表，等等。每个返回代码也有一个优先级:“reject”的优先级高于之前的“noop”。
返回代码和默认操作的列表如下表所示：
现在已经提供了理解服务器如何处理请求所需的所有部分。
服务器用默认的返回代码和优先级启动每个请求。它通过处理部分处理请求。
每个语句或模块都会被求值，语句返回代码用于更新与请求相关联的最终返回代码。当列表完成时，服务器要么继续下一个部分，要么向请求发送一个应答。
服务器使用的算法如下伪代码所示：
(code, 0) = action_table[default]
foreach (statement in section) {
code' = evaluate(statement)
(action, priority') = action_table[code']
if (action == return) {
code = code'
break;
}
if (priority' >= priority) {
(code, priority) = (code', priority')
}
}
return (code, priority)上面算法中的“evaluate”函数应该被看作是执行一个模块(例如mschap)或者解释一个“unlang”语句。当unlang语句涉及到一个子部分时，算法将在该子部分上递归运行。
服务器进程
服务器通过一个或多个数据包处理部分处理每个请求。运行FreeRADIUS可能涉及以下任何处理部分：
下图说明了不同操作所使用的不同数据包处理部分。
数据包处理
身份验证
介绍服务器收到用户的访问请求报文并对用户进行认证时的情况。
由于历史原因，此章节的名称为authorize，因为服务器的早期版本没有post-auth章节。对这一章节更准确地描述是pre-authentication。
authorize章节处理Access-Request数据包的方式是：对请求进行规范化，确定使用哪种身份验证方法，为用户设置“known good”密码(在数据库中找到的有效密码)，或者通知服务器应该代理该请求。
一旦authorize章节完成了数据包的处理，服务器将检查该部分的返回代码。如果返回代码是noop、notfound、ok或updated，则请求处理将继续。如果处理了返回代码为handled，则假定其中一个模块设置了应答的内容，并且服务器发送应答消息。否则，服务器将身份验证视为被拒绝，并运行post-auth章节。
如果身份验证没有被拒绝，那么服务器通过在控制列表中搜索Auth-Type属性继续处理请求。一旦找到Auth-Type属性，就会执行认证的命名子章节，如下所述。这个功能是历史的，可以追溯到2.0.0之前的版本。对于版本2.0.0及更高版本，我们建议使用Unlang策略，它更灵活，也更容易理解。
注意：authorize部分不应该用于设置回复的属性。尽管这种做法非常普遍，而且由于历史原因是默认配置，但它并不是好的策略设计。应该使用authorize部分来定义策略，使用post-auth部分来设置应答属性。
当执行同时使用或双重登录检测时，会话部分用于执行数据库查找。它仅用于Access-Request报文。
authentication部分仅在服务器对请求进行本地身份验证时使用，在进行代理时完全绕过。该章节不同于其他章节：它由一系列子章节组成，只执行其中一个子章节。相关的子章节是根据在control列表中找到的Auth-Type属性的内容来选择的。
Auth-Type属性也可以引用模块(例eap)而不是子模块，在这种情况下，该模块(且仅该模块)会被处理。
Auth-Type子章节可能包含一系列Unlang语句，这在修改认证结果时很有用。
完成身份验证部分后，将执行post-auth章节。
post-auth部分包含认证成功或认证失败(被拒绝)后应用的策略。
当身份验证成功时，将处理post-auth部分的内容以及任何其他相关部分。
当身份验证失败时，服务器将寻找一个名为Post-Auth-Type Reject的子章节，如果找到，则只执行该章节中找到的语句。如果不存在这样的章节，则不进行后认证处理。
要更新任何回复属性，建议只使用post-auth部分，尽管这可能比较困难。许多模块只在它们的authorize方法中提供reply属性。可以通过使用模块名从认证后部分调用该方法。授权语法(例如，sql.authorize)。
计费
此部分描述了当服务器接收到一个计费请求时会发生什么。
preacct部分用于通过对请求进行规范化和确定是否应该代理请求来处理Accounting-Request数据包。
如果该章节返回noop、ok或updated，则处理计费章节。否则，服务器停止处理请求，不响应一个计费响应包。
计费部分用于处理Accounting-Request报文。
如果在control列表中设置了Acct-Type属性，那么只处理那个命名的子章节。否则，整个计费部分将被处理，而acct-type的章节将被忽略。
一旦处理了计费部分，服务器就会检查请求是否应该被代理。这个顺序允许服务器在本地记录计费数据包，并同时代理它们。
代理身份验证
该章节描述了当服务器接收到访问请求并对其进行代理时发生的事情。
在代理身份验证过程中，与正常身份验证过程一样运行authorize部分。
pre-proxy部分用于在被代理之前处理请求。本节是用于所有请求,包括Access-Request， Accounting-Request， CoA-Request和Disconnect-Request。
如果对不同类型的报文需要不同的策略，可以使用home_server_pool部分定义一个virtual_server项。虚拟服务器可以包含代理前和代理后部分，这些部分只有在向该池中的主服务器发送请求时才会执行。
由于主服务器是类型化的，并且与正在发送的请求类型绑定在一起，因此该配置允许针对每种类型的请求使用不同的策略。
post-proxy部分用于处理来自主服务器的回复。作为post-proxy部分，这部分是用于所有请求,包括Access-Request， Accounting-Request， CoA-Request和Disconnect-Request。
post-proxy部分最常用来过滤来自主服务器的回复，以删除不适当的授权，如VLAN设置或IP地址分配。
与预代理部分一样，如果对不同类型的数据包需要不同的策略，可以使用home_server_pool部分来定义virtual_server条目。虚拟服务器可以包含pre-proxy 和 post-proxy部分，这些部分只有在向该池中的主服务器发送请求时才会执行。
主服务器可能不会在response_window时间内响应代理请求(参见proxy.com文件)。当response_window时间过期时，代理请求的服务器就会执行post-proxy部分的Post-Proxy-Type的Fail部分。此行为允许管理员为无响应的主服务器定义策略。
post-proxy部分完成执行后，将丢弃回复列表中的所有现有属性，并将post-proxy属性复制到回复列表中。此行为允许主服务器定义发送回NAS的默认应答。
代理计费
在代理计费过程中，preacct部分的运行与正常的计费过程相同。
在代理计费期间，计费部分的运行与正常计费会话期间相同。
代理计费时，与代理认证时一样，执行pre-proxy。
代理计费时，与代理认证时一样，执行post-proxy。
变更授权(CoA)
send-coa部分负责发送授权消息的变更这些消息被发送到NAS，然后NAS断开用户与网络的连接。网络管理员还可以使用变更授权消息来为用户的会话添加额外的过滤规则；一个例子是在用户的会话上设置带宽限制。
recv-coa部分用于处理来自NAS的CoA-Request或Disconnect-Request报文。此部分可能导致请求被代理，在这种情况下，执行pre-proxy和post-proxy部分，如上所述。
recv-coa部分接收并处理授权消息的变更。例如，如果用户断开连接，该章节中的模块可以显示消息。
最小化radiusd.conf
默认的配置文件包含数千行配置定义和注释。虽然所有这些数据在一开始可能显得很困难，但服务器配置可能非常简单。缺省配置很复杂，因为它只做简单的计算并支持许多身份验证协议。
下面提供一个小型简单的配置文件的示例，展示服务器配置可以多么简单。
服务器的唯一要求是：
下面显示了一个简单的配置示例。将以下文本放在一个名为small.conf的文件中：
listen {
type = auth
ipaddr = *
port = 0
}
client localhost { # allow packets from 127.0.0.1
ipaddr = 127.0.0.1
secret = testing123
}
modules { # We don’t use any modules
}
authorize { # return Access-Accept for PAP and CHAP
update control {
Auth-Type := Accept
}
}要在调试模式下启动服务器，请使用small.conf文件，而不是默认的radiusd.conf文件。你可以使用下面的命令来做到这一点：
$ radiusd -X -n small此配置接受包含PAP或CHAP身份验证方法的任何本地主机访问请求，并返回一个Access-Accept。
