RADIUS 計費：追蹤會話、使用情況與稽核記錄

執行摘要

對於企業 IT 與網路營運團隊而言，讓使用者通過 WiFi 網路驗證只是成功的一半。一旦裝置連線後，瞭解該裝置的行為——連線了多久、消耗了多少資料量、何時中斷連線——對於安全性、容量規劃與法規遵循至關重要。這就是 RADIUS 計費 不可或缺的原因。RADIUS 驗證負責處理網路存取的「誰」與「如何」，而 RADIUS 計費則詳實記錄了「什麼」、「何時」與「多少」。

本指南將深入探討 RADIUS 計費的技術細節，涵蓋開始、停止與臨時更新封包的運作機制，以及使其具有價值的屬性。文中將說明 餐旅業 、 零售業 及其他行業的場域營運商如何運用這些資料，維護完善的稽核軌跡、確保 GDPR 合規性，並將可行的情報饋送至 SIEM 平台或 WiFi Analytics 系統。透過精通 RADIUS 計費，網路架構師能將原始會話記錄轉化為策略性資產，提升營運效率並降低風險。

技術深入探討

RADIUS 計費與 RADIUS 驗證的比較

RADIUS（遠端驗證撥入使用者服務）定義於 RFC 2865 ，並在 RFC 2866 中擴充計費功能，採用主從式架構。在常見的企業 WiFi 部署中，存取點（AP）或無線區域網路控制器（WLC）擔任 網路存取伺服器（NAS）——亦即 RADIUS 客戶端。RADIUS 伺服器（例如 FreeRADIUS、Cisco ISE、Aruba ClearPass）則接收並處理請求。

驗證與計費之間的區別至關重要：

對於大規模部署 Guest WiFi 的團隊而言，這兩項功能都是必要的——但計費功能才是確保合規性與防禦能力的關鍵。

三種計費封包類型

RADIUS 計費仰賴三種主要的 Accounting-Request 封包類型，各自以 Acct-Status-Type 屬性定義：

1. 開始（Acct-Status-Type = 1）：當使用者成功連線並建立會話時，由 NAS 發送。此封包會在計費資料庫中建立基準記錄，擷取使用者身分、裝置 MAC 位址、指派的 IP 位址，以及使用者連線的 AP。

2. 臨時更新（Acct-Status-Type = 3）：在活躍會話期間定期發送。這些封包提供當前用量的執行快照——傳輸的位元組數、會話持續時間與封包計數。它們如同心跳般確認會話依然存在，並提供對長時間運作會話的可見性，無需等待中斷連線。

3. 停止（Acct-Status-Type = 2）：當會話終止時發送——可能是使用者主動中斷連線、AP 重新啟動、閒置逾時或會話逾時。其中包含整個會話的最終累計統計資料。

圖 1：RADIUS 計費封包在 WiFi 會話生命週期中的流程。

關鍵計費屬性

為了有效追蹤會話並建立可防禦的稽核記錄，NAS 會將特定屬性填入 Accounting-Request 封包中。以下是最具營運重要性的屬性：

對於使用 802.1X Authentication 的團隊，User-Name 屬性將包含來自 EAP 交換的已驗證身分，提供比單純 MAC 驗證旁路（MAB）更豐富的稽核軌跡。

實作指南

部署可靠的 RADIUS 計費基礎架構，需要同時在 NAS 與 RADIUS 伺服器層級進行謹慎的設定。以下是建立可靠計費管線的跨廠商方法。

步驟 1：設定 NAS（存取點／控制器）

NAS 設定是多數部署失敗的關鍵所在。管理員通常會正確設定驗證，但卻讓計費維持預設設定或完全停用。

