為什麼我的訪客 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 問題，您首先需要了解它在網路層級上的實際作用。大多數人認為它只是一個登入頁面。但實際上，它是一個網路層級的流量攔截機制，而當問題發生時，這個區別至關重要。 以下是其運作順序。顧客的裝置加入您的顧客 SSID，並透過 DHCP 取得 IP 位址。此時，作業系統不會等待使用者打開瀏覽器。在背景中，系統服務會立即發送一個未加密的 HTTP GET 請求到設備製造商控制的探測 URL。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 子網路下為 2,000 名與會者舉辦會議，您將只有 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 範圍和驗證網域。六個月前運作完美的圍牆花園，今天可能會在無聲無息中失效。請安排每季進行圍牆花園稽核，並在您的硬體支援時使用萬用字元網域偵聽。在 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、連線至 portal，然後重新啟用 VPN。對於您在前台服務的工作人員，這應該是他們在訪客回報連線問題時詢問的第一個問題。 根本原因之六：MAC 位址隨機化破壞了工作階段持久性。現代的 iOS 和 Android 裝置預設會使用隨機化 MAC 位址作為隱私功能。裝置每次連線到網路時，都可能呈現不同的 MAC 位址。由於 Captive Portal 工作階段狀態是透過 MAC 位址進行追蹤，因此一小時前已通過驗證的訪客，在其裝置的 MAC 輪替後，可能會再次看到登入頁面。面向訪客的解決方案是在網路設定中，針對您的特定 SSID 停用「專用位址」。電信業者端的解決方案則是實施基於設定檔的驗證，例如透過 Passpoint 與 802.1X 進行 OpenRoaming，這會在 Layer 2 使用憑證而非 MAC 位址進行驗證，從而使隨機化變得無關緊要。 - 第 3 節：實施建議與陷阱 - 約 2 分鐘 既然我們了解了根本原因，現在就來談談配置良好的 Captive Portal 部署實際上是什麼樣子。 首先從您的 DHCP 架構開始。對於預期有超過 200 台並行裝置的任何場域，請不要使用單一的 slash-24 子網路。請使用 slash-22 或更大範圍，並設定租約時間以符合您場域的停留時間分佈。飯店可將租約設定為 8 小時；體育場將租約設定為 3 小時；購物中心將租約設定為 90 分鐘；會議中心則將租約設定為 30 分鐘。 接下來，在每次重大活動前驗證您的 walled garden（圍牆花園）。最少所需的條目包括：您的 portal 的 FQDN 及其所有關聯的 CDN 網域、適用於 Apple、Google、Windows 和 Firefox 的 Captive Portal 偵測 URL，以及您支援的每個社群登入提供者的 OAuth 網域。在 Purple 的平台上，我們會將這些 walled garden 條目作為雲端管理服務的一部分進行自動維護與更新，從而減輕您團隊的手動維護負擔。 至於您的 portal 憑證，請使用來自公認憑證機構且受公開信任的 TLS 憑證。自我簽署憑證會在每台裝置上觸發瀏覽器警告。請在到期前更新憑證 - 逾期憑證是導致突然發生全場域 portal 故障最常見的原因之一。 許多 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 租期（lease times）和子網路大小、對照社群登入提供者目前的 OAuth 網域來驗證您的 Walled Garden，以及在每次變更設定後，從全新未驗證的裝置測試您的 portal 頁面。 對於您的長期路線圖，請評估將 OpenRoaming 作為再次到訪訪客免除 captive portal 重新驗證的替代方案。該技術已相當成熟，標準也已在 IEEE 802.1X 和 WPA3-Enterprise 下確立，且 Purple 在 Connect 方案下提供此功能，無需支付額外的軟體費用。 如需更多技術指南、案例研究與實施資源，請造訪 purple.ai。感謝您收聽本次 Purple 技術簡報。祝您的網路保持穩定，訪客連線順暢。