Captive Portal 與開放式網路：在安全與使用者體驗（UX）之間取得平衡

執行摘要

在現代企業環境中，訪客 WiFi 不再只是單純的營運工具 - 它是客戶互動、品牌關係以及網路安全的重要觸點。對於 IT 經理、網路架構師和場域營運總監而言，核心挑戰在於如何平衡網路安全與用戶體驗 (UX)。

本指南針對兩種主要的訪客 WiFi 架構：Captive Portals 與開放網路（Open Networks），提供權威性的技術分析。雖然開放網路提供無摩擦的存取，但它們會讓使用者面臨安全漏洞，並剝奪場域收集寶貴數據的機會。相反地，配置不當的 captive portals 會引入摩擦，導致連線中斷和系統服務台的工作量增加。

透過瞭解底層協定 - 包括 RADIUS AAA、授權變更 (CoA) 和機會性無線加密 (OWE) - 企業可以佈署既能保障網路邊緣安全、確保法規合規性，又能提供無縫用戶體驗的訪客 WiFi 系統。本文概述了實現此平衡所需的技術藍圖、配置步驟和產業最佳實踐。

技術深度剖析

Captive Portal 重新導向機制

要瞭解 captive portal 的運作方式，我們必須檢查當用戶端裝置與設定為網頁重新導向的開放 SSID 進行關聯時，所發生的封包層級互動。

當用戶端與存取點 (AP) 或無線區域網路控制器 (WLC) 建立關聯時，會透過 DHCP 獲派一個 IP 位址。然而，WLC 會在其關聯表中將用戶端的 MAC 位址設為「未驗證」狀態。在此狀態下，WLC 會套用預先驗證存取控制清單 (ACL)，封鎖除 DNS (UDP port 53)、DHCP (UDP ports 67 和 68) 以及在「Walled Garden」中定義的特定 IP 範圍之外的所有 IP 流量。

+-------------+          +------------+          +---------------+          +---------------+          +---------------+
|   Client    |          |   AP/WLC   |          |  DNS Server   |          | Purple Portal |          | RADIUS Server |
+-------------+          +------------+          +---------------+          +---------------+          +---------------+
       |                       |                         |                          |                          |
       |--- 1. Associate ----->|                         |                          |                          |
       |<-- 2. IP Assigned ----|                         |                          |                          |
       |                       |                         |                          |                          |
       |--- 3. DNS Query ----->|------------------------>|                          |                          |
       |    (captive.apple.com)|                         |                          |                          |
       |<-- 4. DNS 回應 -------|<------------------------|                          |                          |
       |                       |                         |                          |                          |
       |--- 5. HTTP GET ------>|                         |                          |                          |
       |    (已攔截)           |                         |                          |                          |
       |<-- 6. HTTP 302 -------|                         |                          |                          |
       |    (重新導向至 Purple)                           |                          |                          |
       |                       |                         |                          |                          |
       |--- 7. HTTPS GET ---------------------------------------------------------->|                          |
       |    (請求 Portal 頁面)                                                      |                          |
       |<-- 8. 提供頁面 ------------------------------------------------------------|                          |
       |                       |                         |                          |                          |
       |--- 9. 送出表單 ------------------------------------------------------------>|                          |
       |                       |                         |                          |--- 10. 驗證請求 -------->|
       |                       |<-- 11. RADIUS CoA (授權 MAC) ----------------------|                          |
       |                       |                                                    |<-- 12. 驗證接受 ---------|
       |<-- 13. 已授予存取權---|                         |                          |                          |

當使用者嘗試瀏覽 HTTP 網站，或者當作業系統的 Captive Network Assistant (CNA) 觸發自動瀏覽器視窗時，用戶端會傳送 HTTP GET 請求。WLC 會攔截此請求 (通常在連接埠 80) 並傳回 HTTP 302 重新導向狀態碼。此重新導向會將用戶端的瀏覽器導向外部 Captive Portal URL (例如 Purple 的 Portal 託管平台)，並附加關鍵查詢參數，例如：

• client_mac：訪客裝置的 MAC 位址。
• ap_mac：用戶端關聯的 AP 的 MAC 位址。
• ssid：訪客網路的名稱。
• redirect_url：使用者原本嘗試存取的原始 URL。

Captive Network Assistant (CNA) 的角色