• 定義計費伺服器：指定 RADIUS 伺服器的 IP 位址，以及用於 UDP 連接埠 1813 的共用密鑰。在高可用性部署中，請設定次要計費伺服器，避免主要伺服器無法連線時造成資料遺失。
• 啟用臨時更新：這是最重要的一項設定步驟。設定適當的間隔——企業部署通常為 10 至 15 分鐘。較短的間隔（例如 1 分鐘）可提供更細微的資料，但會在大規模環境中產生難以承受的寫入負載；較長的間隔（例如 30 分鐘）則可減少負荷，但會延遲對活躍會話的可見性。
• 確保時間同步：在所有 NAS 裝置與 RADIUS 伺服器上設定 NTP。準確的時間戳記對於稽核記錄與 SIEM 關聯而言是不可或缺的。在合法攔截情境下，5 分鐘的時鐘誤差就可能使整條稽核軌跡失效。

步驟 2：設定 RADIUS 伺服器

• 資料庫整合：將 RADIUS 伺服器設定為將計費資料記錄至結構化的關聯式資料庫（例如 PostgreSQL、MySQL），而非純文字檔案。結構化儲存可實現高效的查詢、索引，以及與下游系統的整合。請確保在 Acct-Session-Id、User-Name、Framed-IP-Address 以及會話開始時間戳記上建立索引。
• 資料保留政策：根據合規要求，實作自動化歸檔或清除指令碼。GDPR 第 5(1)(e) 條要求資料保存期限不得長於必要時間；然而，許多司法管轄區的合法攔截法規（如英國《2016 年調查權力法》）可能要求保留長達 12 個月。

步驟 3：建立資料管線

為了最大化計費資料的價值，必須將其匯出至消費平台，以便進行查詢、關聯與視覺化呈現。

• SIEM 整合：設定 RADIUS 伺服器或底層資料庫，透過 Syslog 或 REST API 將記錄轉送至您的 SIEM（例如 Splunk、Microsoft Sentinel、IBM QRadar）。這讓安全團隊能將 WiFi 驗證事件與防火牆封鎖、入侵偵測警示或資料外洩防護觸發條件進行關聯。
• 分析整合：將會話資料饋送至 Purple 的 WiFi Analytics 等平台，將原始位元組與 MAC 位址轉化為關於人流、停留時間與尖峰用量時段的可行見解。這對於需要將人力配置與基礎架構投資對齊實際使用模式的 零售業 與 餐旅業 營運商特別有價值。

圖 2：從存取點到 SIEM 與分析平台的 RADIUS 計費資料管線。

最佳實務

永遠使用臨時更新。 僅依賴開始與停止封包會造成營運盲點。中斷的連線或 AP 電源故障可能導致停止封包從未被發送，使過時會話無限期停留在資料庫中。臨時更新提供了偵測並關閉這些過時會話的機制。經驗法則：如果某個會話在超過設定的間隔的兩到三倍時間內未發送臨時更新，就應視為已終止。

將 RADIUS 計費與 DHCP 記錄進行關聯。 RADIUS 計費提供 Framed-IP-Address，但在某些環境中，DHCP 租期可能短於會話長度。同時維護 DHCP 記錄與 RADIUS 記錄可提供更具復原力的稽核軌跡，特別是在 IP 位址頻繁回收的高密度場域中。

使用 RadSec 保護傳輸。 傳統 RADIUS 流量透過 UDP 傳輸，僅有最低限度的加密——僅使用者密碼欄位經過混淆處理。在分散式部署中，特別是跨多個站點或雲端託管 RADIUS 伺服器的環境，請使用 RadSec（基於 TLS 的 RADIUS，定義於 RFC 6614）或 IPsec 隧道來保護傳輸中的計費資料。對於處理持卡人資料的任何網路，這是 PCI DSS 4.0 的要求。

監控計費佇列。 若 RADIUS 伺服器無法連線，NAS 裝置會將計費封包暫存於本機佇列。監控此佇列長度；佇列滿載將導致封包遺失，並喪失稽核資料。請對佇列深度設定警報，並為高可用性部署實作次要計費伺服器。

大規模環境中分離驗證與計費伺服器。 在超過 5,000 個同時上線使用者的部署中，計費的寫入負載可能會降低驗證的回應時間。使用獨立的伺服器執行個體與資料庫實例的專用計費伺服器，可避免此資源競爭。

