FreeRadius原理
分爲3個部分:用戶/nas/radius
用戶提供認證名、密碼到NAS（Network Access Server）
NAS一般是路由器、交換機等設備
NAS提交相應信息到radius服務器，由radius服務器進行認證，其中認證信息也可以存放於mysql、ldap、oracle、postgreSQL等數據庫中
NAS發送radius-request到radius服務器，如果多次連接失敗，則NAS可發送數據包到其他radius服務器
Radius服務器根據用戶名查找相應記錄，包括用戶口令、訪問端口、訪問權限等，如果用戶被否認的話，radius服務器發送radius-reject包到NAS
如果用戶被確認，則radius服務器發送radius-challenge數據包，要求NAS提供更多的相關屬性數值；NAS通知用戶要求提供更多信息，然後再創建radius-request包，而radius服務器經覈實後，再次發送radius-accept包，返回用戶所需的屬性（ip、mask、MTU等）
Radius數據包結構：
Code（8bit）、identifier(8bit)、length(16bit)、Authenticator(128bit)、Attributes（不定長）
Attribute結構：
Type、length、value
常用的Type類型：
User-Name Password CHAP-Password NAS-IP-Address NAS-Post-ID Service-Type Frame-Protocol等等
User-Password或CHAP-Password默認以md5加密
Attributes應該包括以下幾個屬性：
◆ “User-Name”
◆ “User-Password”或“CHAP-Password”
◆ “NAS-IP-Address”
* “NAS-Identifier”
◆ “NAS-Port”
◆ “NAS-Port-Type”
早期的users文件格式：(man 5 users)
Username check_items
Reply_items
其中，check items中的屬性值和radius-request包中的屬性值做比較，如果匹配則將reply items中的屬性值添加到radius-reply包中去
如果username爲DEFAULT 則匹配所有用戶名
屬性：Fall_Through=No表示不再查詢下一條匹配記錄，直接返回。
屬性操作符：
“＝” 賦值操作符，不得用於check items，如之前無相應屬性則添加
“：＝” 總用於check items，如果request包中沒有該屬性，則添加，並且覆蓋config items中的相同屬性值
“＋＝” 用戶check items，總是添加當前屬性值到config items中。
“＝＝”、“！＝”、“＝～”、“！～”、“＝*”、“!*”都是邏輯判斷符
Sql模塊分爲：
前端：rlm_sql
後端：rlm_sql_mysql/rlm_sql_postgresql等
Sql查看流程：
1. Search the radcheck table for any check attributes specific to the user
2. If check attributes are found, and there's a match, pull the reply items
from the radreply table for this user and add them to the reply
3. Group processing then begins if any of the following conditions are met:
a. The user IS NOT found in radcheck
b. The user IS found in radcheck, but the check items don't match
c. The user IS found in radcheck, the check items DO match AND
the read_groups directive is set to 'yes'
4. If groups are to be processed for this user, the first thing that is
done is the list of groups this user is a member of is pulled from the
usergroup table ordered by the priority field. The priority field of
the usergroup table allows us to control the order in which groups are
processed, so that we can emulate the ordering in the users file. This
can be important in many cases.
5. For each group this user is a member of, the corresponding check items
are pulled from radgroupcheck table and compared with the request. If
there is a match, the reply items for this group are pulled from the
radgroupreply table and applied.
6. Processing continues to the next group IF:
a. There was not a match for the last group's check items
(The above is exactly the same as in the users file)
7. Finally, if the user has a User-Profile attribute set or the Default
Profile option is set in the sql.conf, then steps 4-6 are repeated for
the groups that the profile is a member of