現代作業系統 (iOS、Android、macOS 和 Windows) 使用背景精靈來監控網路連線。在與 WiFi 網路建立關聯後，作業系統會向專用的硬編碼驗證 URL 傳送 HTTP 請求。範例包括：

• Apple：http://captive.apple.com/hotspot-detect.html
• Google Android：http://connectivitycheck.gstatic.com/generate_204
• Microsoft Windows：http://www.msftconnecttest.com/connecttest.txt

如果作業系統收到預期的 HTTP 200 OK（或 HTTP 204 No Content）回應，則會假設可直接存取網際網路。如果收到 HTTP 302 重新導向，則會偵測到 Captive Portal 並啟動 CNA - 一個沙盒化、精簡的瀏覽器視窗。

管理 CNA 是訪客 WiFi 設計的關鍵面向。由於 CNA 瀏覽器經過沙盒處理，因此具有嚴格的限制：它通常不支援 Cookie、本機儲存或某些 JavaScript API，且如果使用者切換應用程式，它會立即關閉。如果 Captive Portal 設定未考慮到這些限制，使用者體驗將會失敗。

RADIUS AAA 與授權變更 (CoA)

一旦使用者在 Captive Portal 上完成所需的動作（例如：輸入電子郵件地址、接受條款或透過社群媒體供應商進行身分驗證），入口網站伺服器必須通知 WLC 以授與網路存取權限。這是使用 RADIUS (Remote Authentication Dial-In User Service) 協定來實現的，特別是利用 RFC 3576 授權變更 (CoA)。

1. 身分驗證請求：入口網站伺服器向組織的 RADIUS 伺服器（或直接向作為 AAA 用戶端的 WLC）傳送 API 呼叫或 RADIUS Access-Request，以驗證使用者的工作階段。
2. RADIUS CoA：RADIUS 伺服器向 WLC 傳送 CoA-Request 封包（UDP 連接埠 3799）。此封包包含用戶端的 MAC 地址以及更新工作階段狀態的指令。
3. 工作階段狀態更新：WLC 處理 CoA-Request，將用戶端的狀態從「未經身分驗證」轉換為「已驗證」，並套用驗證後原則（例如：將用戶端移至不同的 VLAN、套用頻寬速率限制或啟用無限制的網際網路存取）。
4. CoA-ACK：WLC 向 RADIUS 伺服器傳回 CoA-ACK (Acknowledge) 封包，確認原則變更。

開放式網路與機會性無線加密 (OWE)

傳統的開放式網路（無 Captive Portal、無加密）以純文字傳送所有無線框架。這使得實體範圍內的惡意行為者能夠進行被動竊聽，擷取透過未加密協定（HTTP、FTP、IMAP）傳輸的敏感資料。

為了在不引入預共用金鑰 (PSK) 摩擦的情況下減輕此漏洞，Wi-Fi 聯盟推出了機會性無線加密 (OWE)，並在 RFC 8110 中進行了標準化。OWE 在 802.11 關聯程序中使用 Diffie-Hellman 金鑰交換，為每個用戶端建立一個唯一的、加密的成對工作階段金鑰。

雖然 OWE 可以防止被動竊聽，但它不提供身分驗證。就存取控制而言，它是一個「開放」網路，但就傳輸而言是加密的。對於場域而言，OWE 代表了安全方面的重大進步，但除非與網頁式重新導向機制配合使用，否則它無法促進資料擷取或服務條款接受。

實作指南

本指南提供逐步部署說明，介紹如何配置一個企業級的訪客 WiFi 網路，此網路使用 Cisco Catalyst 無線區域網路控制器（WLC）並整合 Purple 的外部 captive portal 與 RADIUS 服務。

步驟 1：配置訪客 VLAN 和 DHCP 範圍

在配置無線參數之前，請先在您的核心交換器上建立一個專用的隔離 VLAN，並配置租期較短（例如 2 到 4 小時）的 DHCP 範圍，以防止高密度環境中的 IP 位址耗盡。

! Core Switch Configuration
vlan 900
 name Guest_WiFi
!
interface Vlan900
 description Guest WiFi Gateway
 ip address 172.16.0.1 255.255.240.0
 ip helper-address 172.16.0.10
!
! DHCP Server Configuration (ISC DHCPD Example)
subnet 172.16.0.0 netmask 255.255.240.0 {
  range 172.16.0.50 172.16.15.254;
  option routers 172.16.0.1;
  option domain-name-servers 8.8.8.8, 1.1.1.1;
  default-lease-time 7200;
  max-lease-time 14400;
}