故障排除與風險緩解

過時會話問題

症狀：RADIUS 資料庫顯示某位使用者已連線 48 小時，但場館夜間已關閉。

根本原因：NAS 未能發送停止封包——通常是電源故障、AP 重新啟動或網路中斷所致——且該封包從未被 RADIUS 伺服器接收。

緩解措施：在 RADIUS 伺服器上實作過時會話清除指令碼。該指令碼應定期掃描活躍會話，其中最後接收封包（開始或臨時更新）的時間早於定義的閾值（例如，臨時更新間隔的 2.5 倍）。超過此閾值的會話應強制關閉，並產生一個合成的停止記錄，終止原因註記為「Lost-Carrier」或「Admin-Reset」。

RADIUS 伺服器 CPU 與 I/O 負載過高

症狀：尖峰時段驗證回應時間惡化；RADIUS 伺服器回報高 CPU 與磁碟 I/O。

根本原因：跨數千台 AP 的過度頻繁臨時更新間隔（例如 1 分鐘），產生了難以承受的資料庫寫入量。

緩解措施：將臨時更新間隔增加至 15 分鐘。確認計費資料庫已建立適當的索引。考慮將驗證與計費功能分離至獨立的伺服器執行個體。評估時序資料庫（例如 InfluxDB）是否比關聯式資料庫更適合處理高容量的計費資料。

計費記錄中缺少 Framed-IP-Address

症狀：存在 RADIUS 計費記錄，但 Framed-IP-Address 欄位為空白或不存在，導致無法進行 IP 與 MAC 的關聯。

根本原因：NAS 可能在 DHCP 尚未指派 IP 位址給客戶端之前，就發送了開始封包。IP 位址僅在 DHCP 交換完成後才可用。

緩解措施：若平台支援，請設定 NAS 延遲發送開始封包，直到 DHCP 指派完成。另一種方式是依賴臨時更新封包，這些封包在 DHCP 指派後發送，且會包含 Framed-IP-Address。請確保您的稽核查詢能處理此情況，若開始記錄缺少 IP，則檢查臨時更新記錄。

ROI 與商業影響

實作完善的 RADIUS 計費功能，可在三個面向帶來可衡量的商業價值：

合規性與法律風險緩解。 在發生安全事件、收到根據 GDPR 提出的資料主體存取要求，或接獲合法攔截命令時，準確的計費記錄能提供必要的稽核軌跡，以識別在特定時間持有特定 IP 位址的使用者或裝置。若缺乏此功能，組織將面臨 GDP3 下的潛在監管罰款（最高可達全球年營業額的 4%）與聲譽損害。導入適當計費基礎架構的成本，僅是一次監管執法行動成本的極小部分。

容量規劃與基礎架構 ROI。 透過分析 Acct-Input-Octets 與 Acct-Output-Octets 的長期趨勢，網路架構師可識別頻寬消耗模式、尖峰用量時段，以及驅動最高負載的特定 AP 或 SSID。這些資料能直接影響 WAN 升級決策與 AP 佈署策略，確保基礎架構投資能導向最具影響力的地方。對於 交通運輸 樞紐與大型場館而言，這可能代表顯著的資本支出節省。

增強分析與場域智慧。 當 RADIUS 會話資料與 Purple 的 WiFi Analytics 及 Sensors 等平台結合時，原始的計費資料便轉化為場域智慧。從會話持續時間推導出的停留時間指標、從 Calling-Station-Id 歷史記錄識別的重複訪客，以及從並行會話數分析得出的尖峰佔用率，全都變得唾手可得。對於 餐旅業 營運商而言，這類資料能直接影響人力配置模型、餐飲配置與行銷個人化策略。關於 WiFi 基礎架構如何支撐這些功能的進一步脈絡，請參閱我們關於 無線存取點 與 現代餐旅 WiFi 解決方案 的指南。