如何一步步測試 RADIUS 驗證
Published
您正身處某個據點，手邊有一台筆記型電腦、一個存取點，以及一台「應該已經沒問題」的 RADIUS 伺服器。有人對它執行過 ping。UDP 1812 已開啟。儀表板探針甚至顯示綠燈。但這些都無法告訴您員工裝置是否能順利連上員工 VLAN，或是已撤銷的憑證是否仍可取得工作階段。
如何測試 RADIUS 驗證是一連串的驗證過程，而不是單次登入。請將每個 Access-Accept 都視為一個假設。您仍須檢查驗證方式、屬性、來源位址，以及當伺服器、目錄或憑證出錯時，網路會如何反應。
從一個受控請求開始。接著擴大測試案例，讓虛假通過無所遁形。
目錄
- 使用 radtest 發送您的第一個測試
- 為什麼 Access-Accept 不代表已具備網路存取權限
- 每個 RADIUS 部署都需要測試案例
- 使用 radclient 測量負載與延遲
- 失敗路徑、故障轉移與安全性檢查
- 檢視日誌以確認每個測試結果
- 決定 RADIUS 何時準備好進行推廣部署
使用 radtest 傳送您的第一個測試
您可以在接下來五分鐘內執行的命令是 radtest testing password 127.0.0.1 0 testing123。FreeRADIUS radtest 手冊 將其定義為具有五個輸入項目的受控 Access-Request：使用者名稱、密碼、伺服器位址、NAS-Port 以及共用金鑰。PAP 為預設值。同一個公用程式也可以傳送 CHAP、MS-CHAP 或 EAP-MD5。
在變更任何其他內容之前執行基準測試
- 定義測試帳號。 在伺服器可存取之處設定已知的使用者名稱與密碼。您會需要一組無需在目錄中搜尋即可直接輸入的憑證。
- 列出用戶端。 您傳送要求的來源主機或 NAS 必須存在於
clients.conf中，並搭配您將輸入的金鑰。未知的來源與密碼錯誤屬於不同的失敗情況。 - 以偵錯模式啟動伺服器。 每個封包與拒絕原因都應列印在終端機上。無預警的失敗會浪費測試過程。
- 傳送五個輸入值。 使用者名稱、密碼、伺服器、NAS-Port、金鑰。對於第一次驗證，NAS-Port 設定為
0就足夠了。 - 先檢視代碼，再檢視原因。 Access-Accept 表示伺服器已核准該憑證。Access-Reject 表示伺服器已拒絕。偵錯輸出會區分不正確的共享金鑰、未知的用戶端、無效的憑證以及策略失敗。
- 從 NAS 重複執行。 從無線基地台或交換器位址傳送相同的請求，而非僅從 localhost。用戶端通常是由來源位址與共享金鑰共同授權。
可達性並不代表最終結果。封包必須順利送達，而且授權決定必須符合您的預期。收到接受回應時，請檢視傳回的屬性，例如 VLAN、服務類型或框架位址。即使代碼看起來沒有問題，但指定了錯誤 VLAN 的接受回應依然算未通過。
在完成基本的接受回應後，同一份手冊列出了適用於範例帳號的八種方法：PAP、CHAP、MS-CHAPv1、MS-CHAPv2、PEAP、EAP-TTLS、EAP-GTC 與 EAP-MD5。今天不需要追求全部八種。
實用規則： 儲存一份來自真實 NAS 位址的 Access-Accept，以及一份來自錯誤密碼的 Access-Reject。這兩份筆記是評估日後所有案例的基準。
為何 Access-Accept 不代表網路存取無虞
綠色的基礎架構測試是我不會簽核的虛假通過。它通常只代表某些請求獲得了某些回覆。
Meraki RADIUS 疑難排解指南 指出，其儀表板測試使用的是搭配 MS-CHAPv2 的 PEAP。該測試針對 EAP-TLS 會失敗或無法提供任何有意義的驗證，因為無線存取點沒有用戶端憑證。憑證無線網路必須使用擁有正確憑證與信任鏈的真實 supplicant 進行測試。
四個層級，四個不同的問題
傳輸確認是否有任何回應。逾時並不等於拒絕。
身分驗證旨在確認密碼或憑證對該身分是否有效。
授權旨在確認回覆是否包含您打算傳送的 VLAN、角色或 ACL。
可達性 會詢問端點是否取得預期的位址、DNS 策略，以及對該網段應允許之資源的存取權限。
某個層級通過驗證，並不代表其他三個層級就沒問題。參照 FreeRADIUS EAP 的運作行為，相同的 Meraki 指引將成功的 EAP-TLS 測試描述為包含多封包的 Access-Request 與 Access-Challenge 交換，接著才是真實用戶端的網路存取。單一連線探針並不等於該項測試。
請檢查 supplicant 信任的伺服器名稱、CA 鏈、憑證到期日以及裝置時鐘。時鐘偏移會導致合規的憑證驗證失敗。假設員工筆記型電腦完成驗證，卻停留在預設的 VLAN 而非員工區段。Accept 是真實的，但網路配置錯誤。這是大多數檢查清單從未記錄到的遺漏。
請為密碼使用者、EAP-TLS 裝置、xPSK 身分及目錄導向原則保留單獨的資料列。PAP 接受絕不能替代憑證加入。
在備用裝置上驗證 EAP-TLS
- 從伺服器信任的同一 CA 核發測試用戶端憑證。
- 將憑證與 CA 鏈安裝在備用的筆記型電腦或手機上。
- 確認 supplicant 已驗證您設定的伺服器名稱。
- 連線並擷取挑戰交換過程，而非單一封包偵測。
- 確認工作階段以真實的網路存取在預期的 VLAN 上結束。
當您自身的追蹤訊號較雜亂時，快速檢視該交換過程能讓封包擷取更容易辨識。
每個 RADIUS 部署都需要測試案例
有效的憑證可能會產生 Access-Accept，但使用者卻連線至錯誤的網路。請單獨測試每個層級：要求處理、驗證、授權屬性以及終端節點的實際存取權限。FreeRADIUS 效能測試指南 涵蓋了負載與正確性測試。同時也要包含反向案例：無效的憑證應傳回 Access-Reject，而格式錯誤的要求、未識別的 NAS 以及不正確的共用金鑰則絕不能產生成功的登入結果。
radtest 工作流程由來已久，至今仍使用相同的五項輸入。對於隧道化方法，請在 UDP 連接埠 18120 上單獨測試內部驗證伺服器。當 PEAP 為外部方法時，請使用 MS-CHAP 內部測試。這有助於釐清失敗是出現在外部 EAP 交換、憑證或 TLS 設定，還是內部憑證檢查中。
Access-Accept 是需要驗證的假設，而非網路存取正確的證明。FreeRADIUS 實作指南 說明了 NAS 如何捨棄不支援的 VLAN 屬性，或將缺失的屬性對映至預設的 VLAN。請檢查回傳的屬性，然後驗證端點的位址、VLAN、ACL、DNS 策略與可達性。EAP-MD5 無法提供無線網路所需的金鑰材料，因此 EAP-MD5 的接受回應並不能作為無線網路就緒的依據。請僅將其用於有限度的有線網路測試。
在執行授權測試前先決定預期的網段；WiFi 存取控制 說明了如何構建該策略。
算作最低要求的九個資料列
| 測試案例 | 執行方式 | 預期結果 |
|---|---|---|
| 基準接受 | 從 NAS IP 使用有效的測試帳號執行 radtest |
帶有預期 VLAN 屬性的 Access-Accept；確認端點進入該 VLAN |
| 密碼錯誤 | 使用不正確的密碼執行 radtest |
Access-Reject 並包含記錄的原因 |
| 共享金鑰錯誤 | 從設定了不相符金鑰的用戶端傳送 | 無 Access-Accept；金鑰錯誤會在偵錯輸出中顯示 |
| 未知的 NAS | 從未定義為用戶端的 IP 位址傳送 | 已丟棄或拒絕並記錄 |
| 有效的 EAP-TLS 裝置 | 連線具有有效憑證和受信任鏈的真實請求者 (supplicant) | Access-Accept 以及為其群組指定的正確 VLAN；確認來自裝置的網路存取 |
| 憑證過期或已撤銷 | 連線帶有過期或撤銷憑證的裝置 | Access-Reject，且不會後退回復至預設網路 |
| 目錄群組變更 | 將測試使用者移至另一個群組，然後重新驗證 | VLAN 或角色變更以符合新群組，或者拒絕存取 |
| 主伺服器不可用 | 阻擋至主伺服器的 UDP 1812 或停止主伺服器 | 在逾時時間內故障轉移至備用伺服器，並套用相同的策略 |
| 計費開始與停止 | 開始一個會話 (session)，然後結束它 | 開始與停止記錄與該會話相符 |
針對每一列，記錄請求送達時間、回應代碼、往返延遲、所選取的策略、傳回的屬性，以及計費的開始與停止。請重複執行每項測試，以擷取間歇性的 UDP 遺失。單次乾淨的執行可能會漏掉錯誤的 VLAN 或不一致的策略決策。
若接受請求卻將用戶端放置在錯誤的網路上，這屬於測試失敗。
使用 radclient 測量負載與延遲時間
沒有警報的接受回覆隱藏了佇列排隊問題。容量測試需要專為批次建立的工具，而不是另一次單一登入。
- 建立隨機使用者名稱與密碼的驗證檔案。將有效與無效的項目混合，以便計算拒絕次數，而非視為雜訊。
- 傳送檔案並計算整批處理的時間，在由
radclient驅動伺服器時，使用 Unix 的time指令。 - 記錄原始統計數。總請求數、接受數、拒絕數、超時、錯誤回應以及經過時間。
- 計算比率。接受率應符合檔案的有效比例。拒絕率應符合無效比例。同時取得平均延遲與百分位數延遲。
- 在繁忙時段重複測試。早晨報到或學校開課時段會顯示出午餐時間實驗室測試所無法顯現的排隊情況。
| 指標 | 計算方式 | 目標 |
|---|---|---|
| 總請求數 | 從驗證檔案傳送的行數統計 | 等於檔案長度 |
| 接受率 | 接受數除以總請求數 | 符合檔案的有效比例 |
| 拒絕率 | 拒絕數除以總請求數 | 符合檔案的無效比例 |
| 超時與錯誤 | 執行期間無回應與錯誤回應的統計數 | 正常路徑下為零 |
| 平均延遲 | 所有請求的平均回應時間 | 在尖峰時段維持在您的延遲目標內 |
| 經過時間 | 整批處理的 Unix 時間輸出 | 重複執行時保持穩定 |
將通道與帳戶儲存庫分開
如果接受率低於有效份額，在確認哪一半失敗之前，請勿歸咎於「負載」。對於 PEAP，請針對內部伺服器發送 MS-CHAP 請求，單獨測試內部方法。內部接受但外部加入中斷，指向憑證或 TLS 設定問題。若外部握手在內部檢查時中止，則指向帳號儲存庫、密碼雜湊或原則預期的群組。
請將這些時間記錄在與功能結果相同的記錄中。日後的韌體或目錄變更應與該基準進行比較，而不是憑感覺認為「好像變慢了」。
如果逾時僅在尖峰時段增加，請在新增據點之前先修復容量或路徑。正確但速度慢的伺服器，仍然會使先放棄連線的用戶端連線失敗。
失敗路徑、故障轉移與安全性檢查
運作正常的交換仍可能不安全。僅詢問 UDP 1812 是否收到回覆的疑難排解太早停止了。
Juniper 的 2025 年安全性公告 說明了 RFC 2865 Response Authenticator 中的 Blast-RADIUS 風險暴露。能夠修改流量的本機攻擊者，有可能透過 MD5 選擇前綴碰撞（chosen-prefix collision）將有效回應轉變成另一種回應。「驗證成功」並不代表部署已受到保護。
應與故障轉移在同一次執行中進行的檢查
在平台允許之處保護路徑。 確認已阻擋路徑上的篡改行為，且對需要封包的案件實施 Message-Authenticator 驗證。
關閉安全性較弱的方式。 應停用已過時的 EAP 類型，而不是留著「以防萬一」。如果您仍在使用憑證與密碼外層方式之間進行選擇，請在同時啟用兩者之前，先在 EAP-TLS 與 PEAP 中進行比較。
故意使伺服器失效。 下方的每個情境都應該顯示預期的關閉式失敗 (fail-closed) 或受控的備援機制，外加一行記錄、一個警報，以及您可以向現場主管解釋的使用者體驗。
| 失敗情境 | 如何觸發 | 通過條件 |
|---|---|---|
| 逾時 | 阻擋 UDP 1812 至伺服器的連線 | 關閉失敗（Fail closed）或受控後退（controlled fallback），並予以記錄和警報 |
| Access-Reject | 使用錯誤密碼 | 拒絕存取且無後退網路 |
| 憑證過期 | 憑證已過期的裝置 | Access-Reject 且無預設 VLAN |
| 憑證已撤銷 | 憑證已撤銷的裝置 | Access-Reject 且無預設 VLAN |
| 未知的 NAS 來源 IP | 從未定義的位址發送 | 丟棄或拒絕，並予以記錄 |
| 共享金鑰不正確 | 用戶端上的金鑰不符合 | 無 Access-Accept 且除錯輸出中顯示金鑰錯誤 |
| 無法連線至目錄 | 停止目錄連線性 | 根據原則拒絕或受控後退 |
| 授權回應延遲 | 增加授權回覆的延遲 | 處理逾時且未開放存取 |
跨區故障轉移必須保留的項目
由另一台伺服器進行回應並不代表策略保持一致。當您停止主要伺服器時，請比較備份伺服器與主要伺服器的 VLAN、頻寬限制、撤銷狀態以及稽核屬性。即使連線速度很快，但如果訪客容錯移轉至員工網段，這依然是一次失敗的測試。
無論使用者是否上網，只要會備援至開放存取的情境，請一律標記為失敗。將每個結果寫入與功能基準相同的測試記錄中，這樣日後的容錯移轉變更就會一目瞭然。
讀取日誌以確認每項測試結果
每項測試都應留下可與測試 ID 或已知帳號比對的追蹤紀錄。在繁忙的資產環境中，該標籤是您無須捲動瀏覽其他人早晨活動即可找到自己執行紀錄的方法。
針對每次驗證，對齊以下欄位：
- 身分與裝置：加入的對象或裝置，而不只是您希望屬於您的 MAC 位址。
- 方法： EAP-TLS、PEAP，或個別 PSK。未部署的方法即屬稽核發現。
- 地點：無線基地台、SSID及站點。
- 決策： VLAN 與返回的角色，或拒絕原因。
- 時間：位於您測試時間範圍內的時間戳記。
我們的驗證記錄就是為了滿足這種需求而建立的。單一的全園區查詢即可顯示每一次接受與拒絕，包括身份、裝置、註冊狀態、方式、存取點、SSID、據點、VLAN、角色、原因和時間戳記。當某個據點有多個存取點，且您需要確認相同的失敗是發生在所有地方，還是僅發生在單一控制器上時，即可使用此功能。
代表紀錄有誤的三種模式
原因與測試不符。 您傳送了錯誤的密碼，但記錄顯示未知的用戶端。您測試了錯誤的項目，或者有兩個錯誤重疊了。
接受回覆指定了預設的 VLAN。 憑證有效，但套用位置不對。請勿關閉案子。
記帳（Accounting）已啟動但從未停止。連線階段紀錄不完整，因此您無法證明用戶端是否在您預期的時間離線。請將啟動與停止時間與您執行的連線階段進行比較，而不是與附近使用者的連線階段比較。
請在測試期間針對拒絕次數暴增設定警報，這樣錯誤的共用金鑰就不會看起來像「使用者輸入錯誤」。請將記錄擷取內容與測試筆記一起保留。當數週後有人詢問您證明了什麼時，該擷取內容就是稽核證據。
判定 RADIUS 何時準備好推廣部署
僅在證據符合五道關卡時才上線。工程師的自信並不包含在內。
- 您部署的每種 NAS 類型皆通過矩陣中的每一行測試，包括您打算保留的每個 SSID 或存取策略。
- 容錯移轉保持與主要伺服器相同的 VLAN、策略與撤銷行為。以不同角色回應的次要伺服器將無法通過此關卡。
- 沒有任何失敗情境會變成預設開放。密碼錯誤、目錄失效、憑證過期以及延遲回應，絕不能讓使用者進入未受限的網路。
- 負載在尖峰時段保持在您的延遲目標內，且接受率符合測試檔案的有效比例。
- 日誌針對您宣稱為通過的每一次執行，顯示預期的原因與 VLAN。
暫緩大規模推廣，直到這五項在真實案場都成立為止，而不是僅在實驗室中成立 VLAN。
我們讓您能先在單一站點上證明這一點。將新的開放、安全及 xPSK 網路部署至該站點現有的無線基地台上，並與其目前使用的網路並列，在對其他站點進行任何變更前，根據工單與稽核證據評估結果。在該試點期間，記錄應能在無需開會的情況下回答兩個問題：哪些裝置透過哪些 VLAN 加入，以及哪種接受或拒絕原因最常出現。
僅在工單和稽核擷取資料顯示沒有異常拒絕且無裝置位於錯誤網段時，才進行擴充。將矩陣保持為常設的迴歸測試套件。在每次憑證更新、韌體升級或目錄變更後，且在使用者看到變更之前，針對相同的基準重新執行測試。關於該試點場景應如何規劃，請參考 WiFi 網路設計，並測試您打算長期保留的設計，而非下週就會刪除的臨時 SSID。
Purple Access 為您提供雲端 RADIUS，可根據身分將各個裝置分配至開放、安全或 xPSK 網路，並能在驗證記錄中檢視 VLAN 與拒絕原因。若您希望針對現有的無線基地台執行該測試計畫，可先從單一站點開始，並在進一步推廣前檢視結果。請造訪 Purple Access，將第一個站點建立在可捍衛的基準上。