步驟 2：定義圍牆花園（認證前 ACL）

為了允許未認證的用戶端解析 DNS 並存取 captive portal，您必須在 WLC 上配置認證前 ACL。此 ACL 必須允許往返於 Purple 的託管基礎架構以及任何必要的 CDN 或社群登入端點的流量。

! Cisco WLC CLI Configuration
ip access-list extended PRE_AUTH_ACL
 ! Permit DNS resolution
 permit udp any any eq domain
 permit udp any eq domain any
 ! Permit DHCP
 permit udp any any eq bootpc
 permit udp any eq bootps any
 ! Permit access to Purple Portal Servers
 permit tcp any host 54.246.117.243 eq www
 permit tcp any host 54.246.117.243 eq 443
 permit tcp any host 52.19.194.225 eq www
 permit tcp any host 52.19.194.225 eq 443
 ! Permit Apple CNA validation bypass (Optional - if you wish to bypass CNA)
 permit tcp any host 17.253.109.201 eq www
 deny ip any any

步驟 3：配置 RADIUS 認證與計費伺服器

配置 WLC 以與 Purple 的 RADIUS 伺服器進行通訊，用於認證、計費和 CoA。

! Configure RADIUS Authentication Server
radius-server host 54.246.117.243 auth-port 1812 acct-port 1813 key 7 
! Configure RADIUS Accounting Server
radius-server host 52.19.194.225 auth-port 1812 acct-port 1813 key 7 
!
! Enable RFC 3576 Change of Authorization (CoA)
aaa server radius dynamic-author
 client 54.246.117.243 server-key 7 
 client 52.19.194.225 server-key 7 
 port 3799

步驟 4：配置訪客 SSID (WLAN)

建立訪客 SSID，將其對應至訪客 VLAN，並套用安全性與重新導向原則。

! Create WLAN
wlan Guest_WiFi 1 Guest_WiFi
 client vlan Guest_WiFi
 ip flow monitor wireless-input unicast
 ip flow monitor wireless-output unicast
 ! Configure Layer 2 Security to Open
 security wpa secondary none
 security wpa akm owe
 ! Configure Layer 3 Security for Web Redirect
 security web-auth
