為什麼我的訪客 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 位址池耗盡。這是高密度活動中的隱形殺手。如果您在標準的 slash-24 子網路下舉辦有兩千名與會者的會議，您只有 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 稽核，並在您的硬體支援時使用萬用字元網域窺探（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 位址進行驗證，從而使隨機化變得無關緊要。 - - 第 3 節：實施建議與陷阱 - 約 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 團隊經常面臨的一個陷阱是：使用先前已驗證過的裝置測試 portal。由於您的裝置工作階段（session）仍處於作用狀態，因此您會完全繞過 portal，並誤以為一切正常。請務必使用全新、未驗證狀態的裝置進行測試 - 可以是新裝置，或是已清除 WiFi 設定檔並選擇清除該網路記憶的裝置。 最後，請考慮未來的策略發展方向。Captive portal 是一項成熟的技術，但它們本身就存在使用摩擦。建構於 Passpoint 與 802.1X 之上的 OpenRoaming，可讓再次造訪的訪客安全地自動連線，完全不需要看到登入頁面。在我們的 Connect 方案中，Purple 可免費作為 OpenRoaming 的身分識別提供者。像 Premier Inn 和 Manchester Airports Group 等場域都已經部署此方案，在消除回訪客重複驗證摩擦的同時，仍能保持完全符合 GDPR 規範並進行第一方數據收集。 - 第 5 節：快速問答 - 約 1 分鐘 讓我們來解答場域 IT 團隊最常遇到的一些問題。 問題：為什麼 portal 在 iPhone 上運作正常，但在 Android 裝置上卻不行？解答：Android 使用 connectivitycheck.gstatic.com 作為其探測 URL。如果該網域被您的防火牆封鎖或未列在您的 walled garden 中，Android 裝置就永遠不會觸發 portal。請務必將其明確加入。 問題：訪客反映 portal 已載入，但在登入後卻無法上網。解答：這幾乎都是 RADIUS 授權失敗。請檢查您的無線控制器是否可以連線到 RADIUS 伺服器，驗證雙方的共用金鑰（shared secret）是否相符，並檢視 RADIUS 記錄中的 Access-Reject 訊息。 問題：我們該如何處理每隔幾分鐘就會被登出的訪客？解答：請檢查您的閒置逾時設定。許多控制器預設為 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 之下，且 Purple 在 Connect 方案中免費提供此功能，無需額外的軟體成本。 如需更多技術指南、案例研究和部署資源，請造訪 purple.ai。感謝您收聽本次 Purple 技術簡報。確保您的網路穩定可靠，並讓您的訪客保持連線。