為什麼我的訪客 WiFi 無法連線？Captive Portal 問題排解指南

TITLE: 為什麼我的訪客 WiFi 無法連線？疑難排解 Captive Portal 問題 FORMAT: Purple 技術簡報播客 VOICE: 英國英語 - 資深解決方案架構師語氣 DURATION: 約 10 分鐘 --- SECTION 1: 導言與背景 - 約 1 分鐘 哈囉，歡迎收聽來自 Purple 的技術簡報。我是您的主持人，今天我們要探討企業無線網路中最頑固、最常被誤解的問題之一：完全無法載入的訪客 WiFi Captive Portal。 您一定遇過這種情況。訪客抵達您的飯店、零售店面、體育場或會議中心。他們加入了 WiFi 網路。但什麼事也沒發生。沒有登入頁面。沒有網際網路。只有一個旋轉的圖示和越來越深的挫折感。對於場館營運總監和 IT 經理來說，那一刻不僅僅是微不足道的便利性問題。它代表了您訪客體驗的直接失敗、前台支援電話的暴增，以及錯失了收集第一方數據的機會，而這些數據正是您無線基礎設施投資的價值所在。 在本次簡報中，我們將深入探討其背後的運作機制。我們將精確解釋作業系統層級如何進行 Captive Portal 偵測、找出導致絕大多數連線失敗的六大根本原因，並為您提供一個實用、可操作的疑難排解框架，讓您今天就能交給您的 IT 團隊。讓我們開始吧。 --- SECTION 2: 技術深度探討 - 約 5 分鐘 要解決 Captive Portal 問題，您首先需要了解 Captive Portal 在網路層級實際上做了什麼。大多數人只把它當作一個登入頁面。它實際上是一個網路層級的流量攔截機制，而當事情出錯時，這個區別就顯得極為重要。 以下是其運作順序。訪客的裝置加入您的訪客 SSID，並透過 DHCP 取得 IP 位址。此時，作業系統不會等待使用者開啟瀏覽器。在背景中，系統服務會立即向廠商控制的探測 URL 發送一個未加密的 HTTP GET 請求。Apple 裝置會查詢 captive.apple.com。Android 裝置會查詢 connectivitycheck.gstatic.com。Windows 裝置會查詢 msftconnecttest.com。Firefox 則有其位於 detectportal.firefox.com 的專屬探測。 如果網路具有開放的網際網路存取權限，這些探測會傳回其預期的回應，作業系統便會判定一切正常。但在訪客網路上，您的無線閘道器或控制器會在該 HTTP 探測到達網際網路之前將其攔截。閘道器不會傳回預期的回應，而是傳回指向您 Captive Portal 登入頁面的 HTTP 302 重新導向。作業系統偵測到這個非預期的重新導向，意識到自己處於 Captive Portal 之後，並開啟一個沙盒瀏覽器視窗（通常稱為 Captive Portal 助理）來顯示登入頁面。 這是順利運作的情況。現在讓我們來談談導致其失效的六種方式。 根本原因之一：DHCP 位址池耗盡。這是高密度活動中的隱形殺手。如果您在標準的 /24 子網路上舉辦有兩千名與會者的會議，您將擁有 254 個可用 IP 位址。如果您的 DHCP 租期設定為預設的 24 小時，您將在開門後的幾分鐘內耗盡該位址池。隨後的所有連線嘗試甚至在 Captive Portal 流程開始之前就會失敗。解決方法很簡單：針對高流動率的環境，將訪客 DHCP 租期設定在 15 到 30 分鐘之間，並針對尖峰同時在線使用者人數（而非僅是總人數）規劃適當的子網路大小。 根本原因之二：DNS 攔截失敗。Captive Portal 的重導向取決於閘道器攔截 HTTP 探測。但該探測首先需要進行 DNS 查詢。如果您的 DNS 設定不允許未驗證的用戶端解析外部網域名稱，則探測永遠不會觸發。請確保您的防火牆原則明確允許來自未驗證用戶端的 DNS 查詢，並透過對測試裝置進行封包擷取來驗證您的 DNS 攔截是否正常運作。 根本原因之三：圍牆花園（Walled Garden）設定不完整。圍牆花園（也稱為預先驗證存取控制清單）定義了未驗證的訪客可以存取哪些外部網域。如果您的 Portal 歡迎頁面從不在圍牆花園中的 CDN 載入資源，該頁面將呈現為空白畫面。如果您透過 Google、Apple 或 Facebook 提供社群登入，則這些供應商使用的每個 OAuth 網域都必須列入白名單。而關鍵點在於：社群身分驗證供應商會定期更新其 CDN IP 範圍和驗證網域。六個月前運作完美的圍牆花園，今天可能會在不知不覺中失效。請安排每季進行圍牆花園稽核，並在您的硬體支援時使用萬用字元網域探測（Wildcard Domain Snooping）。在 Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 上，此功能為原生支援。 根本原因之四：HSTS 阻擋了重導向。HTTP 嚴格傳輸安全（HSTS）是一種瀏覽器安全性原則，強制僅透過 HTTPS 連線到特定網域。如果訪客的裝置嘗試聯絡預先載入 HSTS 的網域（這幾乎包括所有主流網站），而您的閘道器試圖攔截該 HTTPS 請求以重導向到 Portal，瀏覽器將偵測到憑證不符。它會顯示無法跳過的安全性警告，並完全阻擋重導向。正確的解決方案是絕不嘗試進行 HTTPS 攔截。您的閘道器應該只重導向未加密的 HTTP 探測（Canary Probes）。長期基於標準的解決方案是 RFC 8910，它定義了 DHCP Option 114。此選項允許您的 DHCP 伺服器直接向用戶端裝置宣告 Captive Portal URL，從而完全不需要進行 HTTP 重導向。iOS 14 和 Android 11 及以上版本已原生支援此功能。 根本原因之五：訪客裝置上啟用了作用中的 VPN。VPN 會加密來自裝置的所有流量，並在流量到達您的閘道之前，透過外部通道進行路由。您的閘道永遠偵測不到 HTTP 探測，因此 Captive Portal 偵測程序永遠不會被觸發。訪客看不到登入頁面，也無法連線上網。對訪客而言，解決方法很簡單：停用 VPN、連線至入口網站，然後重新啟用 VPN。對於您的第一線服務人員來說，當訪客回報連線問題時，這應該是他們詢問的第一個問題。 根本原因之六：MAC 位址隨機化破壞了工作階段的持續性。現代 iOS 和 Android 裝置預設會使用隨機 MAC 位址作為隱私保護功能。每當裝置連線到網路時，它可能會呈現不同的 MAC 位址。由於 Captive Portal 的工作階段狀態是透過 MAC 位址進行追蹤，因此一小時前已通過驗證的訪客，在其裝置的 MAC 位址輪替後，可能會再次看到登入頁面。面向訪客的解決方法是在網路設定中，針對您特定的 SSID 停用「專用位址」。營運商端的解決方法則是實作基於設定檔的驗證（例如透過 Passpoint 和 802.1X 的 OpenRoaming），這會在第 2 層使用憑證而非 MAC 位址進行驗證，從而使隨機化失效。 --- 第 3 節：實作建議與常見陷阱 - 約 2 分鐘 既然我們已經了解了根本原因，現在讓我們來談談配置完善的 Captive Portal 部署實際上是什麼樣子。 首先從您的 DHCP 架構開始。對於任何預期有超過 200 台同時連線裝置的場域，請不要使用單一的 /24 子網路。請使用 /22 或更大的子網路，並將租約時間設定為符合您場域的停留時間特性。飯店將租約設定為 8 小時。體育場將租約設定為 3 小時。購物中心將租約設定為 90 分鐘。會議中心將租約設定為 30 分鐘。 接下來，在每次重大活動之前驗證您的 Walled Garden（圍牆花園）。最少要求的項目包括：您入口網站的 FQDN 和所有相關的 CDN 網域、Apple、Google、Windows 和 Firefox 的 Captive Portal 偵測 URL，以及您支援的每個社群登入提供商的 OAuth 網域。在 Purple 的平台上，我們會自動維護並更新這些 Walled Garden 項目，作為我們雲端管理服務的一部分，這減輕了您團隊的手動維護負擔。 對於您的入口網站憑證，請使用來自受信任憑證機構的公開信任 TLS 憑證。自我簽署憑證會在每台裝置上觸發瀏覽器警告。請在到期前更新憑證——憑證過期是導致整個場域突然發生入口網站故障最常見的原因之一。 許多 IT 團隊常遇到的一個陷阱：使用先前已驗證過的裝置來測試 portal。由於您裝置的工作階段（session）仍處於作用狀態，因此會完全繞過 portal，讓您誤以為一切正常。請務必使用處於全新、未驗證狀態的裝置進行測試——可以使用新裝置，或是已清除該網路並清除 WiFi 設定檔的裝置。 最後，請思考未來的策略發展方向。Captive Portal 是一項成熟的技術，但它們本質上會帶來使用摩擦。基於 Passpoint 和 802.1X 構建的 OpenRoaming，可讓再次到訪的訪客自動且安全地連線，完全不需要看到登入頁面。在我們的 Connect 方案下，Purple 可作為 OpenRoaming 的免費身分識別提供者（Identity Provider）。Premier Inn 和曼徹斯特機場集團（Manchester Airports Group）等場域已部署此技術，在消除重複訪客重新驗證摩擦的同時，仍能保持完全符合 GDPR 規範並收集第一方數據。 --- 第 4 節：快速問答 - 約 1 分鐘 讓我們快速瀏覽一下場域 IT 團隊最常提出的問題。 問題：為什麼 portal 在 iPhone 上可以運作，但在 Android 裝置上卻不行？回答：Android 使用 connectivitycheck.gstatic.com 作為其探測 URL。如果該網域被您的防火牆阻擋，或未加入您的 walled garden 中，Android 裝置就永遠不會觸發 portal。請將其明確加入。 問題：訪客反應 portal 已載入，但登入後卻無法上網。回答：這幾乎都是 RADIUS 授權失敗所致。請檢查您的無線控制器是否可以連線到 RADIUS 伺服器，驗證雙方的共用金鑰（shared secret）是否一致，並檢視 RADIUS 記錄檔中是否有 Access-Reject 訊息。 問題：我們該如何處理每隔幾分鐘就會被登出的訪客？回答：請檢查您的閒置逾時（idle timeout）設定。許多控制器的預設閒置逾時為 5 分鐘，這對於在互動空檔會進入休眠的行動裝置來說太過短暫。針對餐旅和零售環境，請將閒置逾時至少設定為 30 分鐘。 --- 第 5 節：總結與後續步驟 - 約 1 分鐘 總結來說：訪客 WiFi Captive Portal 故障可歸納為六大類——DHCP 租期耗盡、DNS 攔截失敗、walled garden 設定不完整、HSTS 重新導向阻擋、用戶端裝置上啟用了作用中的 VPN，以及 MAC 位址隨機化。每一種都有特定且可測試的解決方案。 對於您的 IT 團隊，眼前的即時行動為：稽核您的 DHCP 租期時間和子網路大小、對照社群登入提供者目前的 OAuth 網域來驗證您的 walled garden，並在每次變更設定後，使用全新的未驗證裝置測試您的 portal。 針對您的長期規劃，請評估將 OpenRoaming 作為再次到訪訪客免去 Captive Portal 重新驗證的替代方案。此技術已相當成熟，標準建立在 IEEE 802.1X 和 WPA3-Enterprise 之下，且 Purple 在 Connect 方案下提供此功能，無需額外的軟體費用。 如需更多技術指南、案例研究和實作資源，請造訪 purple.ai。感謝您收聽本次 Purple 技術簡報。祝您的網路持續穩定，顧客隨時保持連線。