RADIUS Server 高可用性：Active-Active 與 Active-Passive 的比較

# RADIUS Server High Availability: Active-Active vs Active-Passive ## Purple Technical Briefing — Podcast Script (~10 minutes) --- **PART 1 — INTRODUCTION & CONTEXT (approx. 1 minute)** 歡迎收聽 Purple Technical Briefing。我是您的主持人，今天我們要探討對於任何運行企業級 WiFi 的組織來說，最重大的基礎架構決策之一：RADIUS 伺服器高可用性（High Availability）。 如果您是負責飯店集團、零售連鎖店、體育場或公共部門設施驗證基礎架構的網路架構師或 IT 總監，本次簡報將為您提供做出正確決策所需的框架和具體技術細節，並避免在最糟糕的時刻導致驗證中斷的錯誤。 讓我來為您說明背景。RADIUS（遠端使用者撥入驗證服務）是您網路的守門人。每當員工透過 802.1X 連線，或者訪客透過您的 Captive Portal 進行驗證時，RADIUS 就是檢查憑證並授權存取的引擎。它是 IEEE 802.1X 和 WPA3 企業級部署的骨幹。與大多數在故障時會優雅降級的 IT 服務不同，RADIUS 是二分法的：它要麼正常運作，要麼就沒有人能連上網路。這種不對稱性正是高可用性如此關鍵的原因。 --- **PART 2 — TECHNICAL DEEP-DIVE (approx. 5 minutes)** 讓我們從基本原理開始。RADIUS 在 UDP 上運行 — 通常驗證使用連接埠 1812，計費使用連接埠 1813。UDP 的無狀態特性實際上是 HA 設計的一個優勢：因為每個驗證請求都是獨立的，叢集中的任何伺服器都可以處理任何請求，而無需知道之前發生了什麼。這正是讓主動-主動（Active-Active）部署如此優雅的架構特性。 現在，您需要了解兩種主要的高可用性模型。 **主動-被動（Active-Passive）**是傳統的方法。您有一個主 RADIUS 伺服器處理所有驗證流量，以及一個處於待命狀態的備用伺服器，接收複製的資料但不處理請求。當主伺服器發生故障時，網路存取裝置（NAS）— 您的存取點（AP）、交換器、VPN 閘道器 — 會偵測到故障並將流量重導向到備用伺服器。 該容錯移轉（Failover）需要多長時間？這就是細節決定成敗的地方。NAS 發送 RADIUS 請求並等待。預設的封包逾時通常是兩秒。之後，它會重試 — 通常每台伺服器嘗試三次。在配置了兩台伺服器的情況下，在經過良好調校的部署中，最大容錯移轉偵測時間大約在六到十二秒之間。在配置了三台伺服器且使用預設計時器的最壞情況下，這可能會延長到十八秒。對於試圖在辦理入住時連線的飯店訪客，或試圖處理交易的零售店員來說，這是一段令人痛苦的等待窗口。 **Active-Active**（雙活動）是更為先進的方法，且對大多數企業級部署而言是正確的選擇。兩台（或所有）RADIUS 伺服器會同時處理驗證請求。流量會透過輪詢（round-robin）循環或專用負載平衡器分發到整個叢集。當其中一個節點故障時，其餘節點會立即吸收其流量。這不會有容錯移轉的偵測延遲，因為這並非傳統意義上的容錯移轉：負載平衡器只會停止向異常節點發送請求，根據健康檢查間隔，這通常在一到兩秒內完成。 其效能優勢是加乘的。在大型場館中（例如擁有 60,000 個座位的體育場或舉辦大型展覽的會議中心），當大門開啟或會議休息時，您會看到數千個同時進行的驗證請求。單一 RADIUS 伺服器（即使是配置良好的伺服器）也可能成為瓶頸。Active-Active 叢集可進行水平擴充：增加另一個節點，即可按比例增加容量。 現在，讓我們來談談資料庫層，因為這是許多部署遇到問題的地方。RADIUS 驗證本身在很大程度上是無狀態的——伺服器根據目錄檢查憑證並傳回 Accept（接受）或 Reject（拒絕）。但 RADIUS 計費（accounting）是有狀態的：它會追蹤工作階段開始、過渡更新和工作階段停止事件。如果您將計費功能用於帳務、合規性記錄或工作階段管理，則需要該資料在所有節點上保持一致。 標準方法是使用複製資料庫來支援您的 RADIUS 叢集。FreeRADIUS 是全球部署最廣泛的開源 RADIUS 伺服器，它與 MySQL 和 MariaDB 整合。對於 Active-Active 部署，您有兩個主要選擇：MySQL NDB Cluster（提供同步多主機複製，具備亞秒級容錯移轉）或 Galera Cluster（提供類似的同步複製，且維運管理稍微簡單一些）。兩者都能消除節點故障時資料遺失的風險。非同步複製（標準 MySQL 主從複製）成本較低，但會引入複製延遲，如果主節點在變更複製之前故障，可能會導致計費記錄遺失。 讓我來探討地理分佈的問題，因為這對於多據點營運商來說越來越重要。如果您經營一家擁有 200 家分店的零售連鎖店，或是一家在多個國家擁有物業的飯店集團，問題不僅僅是「我該如何讓我的 RADIUS 伺服器具備備援能力？」——而是「相對於我的存取點，我的 RADIUS 伺服器應該部署在哪裡？」 將驗證流量從遠端站點回傳到中央資料中心會引入 WAN 延遲，並在 WAN 鏈路上產生單一故障點。如果該鏈路中斷，無論您的中央 RADIUS 叢集有多麼冗餘，遠端站點都無法驗證任何人。解決方案是在每個站點部署本地 RADIUS 執行個體（這會產生巨大的營運開銷），或者使用具有地理分佈式邊緣節點的雲端 RADIUS 服務。 雲端 RADIUS 平台在架構層面解決了高可用性（HA）問題。供應商在多個可用區域和地區營運 RADIUS，無需您建立和管理冗餘基礎設施。節點之間的容錯移轉會自動發生，通常在不到一秒的時間內完成，因為它是由平台的內部負載平衡處理，而不是由 NAS 重試計時器處理。企業級雲端 RADIUS 供應商的 SLA 承諾通常為 99.99% 的可用性——這相當於每年不到 53 分鐘的停機時間。 這裡還有一個重要的合規維度。PCI DSS 要求對持卡人資料環境進行強式驗證控制。GDPR 將驗證記錄視為個人資料，需要適當的處理和資料落地控制。雲端 RADIUS 供應商通常持有 SOC 2 Type II 認證，並提供具有區域資料落地選項的 GDPR 資料處理協議。地端部署則讓您能完全控制資料位置，這在 NHS 資料治理框架下的醫療保健環境，或具有資料主權要求的政府設施中至關重要。 --- **第 3 部分 — 實作建議與常見陷阱（約 2 分鐘）** 讓我帶您了解兩個在實踐中說明這些原則的真實案例。 第一：一家在六個國家擁有 45 家物業的歐洲酒店集團。他們由三名工程師組成的 IT 團隊在每個物業的虛擬機器上執行 FreeRADIUS——共有 45 個獨立的執行個體需要修補、監控和維護。當某個物業的 TLS 憑證過期時，導致了一場大型會議期間的訪客 WiFi 完全中斷。修復工作需要工程師遠端登入並手動更新憑證——在訪客無法連線的情況下，這個過程花費了 40 分鐘。 在遷移到具有集中式策略管理的雲端 RADIUS 服務後，該團隊完全消除了每個站點的維護工作。憑證輪替變成了自動化。這三名工程師收回了先前花在 RADIUS 營運上大約 40% 的時間。更重要的是，該平台跨多個雲端區域的主動-主動（active-active）架構意味著，單一節點故障（以前會導致站點中斷）變得無足輕重。 第二種情境：容納 60,000 名球迷舉辦大型賽事的國家體育場。網路團隊部署了主動-被動（active-passive）的 RADIUS 配置，包含一台主伺服器和一台熱備份伺服器。在活動前的壓力測試中，他們發現當閘門開放、驗證需求激增時，主伺服器達到了飽和狀態——每分鐘處理 8,000 次驗證請求。當主伺服器苦苦支撐時，被動的次要伺服器卻處於閒置狀態。 解決方案是重新配置 NAS 設備，在兩台伺服器之間使用輪詢（round-robin）負載平衡，有效地將部署轉換為主動-主動（active-active）模式。驗證吞吐量立即翻倍。他們還增加了第三台伺服器以提供因應尖峰負載的緩衝空間，並為計費資料庫配置了 Galera Cluster 複製。最終的部署結果是，即使失去任何單一節點，也不會對使用者造成任何可察覺的影響。 現在來談談陷阱。最常見的錯誤是將次要 RADIUS 伺服器視為「設定後即忘」的備份。配置會產生偏差。當主伺服器運行正常時，次要伺服器上的憑證可能已經過期。當主伺服器最終故障且次要伺服器接管時，它也會因為完全不同的原因而失敗。解決方法很簡單：定期（至少每季）測試您的容錯移轉，並將這兩個節點都視為生產系統。 第二個陷阱是忽略了資料庫複製的延遲。如果您使用的是非同步複製，且您的主資料庫節點發生故障，您可能會遺失在故障發生時處於作用狀態的會話計費記錄。對於 PCI DSS 合規性而言，這是一個嚴重的漏洞。對於任何將計費資料完整性視為合規要求的部署，請使用同步複製（Galera 或 NDB）。 --- **第四部分 — 快速問答（約 1 分鐘）** 讓我來解答我最常從網路架構師那裡聽到的問題。 「什麼是最小可行的高可用性（HA）配置？」兩台具有主動-被動容錯移轉、共享金鑰同步和複製資料庫後端的 RADIUS 伺服器。這是您的底線。對於 500 個以上同時上線的使用者，請改用主動-主動模式。 「我可以使用硬體負載平衡器來處理 RADIUS 嗎？」可以，但 RADIUS 使用 UDP，而許多負載平衡器是針對 TCP 進行優化的。請確保您的負載平衡器支援具有健康檢查的 UDP 負載平衡。HAProxy Enterprise 擁有專用的 RADIUS UDP 模組。F5 BIG-IP 則原生支援此功能。 「在 HA 叢集中，我該如何處理 EAP 憑證信任？」所有節點必須呈現相同的伺服器憑證，或者至少呈現來自相同 CA 鏈的憑證。用戶端在 EAP-TLS 和 PEAP 握手期間會驗證伺服器憑證——如果節點呈現不同的憑證，您將在容錯移轉後看到驗證失敗。 「雲端 RADIUS 可以與地端的 Active Directory 搭配使用嗎？」可以，透過輕量級連接器或 LDAP 代理程式來查詢您的本地 AD，而無需將其直接暴露給網際網路。這是混合式環境的標準整合模式。 --- **第 5 部分 — 總結與後續步驟（約 1 分鐘）** 讓我以您需要做出的關鍵決策來做結尾。 如果您的單一場地同時在線用戶少於 500 人，且有穩定的團隊來管理基礎設施，那麼採用經過嚴格測試的容錯移轉程序的「主動-被動」（active-passive）架構是一個合理的選擇。保持簡單、定期測試，並使用同步資料庫複製。 如果您營運的是多場地物業、高密度場館，或者您團隊的頻寬受限，那麼「主動-主動」（active-active）就是正確的架構 — 而雲端 RADIUS 是無需自行建置基礎設施即可實現此目標的最快路徑。 無論您選擇哪種模式，原則都是相同的：分散而非複製、自動化容錯移轉決策，並在故障場景考驗您之前先對其進行測試。 欲了解更多關於 Purple 的平台如何大規模處理 RADIUS 驗證（包括與 802.1X、WPA3 企業版和訪客 WiFi 門戶的整合）的資訊，請造訪 purple.ai。我們下次見。 --- *腳本結束。以每分鐘 150 字的速讀時間計算：約 10 分鐘。*