``` security web-auth parameter-map PURPLE_MAP
 security web-auth authentication-list PURPLE_RADIUS_LIST
 ! Apply Pre-Authentication ACL
 security web-auth acl PRE_AUTH_ACL
 no shutdown

步驟 5：設定 Web Auth Parameter Map

定義重定向參數，包括外部傳送門 URL 以及 WLC 應如何處理用戶端的 MAC 位址。

! Parameter Map Configuration
parameter-map PURPLE_MAP
 type webauth
 redirect-server-url https://portal.purplewifi.net/auth
 redirect portal
 banner-page-disable
 logout-window-disable

最佳實踐

安全性最佳化

1. 用戶端隔離：務必在訪客 VLAN 上啟用用戶端隔離（點對點封鎖）。這可防止關聯的訪客裝置互相通訊，從而降低內部掃描、ARP 欺騙和橫向惡意軟體傳播的風險。
2. DNS 過濾：在訪客網路中實作 DNS 層級安全性（例如 Cisco Umbrella 或 Cloudflare Gateway）。這可確保使用者即使在驗證身份之前，也能免於存取已知的網路釣魚、惡意軟體或成人內容網域。
3. 安全重定向 (HTTPS)：確保 WLC 上設定的重定向主機名稱使用有效且受大眾信任的 SSL/TLS 憑證。如果 WLC 使用自我簽署憑證重定向 HTTPS 請求，使用者的瀏覽器將顯示嚴重的安全性警告，從而破壞信任並提高流失率。

使用者體驗 (UX) 最佳化

1. 最佳化重定向速度：保持預先驗證 ACL（walled garden）儘可能精簡。過多 DNS 查詢或在龐大 ACL 中進行 IP 檢查會延遲重定向過程，導致用戶端裝置逾時並判定網路故障。
2. 減少表單欄位：Captive Portal 表單中每增加一個欄位，轉換率就會降低大約 10%。將資料收集限制在必要欄位（例如電子郵件地址或社群媒體登入），並利用漸進式剖析在後續造訪中收集更多資訊。
3. 實作 MAC 快取：為了防止回訪訪客每次進入場所都必須重新驗證，請設定 MAC 快取（也稱為 MAC 繞過）。當用戶端成功驗證時，RADIUS 伺服器會將其 MAC 位址快取一段設定的時間（例如 30 天）。在後續造訪時，WLC 會向 RADIUS 伺服器執行無聲 MAC 驗證，直接授予存取權限而無需顯示傳送門。

疑難排解與風險緩釋

1. "CNA 迴圈" 失敗模式

• 症狀：用戶端連線到 SSID，CNA 視窗開啟，使用者完成登入流程，但 CNA 視窗未關閉，或立即重新開啟，提示使用者再次登入。
• 根本原因：CNA 瀏覽器透過持續輪詢其驗證 URL（例如 captive.apple.com）來判斷網路連線能力。如果 WLC 授權了網際網路存取，但圍牆花園或路由設定仍然封鎖或將流量重導向至該驗證 URL，作業系統就會認為它仍處於受限狀態。
• 緩解措施：確保 RADIUS CoA 成功將用戶端轉換至不受限制的角色，其中允許所有前往驗證網域的流量。或者，透過在預先驗證 ACL 中允許存取驗證網域，將 WLC 設定為完全繞過 CNA 偵測，不過這會導致某些裝置無法自動彈出入口網站。

2. MAC 隨機化問題

• 症狀：儘管已啟用 MAC 快取，回訪訪客仍被迫重新透過 Captive Portal 進行驗證。
• 根本原因：現代作業系統（iOS 14+、Android 10+、Windows 10/11）預設使用 MAC 隨機化。裝置會為每個 SSID 產生一個唯一的本地管理 MAC 地址。如果使用者啟用了「專用地址」，MAC 地址可能會定期輪替，從而破壞基於 MAC 的快取和分析。
• 緩解措施：接受基於 MAC 的追蹤在長期分析中已被淘汰。利用替代識別碼（例如透過入口網站收集的使用者帳戶或電子郵件地址）來連結工作階段。若要實現無縫存取，請考慮部署 Passpoint（Hotspot 2.0），它使用安全設定檔而非 MAC 地址進行驗證。

3. DNS 解析失敗

• 症狀：Captive Portal 頁面無法載入，在用戶端瀏覽器中顯示 "DNS_PROBE_FINISHED_NO_INTERNET" 或類似錯誤。
• 根本原因：未經驗證的用戶端無法解析外部 Captive Portal 的主機名稱，因為 WLC 正在封鎖 DNS 流量，或者指派的 DNS 伺服器無法從訪客 VLAN 連入。
• 緩解措施：重複檢查預先驗證 ACL，確保明確允許往返 DNS 伺服器的 UDP 連接埠 53。驗證 DHCP 範圍是否正在發布 ACL 中允許的有效且可連入的 DNS 伺服器（例如公共解析程式 8.8.8.8 或 1.1.1.1）。

投資報酬率與商業影響

部署先進的訪客 WiFi 解決方案代表一項策略性投資，可在多個面向產生可衡量的商業價值。

資料收集與阻力之對比

開放式網路不提供任何數據擷取，這讓場所無法得知是誰在使用他們的服務。基本的 captive portal 雖然能擷取數據，但如果每次訪問都需要驗證，就會帶來極高的摩擦感。

利用 Purple 的智慧平台優化 captive portal，能在這兩者之間取得平衡。透過實施 MAC 快取，場所可在顧客首次造訪時擷取豐富的人口統計和行為數據，而後續的造訪則完全無摩擦。這種方法在建立乾淨且合規的行銷資料庫的同時，也能維持極高的使用者滿意度。

法規遵循

營運開放且未受監控的訪客網路會使組織面臨重大的法律風險。在許多司法管轄區（包括英國《2018 年資料保護法》和歐盟 GDPR），場所必須能夠識別使用者，或至少證明他們已採取合理步驟，以防止在其網路上發生非法活動（例如侵犯著作權或存取非法內容）。

企業級 captive portal 可透過以下方式降低此風險：

• 呈現具法律約束力的服務條款和隱私權政策。
• 擷取明確且細緻的行銷傳播同意。
• 記錄工作階段數據（IP 分配、MAC 位址和時間戳記）以配合執法機關的要求（例如英國的 RIPA）。