疑難排解大眾 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 位址池用盡。這是高密度活動中的隱形殺手。如果您在標準的 /24 子網路（slash-24 subnet）上舉辦一場有兩千名與會者的會議，您只有 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 探測。長期符合標準的解決方案是 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 位址）進行驗證，從而使隨機化不再造成影響。 現在讓我們來談談實作。一個配置完善的 Captive Portal 部署在實務上究竟是什麼樣子的？ 首先從您的 DHCP 架構開始。對於預期會有超過 200 台裝置同時連線的任何場所，請避免使用單一的 slash-24（/24）子網路。請使用 slash-22（/22）或更大的子網路，並設定符合您場所停留時間特徵的租約時間。飯店可將租約設為 8 小時；體育場設為 3 小時；購物中心設為 90 分鐘；會議中心則設為 30 分鐘。 接下來，在每次重大活動之前驗證您的圍牆花園（Walled Garden）。最少需要的條目包括：您門戶的完整網域名稱（FQDN）及其所有關聯的 CDN 網域、Apple、Google、Windows 和 Firefox 的 Captive Portal 偵測 URL，以及您支援的每個社群登入提供者的 OAuth 網域。在 Purple 的平台上，我們會將自動維護並更新這些圍牆花園條目作為我們雲端管理服務的一部分，從而減輕您團隊的手動維護負擔。 對於您的門戶憑證，請使用來自受信任憑證授權單位（CA）的公開信任 TLS 憑證。自簽章憑證會在每台裝置上觸發瀏覽器警告。請在到期前更新憑證——逾期的憑證是導致整個場所突然發生門戶失效最常見的原因之一。 許多 IT 團隊常遇到的一個陷阱是：使用先前已驗證過的裝置來測試門戶。由於您裝置的工作階段仍然有效，因此您會完全繞過門戶，並誤以為一切正常。請務必使用處於全新、未驗證狀態的裝置進行測試——可以使用新裝置，或者已清除該網路設定並清除 WiFi 設定檔的裝置。 讓我用兩個真實世界的案例來說明這些原則。 案例一：一家位於倫敦市中心、擁有 350 間客房的酒店。該物業為訪客 WiFi 運行單一的 /24（slash-24）子網。在一次大型會議期間，400 名代表同時抵達。在 20 分鐘內，DHCP 位址池便已耗盡。訪客反映雖然已連線，但無法存取 portal 頁面或網際網路。立即的解決方案是將子網擴展到 /22（slash-22），提供 1,022 個可用位址，並將租約時間從 24 小時縮短至 8 小時。長期解決方案則是導入 Purple 的雲端託管 Captive Portal，它可以即時監控 DHCP 位址池的使用率，並在位址耗盡前向網路團隊發出警報。變更後 48 小時內，portal 故障率降至接近零。 案例二：一家擁有 200 家門市的大型連鎖零售商。該連鎖店在訪客 portal 上使用 Google 和 Facebook 的社群登入。在 Google 更新其 OAuth 基礎架構後，新的驗證網域並未包含在 walled garden 中。訪客可以到達 portal 頁面，但社群登入按鈕卻顯示空白畫面。該連鎖店的 IT 團隊花了兩天時間診斷問題，才找出 walled garden 的遺漏之處。找出問題後，僅花了 10 分鐘便修復完成。啟示：切勿在 walled garden 中針對雲端 OAuth 供應商寫死（hardcode）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 分鐘。 總結今天簡報的重點。 訪客 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 或與您的客戶經理聯絡。 感謝您的聆聽。