疑難排解公共 WiFi：修復「已連線，無網際網路」與快顯畫面重新導向失敗

歡迎閱讀來自 Purple 的技術簡報。今天，我們將探討企業級無線網路中最頑固、最常被誤解的問題之一：完全無法載入的客用 WiFi Captive Portal。 您一定遇到過這種情況。訪客抵達您的飯店、零售門市、體育場館或會議中心。他們加入了 WiFi 網路，但什麼都沒發生。沒有登入頁面，沒有網際網路。只有一個不斷旋轉的圖示，以及越來越深挫折感的訪客。對於場館營運總監和 IT 經理來說，那一刻不僅僅是一個小麻煩，它代表了您的訪客體驗直接失敗、第一線服務台的支援電話激增，並錯失了獲取第一方數據的機會，而這些數據正是您無線基礎設施投資的價值所在。 在本次簡報中，我們將深入探討技術底層。我們將解釋作業系統層級的 Captive Portal 偵測機制到底是如何運作的，找出導致絕大多數連線失敗的六大根本原因，並為您提供一個實用的、可立即執行的疑難排解框架，供您今天就交付給您的 IT 團隊。 讓我們從運作機制開始。大多數人認為 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 307 重新導向。作業系統偵測到這個非預期的重新導向，意識到自己處於 Captive Portal 之後，並開啟一個沙箱瀏覽器視窗 - 通常稱為 Captive Network Assistant - 來顯示登入頁面。 這是最理想的情況。現在，讓我們來談談導致其失效的六種原因。根本原因之一：DHCP 位址池用盡。這是高密度活動中的隱形殺手。如果您在標準的 slash-24 子網路下為 2000 名與會者舉辦會議，您只有 254 個可用的 IP 位址。如果您的 DHCP 租期設定為預設的 24 小時，那麼在活動開始後的幾分鐘內，該位址池就會被耗盡。隨後的所有連線嘗試在 Captive Portal 流程開始之前就會失敗。解決方法很簡單：在人員流動率高的環境中，將訪客 DHCP 租期設定為 15 至 30 分鐘，並針對尖峰時段的同時上線使用者人數（而非僅總人數）適當規劃子網路大小。 根本原因之二：DNS 攔截失敗。Captive Portal 重新導向取決於閘道器攔截 HTTP 探測。但探測需要先進行 DNS 查詢。如果您的 DNS 設定不允許未經身分驗證的用戶端解析外部網域名稱，探測就永遠不會啟動。請確保您的防火牆原則明確允許來自未經驗證用戶端的 DNS 查詢，並透過對測試裝置執行封包擷取，來驗證您的 DNS 攔截是否正常運作。 根本原因之三：Walled Garden 設定不完整。Walled Garden - 也稱為預先驗證存取控制清單 - 定義了未經驗證的訪客可以存取哪些外部網域。如果您的 Portal 歡迎頁面從未包含在 Walled Garden 中的 CDN 載入資源，該頁面就會顯示為空白畫面。如果您透過 Google、Apple 或 Facebook 提供社群登入，這些提供者使用的每個 OAuth 網域都必須加入白名單。而這裡有一個關鍵點：社群身分驗證提供者會定期更新其 CDN IP 範圍和驗證網域。六個月前運作完美的 Walled Garden，今天可能已經悄悄失效。請排定每季進行 Walled Garden 稽核，並在您的硬體支援的情況下使用萬用字元網域探測。在 Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 上，此功能為原生支援。 根本原因之四：HSTS 阻止重新導向。HTTP 嚴格傳輸安全（HSTS）是一種瀏覽器安全性原則，強制規定只能透過 HTTPS 連線到特定網域。如果訪客的裝置嘗試存取預先載入 HSTS 的網域 - 這幾乎包括所有主要網站 - 且您的閘道器試圖攔截該 HTTPS 請求以重新導向至 Portal，瀏覽器就會偵測到憑證不符。瀏覽器會呈現無法繞過的安全性警告，並完全阻止重新導向。正確的解決方案是絕不嘗試 HTTPS 攔截。您的閘道器應僅重新導向未加密的 HTTP 探測。長期的標準解決方案是 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 - 這是使用憑證而非 MAC 位址在 Layer 2 進行驗證，從而使隨機化變得無關緊要。 現在我們來談談實作。一個配置良好的 Captive Portal 部署在實務上究竟是什麼樣子的？ 首先從您的 DHCP 架構開始。對於預期有超過 200 台同時連線裝置的任何場所，請捨棄單一的 slash-24 子網路。請使用 slash-22 或更大的子網路，並設定租約時間以符合您場所的停留時間分佈。飯店將租約設定為 8 小時。體育場將租約設定為 3 小時。購物中心將租約設定為 90 分鐘。會議中心將租約設定為 30 分鐘。 接下來，在每次重大活動之前驗證您的 Walled Garden（圍牆花園）。最少所需的輸入項目包括：您傳送門的完整網域名稱（FQDN）及所有相關的 CDN 網域、適用於 Apple、Google、Windows 和 Firefox 的 Captive Portal 偵測 URL，以及您支援的每個社群登入提供者的 OAuth 網域。在 Purple 的平台上，我們會將這些 Walled Garden 項目作為我們雲端管理服務的一部分進行自動維護與更新，從而減輕您團隊的手動維護負擔。 針對您的傳送門憑證，請使用來自受信任憑證授權單位的公開信任 TLS 憑證。自我簽署的憑證會在每台裝置上觸發瀏覽器安全警告。請在到期前更新憑證 - 憑證過期是導致整個場所突然發生傳送門故障最常見的原因之一。 一個經常讓許多 IT 團隊踩雷的陷阱是：使用先前已通過驗證的裝置來測試傳送門。由於您裝置的工作階段仍處於作用中狀態，因此您會完全繞過傳送門，並得出一切運作正常的結論。請務必始終從處於全新、未驗證狀態的裝置進行測試 - 可以是新裝置，或是已清除該 WiFi 設定檔並選擇清除網路記憶的裝置。 讓我向您提供兩個真實世界的案例，以說明這些原則。 案例一：一家位於倫敦市中心、擁有 350 間客房的飯店。該物業為 guest WiFi 運行單一的 slash-24 子網路。在一次大型會議期間，400 名代表同時抵達。在 20 分鐘內，DHCP 池就宣告耗盡。賓客反映雖然已連線，但無法存取 Captive Portal 或網際網路。當前的解決方案是將子網路擴展到 slash-22，提供 1,022 個可用位址，並將租約時間從 24 小時縮短至 8 小時。長期的解決方案則是導入 Purple 的雲端管理 Captive Portal，它可以即時監控 DHCP 池的使用率，並在耗盡前向網路團隊發出警報。變更後 48 小時內，Portal 失敗率降至接近零。 案例二：一家擁有 200 家門市的大型連鎖零售商。該連鎖店在其 guest portal 上使用 Google 和 Facebook 的社群登入。在 Google 更新其 OAuth 架構後，新的驗證網域並不在 walled garden 中。賓客可以到達 portal 頁面，但社群登入按鈕卻顯示空白畫面。該連鎖店的 IT 團隊花了兩天時間診斷問題，才找出 walled garden 的遺漏。一旦查明，修復只需 10 分鐘。教訓是：切勿在您的 walled garden 中為雲端 OAuth 提供者寫死 IP 位址。請使用萬用字元網域項目，並每季進行審查。 現在來回答一些我們經常聽到場域 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 分鐘。 總結今天簡報的重點。 Guest 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 的服務範圍涵蓋 80,000 個場所，僅在 2024 年就處理了 4.4 億次登入。我們見過本簡報中所描述的每一種錯誤模式 - 並已開發出相應的工具來加以預防。如果您想了解 Purple 的雲端重疊網路如何與您現有的 Cisco Meraki、HPE Aruba、Ruckus 或 Juniper Mist 基礎架構整合，請造訪 purple.ai 或聯絡您的客戶經理。 感謝您的聆聽。