- Purple
- Enterprise WiFi security and authentication: a complete guide
- Passpoint and OpenRoaming: 完整指南
Passpoint and OpenRoaming: 完整指南
本技術參考指南針對企業 WiFi 網路中的 Passpoint (Hotspot 2.0) 與 WBA OpenRoaming 架構提供全面分析。內容詳述了建立安全、無摩擦訪客連線所需的底層驗證協定、架構組件及部署策略。網路架構師與 IT 主管將學習如何設計、實作這些標準並進行疑難排解,以便在維持企業級安全性的同時,消除手動登入的障礙。
Video overview
核心系列的一部分:企業 WiFi 安全指南 →

執行摘要
企業連線需求已從手動、基於 Captive Portal 的訪客存取,轉變為自動、安全且無摩擦的配置。Passpoint(由 WiFi 聯盟定義為 Hotspot 2.0)與 OpenRoaming(由無線寬頻聯盟協調)代表了這一轉變的標準化。藉由利用 IEEE 802.11u 協定與 WPA3-Enterprise 安全性,這些技術允許行動裝置在無需使用者介入的情況下,自動發現、驗證並連線到安全的 WiFi 網路。
本指南旨在為計劃在大型場館、零售環境和企業園區部署這些技術的網路架構師和 IT 主管提供權威參考。我們將探討底層的密碼學握手、聯盟架構,以及將這些標準整合到現有無線基礎架構中所需的實際設定步驟。藉由採用這些框架,企業可以消除傳統訪客入口網站的摩擦,同時顯著增強其無線安全狀況。
技術深度剖析
要理解 Passpoint 與 OpenRoaming,必須先剖析主導其運作的底層協定。Passpoint 的核心是 IEEE 802.11u,這是 802.11 標準的修正案,使無線裝置能夠在建立關聯之前發現網路服務。
在過去,用戶端裝置必須先與存取點(AP)建立關聯並取得 IP 位址,然後才能查詢網路功能。透過 802.11u,此發現過程在關聯前狀態即可使用存取網路查詢協定(ANQP)查詢來進行。
802.11u 發現過程
當啟用 Passpoint 的裝置掃描無線電波時,它會偵測到包含 Interworking 元素的信標(beacon)。此元素表示該 AP 支援 802.11u,並宣傳其網路類型(例如:私有、免費公開、收費公開)。接著,用戶端裝置會發送 ANQP 查詢以請求特定的參數,例如:
- 漫遊聯盟組織識別碼 (OIs): 由 IEEE 分配、代表特定漫遊合作夥伴或聯盟的全球唯一識別碼。
- 場館名稱與場館群組: 描述物理位置的元數據(例如 "Terminal 2" 或 "Stadium")。
- 可用 IP 位址類型: 關於 IPv4 或 IPv6 是否可用以及是否套用 NAT 的資訊。
如果用戶端裝置擁有包含比對成功之漫遊聯盟 OI 的設定檔,它就會啟動驗證程序,而不會提示使用者。
OpenRoaming 聯盟架構
OpenRoaming 作為 Passpoint 之上的全域聯盟層。它建立了由無線寬頻聯盟 (WBA) 管理的安全公開金鑰基礎建設 (PKI)。此聯盟允許身分驗證提供者 (IDP) - 例如行動網路業者、裝置製造商 (Apple, Google) 以及企業身分驗證系統 - 與網路提供者進行安全對等互連。
驗證是使用 WPA3-Enterprise (或用於舊版相容性的 WPA2-Enterprise),並搭配受保護的延伸驗證協定 (PEAP) 或延伸驗證協定 - 傳輸層安全 (EAP-TLS) 來執行。AP 作為驗證者,將 EAP 封包封裝至 RADIUS (遠端使用者撥入驗證服務) 或 RadSec (透過 TLS 的 RADIUS) 封包中,並將其轉發給身分驗證提供者。
RadSec 在 OpenRoaming 中是強制性的,用以確保本機網路的 RADIUS 代理伺服器與公用網際網路上的全域 IDP 之間的通訊安全。RadSec 使用 TCP 連接埠 2083 和 TLS 加密,確保使用者憑證和驗證屬性在經由中間傳輸提供者傳輸期間保持機密。
實作指南
部署 Passpoint 和 OpenRoaming 需要在無線控制器 (WLC)、RADIUS 基礎建設以及 DNS/防火牆設定之間採取系統化的方法。
步驟 1:網路基礎建設稽核
確保您的 AP 和 WLC 支援 802.11u 和 Passpoint 版本 2 或 3。驗證您的 RADIUS 伺服器是否支援 RadSec (RFC 6614)。如果您的舊版 RADIUS 伺服器不支援 RadSec,您必須在 DMZ 中部署 RadSec 代理伺服器 (例如 FreeRADIUS 或專用閘道器)。
步驟 2:防火牆設定
向 OpenRoaming RadSec 代理伺服器開放輸出 TCP 連接埠 2083。確保在您的 RADIUS 伺服器上正確設定 DNS 解析,因為 RadSec 依賴動態委派搜尋系統 (DDDS) 和 NAPTR 記錄來尋找適當的 IDP。
步驟 3:憑證取得
從授權的憑證授權單位 (CA) 取得經 WBA 核准的 RadSec 憑證。此憑證對於您的本機 RadSec 代理伺服器與 OpenRoaming 聯盟代理商之間的雙向 TLS (mTLS) 驗證至關重要。
步驟 4:無線控制器設定
- 建立安全 SSID: 設定新的 SSID 或修改現有的 SSID 以使用 WPA3-Enterprise (或 WPA2/WPA3 轉換模式)。
- 啟用 802.11u (互連): 在 SSID 上啟用互連 (Interworking) 功能。
- 設定 HESSID: 設定同質 ESSID (通常是其中一個 AP 無線電的 MAC 位址),以唯一識別網路群組。
- 新增漫遊聯盟 OI: 新增 OpenRoaming 漫遊聯盟 OI。標準 OI 為:
5A-03-BE-00-00(無結算,由 Google, Apple 或行動網路業者驗證身分)5A-03-BE-00-01(已結算,用於商業漫遊協議)
- 設定 ANQP 參數: 定義場地名稱、場地群組和網路類型。
步驟 5:RADIUS/RadSec 代理伺服器設定
將您的本機 RADIUS 伺服器配置為 RadSec 代理。定義路由規則,將包含 OpenRoaming OI 或特定領域網域樣式的驗證請求轉發至 OpenRoaming RadSec 閘道。
最佳實踐
為確保部署穩定且高效能,請遵循以下業界標準建議:
- SSID 整合: 請勿為 Passpoint 或 OpenRoaming 建立專用的 SSID。相反地,請將它們整合到單一且安全的企業 SSID 中。這樣可以大幅減少信標(beacon)開銷並節省寶貴的空中傳輸時間。
- 憑證管理: 為您的 RadSec 憑證實施自動化憑證更新流程。憑證一旦過期,將立即中止所有 OpenRoaming 驗證。
- 頻道規劃: 由於 Passpoint 依賴關聯前的 ANQP 交換,用戶端裝置會花費更多時間進行掃描和查詢。請優化您的 5 GHz 和 6 GHz 頻道規劃,以減少衝突並確保快速的探測回應。
- 領域網域過濾: 在您的 RadSec 代理上實施嚴格的領域網域過濾,以防止不必要的驗證流量湧入同盟網路。僅轉發符合有效 OpenRoaming 樣式的請求。
- 使用者體驗一致性: 確保您的實體場域指標與數位行銷素材告知使用者,他們可以透過 OpenRoaming 自動連線,進而減少對未加密開放 SSID 的依賴。
疑難排解與風險緩釋
常見故障模式與解決方案
問題:用戶端裝置無法自動連線
- 根本原因: WLC 上缺少或配置了錯誤的 Roaming Consortium OI,或者用戶端裝置未安裝正確的設定檔。
- 緩釋措施: 使用封包分析器擷取信標與探測回應訊框。驗證 802.11u 互連(Interworking)元素是否包含正確的 OI。確保已透過 MDM 或配置入口網站正確部署用戶端設定檔。
問題:RadSec 連線失敗
- 根本原因: 防火牆阻擋了 TCP 連接埠 2083,或 RadSec 憑證無效/已過期。
- 緩釋措施: 在 RADIUS 代理的 WAN 介面上進行封包擷取。驗證 TLS 握手是否成功完成。檢查憑證撤銷清單 (CRL) 的狀態。
問題:驗證過程中延遲高
- 根本原因: IDP 地理位置過遠,或 NAPTR 紀錄的 DNS 解析速度慢。
- 緩釋措施: 實施 DNS 紀錄的本機快取,並確保您的 RADIUS 代理到區域 OpenRoaming 中樞擁有低延遲的路徑。
ROI 與商業效益
轉移至 Passpoint 與 OpenRoaming 可在三個主要維度上帶來可衡量的商業價值:營運效率、安全態勢和數據智慧。
營運效率
透過自動化連線流程,場域能大幅減少與客用 WiFi 相關的支援工單。前台人員與 IT 服務台可減少花費在排查 Captive Portal 失敗和密碼問題的時間。
安全態勢
傳統的開放式客用網路會使使用者面臨竊聽和中間人攻擊。Passpoint 強制採用企業級加密(WPA2/WPA3-Enterprise)以保護所有空中傳輸流量。這可保護使用者和場域,免受與資料洩露相關的法律責任。
數據智慧
與 Purple 等平台整合時,Passpoint 可讓場域無縫識別回訪旅客。由於裝置會自動連線,場域無需使用者重複開啟瀏覽器並登入,即可擷取精確的停留時間和造訪頻率指標。這種持續的數據串流可實現高度針對性的即時互動策略。
關鍵定義
Passpoint
由 WiFi Alliance 推出的認證計畫(基於 Hotspot 2.0),使行動裝置能夠自動發現並連線至具有企業級安全性的 WiFi 網路。
它為無縫的訪客登入引導奠定了技術基礎。
OpenRoaming
由無線寬頻聯盟(WBA)建立的全球漫遊聯盟,允許使用者使用信任的身分安全且自動地連線至 WiFi 網路。
它在 Passpoint 之上作為策略和身分層。
ANQP
接入網路查詢協定(Access Network Query Protocol)。一種行動裝置在與 AP 關聯之前,用於發現網路功能的查詢 - 回應協定。
對於 802.11u 中的關聯前發現至關重要。
802.11u
IEEE 802.11 標準的修正案,增加了與外部網路互通的功能,從而實現關聯前發現。
使 Passpoint 成為可能之物理層與 MAC 層標準。
RadSec
基於 TLS 的 RADIUS(RFC 6614)。一種透過將 RADIUS 封包封裝在 TCP 上的 TLS 隧道中來確保其安全的協定。
對於 OpenRoaming 在公共網際網路上保護身分驗證流量是強制性的。
Roaming Consortium OI
漫遊聯盟組織識別碼(Roaming Consortium Organisation Identifier)。由 IEEE 分配的唯一十六進位識別碼,用於識別特定的漫遊聯盟或合作夥伴。
由 AP 用於廣播它們接受哪些漫遊憑證。
HESSID
同質 ESSID(Homogeneous ESSID)。在 AP 上配置的 48 位元 MAC 地址,用於識別屬於同一網路或場域的一組 AP。
幫助用戶端裝置理解多個 AP 屬於同一個管理網域。
EAP-TLS
可延伸驗證協定 - 傳輸層安全(Extensible Authentication Protocol-Transport Layer Security)。一種使用數位憑證進行雙向驗證的驗證協定。
Passpoint 支援的最安全的驗證方法。
範例
大型體育場部署需要設定 Cisco Catalyst 9800 無線控制器,以支援 OpenRoaming (免結算) 以及現有的企業 SSID。網路架構師必須確保用戶端裝置能使用正確的 Roaming Consortium OI 自動發現並連線至網路。
若要在 Cisco Catalyst 9800 WLC 上實作此設定,請遵循以下步驟:
- 定義 ANQP 伺服器設定檔:
wireless profile anqp openroaming-anqp-profile
venue-name english "Stadium Main Bowl"
venue-group assembly venue-type arena
network-auth-type redirect-url "https://portal.purple.ai"
ip-type ipv4-nat ipv6-no-address
- 建立 Roaming Consortium 設定檔並新增 OpenRoaming 免結算 OI (5A-03-BE-00-00):
wireless profile roaming openroaming-roaming-profile
roaming-consortium-oi 5A03BE0000
- 設定 Hotspot 2.0 (Passpoint) 設定檔:
wireless profile hotspot openroaming-hotspot-profile
anqp-server-profile openroaming-anqp-profile
roaming-consortium-profile openroaming-roaming-profile
hessid 00:11:22:33:44:55
- 將 Hotspot 設定檔套用至目標 WLAN 設定檔:
wlan openroaming-wlan 1 openroaming-ssid
security wpa wpa3
security wpa akm eap
hotspot-profile openroaming-hotspot-profile
no shutdown
- 使用 CLI 驗證設定:
show wireless profile hotspot detailed openroaming-hotspot-profile
某家多據點連鎖零售商希望從傳統的 Captive Portal 轉移到混合模式。他們希望使用 OpenRoaming 進行無縫連線,同時利用 Purple 的分析平台來追蹤訪客行為,並根據停留時間執行精準行銷活動。
此解決方案需要設定 RadSec 代理伺服器,將驗證請求路由至 OpenRoaming 聯盟,同時將計費數據傳送至 Purple 雲端平台。
- 設定本地 RadSec 代理伺服器 (例如 FreeRADIUS) 以與 OpenRoaming 閘道建立 TLS 連線:
home_server openroaming_radsec {
type = auth+acct
ipaddr = radsec.openroaming.org
port = 2083
proto = tcp
tls {
private_key_file = /etc/raddb/certs/radsec.key
certificate_file = /etc/raddb/certs/radsec.pem
ca_file = /etc/raddb/certs/wba_ca.pem
}
}
- 設定計費伺服器以複製計費封包,並將其轉發至 Purple 的 RADIUS 計費端點:
home_server purple_accounting {
type = acct
ipaddr = acct.purpleportal.net
port = 1813
secret = PurpleSharedSecret
}
realm openroaming {
auth_pool = openroaming_radsec
acct_pool = purple_accounting
}
- 在 WLC 上,確保已啟用 RADIUS 計費,並設定為每 300 秒傳送一次過渡更新。這可確保即使使用者未主動開啟瀏覽器,Purple 也能持續接收停留時間數據。
練習題
Q1. 網路工程師注意到 Android 裝置會自動連線到 OpenRoaming SSID,但 iOS 裝置卻會提示使用者手動選擇網路。這種行為最可能的原因是什麼?
提示:考慮如何在不同的行動作業系統上配發和信任設定檔。
查看標準答案
最可能的原因是 iOS 裝置未安裝所需的 OpenRoaming 設定檔,或者設定檔的憑證承載資料不被 iOS 信任。Android 裝置通常預先安裝了來自裝置製造商或電信業者配置的 OpenRoaming 設定檔。iOS 則需要透過 MDM、佈署應用程式或像 Purple 這樣的入口網站進行明確的設定檔安裝,以信任根憑證授權單位(Root CA)並將 Roaming Consortium OI 與 SSID 進行關聯。
Q2. 在 RadSec 代理的 WAN 介面上進行封包擷取期間,您觀察到傳送到連接埠 2083 的 TCP SYN 封包,但未收到 SYN-ACK。您應該採取哪些疑難排解步驟?
提示:專注於網路路徑和防火牆配置。
查看標準答案
- 驗證連外防火牆原則是否允許從 RadSec 代理 IP 到目的地 OpenRoaming 閘道的 TCP 連接埠 2083 流量。
- 檢查是否有中間安全設備(例如 IPS 或深層封包檢測防火牆)阻擋或捨棄該流量。
- 確認透過 DNS NAPTR 記錄解析的目的地 IP 地址是否正確且可連通。
- 執行 traceroute 以識別封包在傳輸路徑中是在哪裡被捨棄的。
Q3. 為什麼在佈署 Passpoint 和 OpenRoaming 時,SSID 整合被視為最佳實踐?忽略此建議的技術影響是什麼?
提示:思考空中傳輸時間效率和信標(beacon)開銷。
查看標準答案
SSID 整合至關重要,因為 AP 上設定的每個 SSID 都必須廣播自己的信標訊框(beacon frame),且通常是以支援的最低強制數據速率進行廣播。為 Passpoint/OpenRoaming 建立專屬的 SSID 會增加信標開銷,消耗寶貴的空口時間(airtime)並降低整體網路容量。透過將 Passpoint 整合到現有的安全企業級 SSID,AP 可以在現有的信標訊框內公告 802.11u 參數,從而節省空口時間並保持最佳的通道效率。
繼續閱讀本系列
iOS 與 macOS 802.1X 疑難排解:Intune、Jamf 與 Microsoft Entra ID 的部署檢查清單
使用此檢查清單診斷 iPhone、iPad 與 Mac 在 Intune 或 Jamf Pro 上無法通過 802.1X 驗證的原因。每種失敗皆對應到四種原因之一:伺服器信任、身分識別憑證、macOS 模式或 Microsoft Entra ID 群組範圍。您將透過 eapolclient 和 RADIUS 紀錄確認原因,套用修正程式,並為未來的憑證輪替做好準備。
Intune WiFi 設定檔伺服器信任:Entra ID 憑證伺服器名稱與根 CA 檢查清單
您將能夠設定 Intune WiFi 設定檔的伺服器驗證端,讓 EAP-TLS 與 PEAP 在 Windows、Apple 和 Android 上順利連線。您將學會如何將憑證伺服器名稱與 RADIUS 憑證進行比對、部署正確的根 CA、調整 Entra ID 群組指派,並在憑證更新前進行預排,以免其在背後無預警中斷連線。
Android 802.1X and EAP-TLS 疑難排解:Intune 與 Microsoft Entra ID 的部署檢核清單
您將能夠精確找出託管的 Android 手機在員工 SSID 上無法通過 EAP-TLS 驗證的原因,並在 Intune 中進行修正。將每個症狀與四個常見原因進行比對:遺失憑證授權單位 (CA) 或網域、用戶端憑證位於錯誤的設定檔中、RADIUS 伺服器名稱值不符,或是未遞送受信任的根憑證。然後套用可防止重複斷線的推出檢核清單。
對於您的特定設置有任何疑問嗎?
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話,我們將向您展示其他與您相似的用戶是如何解決此問題的。