Captive Portal 對決 Splash Page

CAPTIVE PORTAL VS SPLASH PAGE - A PURPLE TECHNICAL BRIEFING Podcast Script - Approximately 10 Minutes UK English Voice --- SEGMENT 1: INTRODUCTION AND CONTEXT (approximately 1 minute) 歡迎收聽 Purple 技術簡報系列節目。我是您的主持人，今天我們將為您釐清在訪客 WiFi 採購與部署過程中，最容易讓人感到困惑的概念之一：captive portal 與 splash page 之間的區別。 如果您曾在供應商會議上聽過這兩個術語被混為一談，您並不孤單。這種情況經常發生 - 無論是在 RFP 招標文件、IT 策略簡報，還是網路工程師之間的對話中。這種混淆至關重要，因為當您把這兩者混為一談時，您最後可能不是對錯誤的組件進行了過度配置，就是對正確的組件投資不足，甚至更糟的是部署了一個外表美觀但底層缺乏適當網路控制的訪客 WiFi 解決方案，又或者是部署了一個技術上很紮實，但卻因為繁瑣且毫無品牌包裝的登入畫面而把訪客拒之門外的系統。 所以，今天我們就來解決這個問題。在本次簡報結束時，您將對每個組件的功能、它們如何互動，以及在為您的場所（無論是飯店、零售物業、體育場還是公共部門建築）評估解決方案時該注意哪些事項，建立起清晰的概念。 --- SEGMENT 2: TECHNICAL DEEP-DIVE (approximately 5 minutes) 讓我們從 captive portal 開始，因為它是所有其他功能運作的基石。 captive portal 是一種網路層級的機制。它的職責是攔截新連接設備的所有外網流量，並將其保留在一個類似數位候機室的區域，直到該設備通過驗證為止。當訪客連接到您的 WiFi SSID 時，他們的設備會透過 DHCP 取得 IP 位址 - 這部分運作正常。但在允許任何實際的網際網路流量通過之前，captive portal 會將其攔截。 以下是技術運作流程。訪客的設備發送一個 HTTP 或 HTTPS 請求 - 這可能是嘗試載入某個網站，也可能是作業系統本身的連線能力檢查，現代設備（如 iPhone 與 Android 手機）會自動執行此檢查。captive portal 控制器（位於您的無線控制器、路由器或雲端平台上）會攔截該 DNS 查詢或 HTTP 請求並進行重新導向。該設備不會連上網際網路，而是會收到一個指向特定 URL 的重新導向回應。而該 URL 就是 splash page 的所在地。 現在，重新導向機制本身使用兩種主要技術之一。第一種是 DNS 綁架 - Captive Portal 會攔截 DNS 查詢，並返回 Portal 伺服器的 IP 位址，而不是真正的目的地。第二種是 HTTP 重新導向 - Portal 會在閘道端攔截 HTTP 請求，並發出 302 重新導向回應。對於 HTTPS 流量，這會更加複雜，因為您無法在不觸發憑證警告的情況下攔截加密的工作階段。這就是為什麼大多數 Captive Portal 實作都依賴作業系統內建的 Captive Network Assistant（當您連接到新網路時手機上彈出的視窗），它在嘗試 HTTPS 連線之前，使用已知的 HTTP 端點來偵測 Captive Portal。 在網路層，Captive Portal 使用防火牆規則來執行存取控制。未經驗證的裝置會被放置在受限制的 VLAN 或子網路中，除了前往 Portal 伺服器的 DNS 和 HTTP 流量外，所有其他流量都會被封鎖。一旦驗證確認 - 無論是簡單的點擊跳轉、社群登入、電子郵件收集，還是完整的 802.1X 憑證交換 - Portal 控制器就會更新該裝置 MAC 位址的防火牆規則，將其從受限區域移至具有完整網際網路存取權限的授權區域。 這點非常重要：Captive Portal 對於訪客而言是不可見的。他們永遠不會直接看到它。他們看到的是 Splash Page。 Splash Page 是應用程式層 - 它是 HTML、CSS 和 JavaScript，會在訪客的瀏覽器或 Captive Network Assistant 快顯視窗中轉譯。它是視覺介面：您的品牌、您的標誌、您的歡迎訊息、您的條款與細則、您的社群登入按鈕、您的行銷訂閱核取方塊。正是它將冰冷的網路驗證事件轉化為具備品牌形象的訪客體驗。 您可以這樣想。Captive Portal 是門口的保全 - 它決定誰可以進入並執行規則。Splash Page 則是接待櫃台 - 它是您場域的門面，負責收集資訊並讓訪客感到賓至如歸。您兩者都需要，且兩者需要無縫協作。 現在，為什麼這種區別在商業上很重要？因為當您在評估訪客 WiFi 解決方案時，您需要針對每個組件提出不同的問題。 對於 Captive Portal，您要問的是：它支援哪些驗證方法？它能否在支援訪客社群登入的同時，也支援企業裝置的 802.1X？對於無法顯示瀏覽器的裝置，它是否支援 MAC 位址繞過？它如何處理工作階段逾時和重新驗證？它是否符合 GDPR 規定的資料保護義務？它是否與您的 RADIUS 架構整合？它能否按使用者類型分割流量 - 在網路層將訪客流量與員工流量隔離開來？ 對於登入頁面，您會問：它的自訂空間有多大？您的行銷團隊能否在不觸碰網路配置的情況下進行編輯？它支援 A/B 測試嗎？它能否向不同的使用者群組呈現不同的內容（例如：會員與首次訪客）？它是否支援影片背景、宣傳橫幅或連線後的重新導向頁面？它在行動裝置上的表現如何？它是否符合無障礙標準？ 這些在根本上是不同的採購標準，將兩者混為一談會導致糟糕的決策。我們看過有些企業在精美的登入頁面設計上投入巨資，卻發現底層的 Captive Portal 不支援其 IT 安全政策所需的驗證方法。我們也看過相反的情況 - 技術上健全的 Captive Portal 部署，但登入頁面設計得非常糟糕，以至於訪客採用率僅在百分之三十左右。 讓我們來談談支撐這一切的標準。Captive Portal 機制沒有單一的主導標準，但它在幾個重要標準的框架內運作。IEEE 802.1X 是基於連接埠的網路存取控制標準，規範裝置如何使用憑證、證書或權杖向網路進行驗證。它是企業 WiFi 安全的基石，甚至在您希望向再次造訪的訪客提供無縫、基於憑證的存取的訪客 WiFi 情境中，也變得越來越重要。最新的 WiFi 安全協定 WPA3 引入了機會性無線加密（OWE），即使在開放網路上也能對流量進行加密 - 這與 Captive Portal 部署相關，因為它改變了初始連線交握的工作方式。 從合規性的角度來看，GDPR 對登入頁面設計有重大影響。如果您的登入頁面收集個人資料（例如：電子郵件地址、姓名、社群登入資訊），您需要獲得明確且知情的同意、提供清晰的隱私權聲明以及合法的處理依據。登入頁面是捕獲該同意的地方，但 Captive Portal 才是強制執行同意與存取之間關聯的機制。如果訪客拒絕您的行銷訂閱，Captive Portal 仍需要授予他們網際網路存取權限 - 在 GDPR 下，同意行銷不能成為存取網路的條件。 如果您的訪客 WiFi 網路屬於卡片資料環境的範圍（通常在零售或餐旅業中），則 PCI-DSS 就與之相關。由 Captive Portal 強制執行的網路分割是此處的一項關鍵控制措施，可確保訪客流量與付款系統隔離。 - 區段 3：實施建議與陷阱（約 2 分鐘） 讓我給您兩個實際案例，說明這在實務中是如何運作的。 第一個例子是一家擁有 200 間客房的酒店集團。他們部署了訪客 WiFi 解決方案，其快顯頁面的品牌形象非常精美 - 包含他們的標誌、歡迎訊息以及水療中心的促銷活動。但底層的 captive portal 只是基本的開源實作，使用 DNS 劫持且沒有任何工作階段管理。結果：返回酒店的訪客在每次訪問時都被要求重新登入，即使在同一次住宿期間也是如此。快顯頁面看起來很棒，但 captive portal 沒有 MAC 位址持久性、沒有工作階段逾時設定，也沒有與物業管理系統整合。解決方法需要完全更換 captive portal 控制器 - 快顯頁面本身沒有問題。 第二個例子是一家全國零售連鎖店。他們部署了具備完整 802.1X 支援、RADIUS 整合和複雜流量細分的企業級 captive portal。但他們的快顯頁面是一個預設範本 - 純白色、無品牌標記，只有通用的 "Connect to WiFi" 訊息。訪客採用率為 34%。在他們投資設計了合適的品牌化快顯頁面並提供一鍵式社群媒體登入選項後，採用率在三個月內上升到 71%。而其中的 captive portal 根本沒有任何改變。 從這兩個案例中得到的教訓：這些不同的組件需要分開的投資和專業知識。不要讓您的網路團隊主導快顯頁面的設計，也不要讓您的行銷團隊對 captive portal 架構做出決定。 要避免的常見陷阱：第一，假設快顯頁面就是 captive portal。它不是。沒有 captive portal 的快顯頁面只是一個沒有人會被強制訪問的網頁。第二，部署 captive portal 但其快顯頁面不支援 HTTPS。在未加密的快顯頁面上收集的任何資料 - 電子郵件地址、登入憑證 - 都會以純文字傳輸。這存在 GDPR 和安全風險。第三，忽略行動裝置體驗。超過 80% 的訪客 WiFi 連線來自行動裝置。如果您的快顯頁面沒有針對行動裝置進行最佳化，您就是在本應建立正面品牌印象的時刻製造阻礙。 - 第 4 部分：快速問答（大約 1 分鐘） 讓我快速解答幾個我們經常聽到的問題。 我可以只有快顯頁面而沒有 captive portal 嗎？技術上可以 - 您可以託管一個網頁並引導人們造訪 - 但如果沒有 captive portal 強制執行重新導向，訪客就沒有理由造訪它。您將無法進行資料收集、同意管理和網路存取控制。 我可以只有 captive portal 而沒有快顯頁面嗎？可以，這在由 802.1X 自動處理驗證的企業環境中很常見。但對於面向訪客的部署，您幾乎總是會希望使用快顯頁面來處理使用者體驗和資料收集。 WPA3 會破壞 Captive Portal 嗎？如果實施得當就不會。支援機會性無線加密的 WPA3 與 Captive Portal 部署相容，但它需要入口網站使用 HTTPS，且網路必須正確發布入口網站 URL。部分較舊的用戶端裝置存在相容性問題，這也是許多場所運行雙 SSID 配置的原因。 透過 Splash Page 進行社群登入安全嗎？這取決於實施方式。基於 OAuth 2.0 的社群登入 - 透過 Google、Facebook 或 Apple - 在實施得當的情況下是安全的。Splash Page 負責處理 OAuth 流程，而 Captive Portal 則接收確認驗證的權杖。主要風險在於該權杖的驗證方式以及工作階段的管理方式。 --- 第 5 部分：總結與後續步驟（約 1 分鐘） 讓我們來做個重點回顧。 第一：Captive Portal 和 Splash Page 是不同的東西。Captive Portal 是網路控制機制 - 它攔截流量並強制執行存取規則。Splash Page 是視覺介面 - 它是訪客看到並與之互動的畫面。 第二：它們協同工作。Captive Portal 將訪客重定向到 Splash Page。Splash Page 收集驗證或同意。然後，Captive Portal 根據該結果授予存取權限。 第三：分別進行評估。提出不同的問題、應用不同的專業知識，並獨立為這兩者編列預算。 第四：合規性存在於兩者的交匯處。GDPR 同意是在 Splash Page 上收集的，但由 Captive Portal 強制執行。這兩者都必須做好。 第五：Purple 同時提供這兩者。如果您正在尋找一個既能處理企業級 Captive Portal 控制，又能提供豐富、可自訂的 Splash Page 設計的平台 - 並具有完整的分析功能、GDPR 合規工具以及與您現有基礎架構的整合 - 這正是 Purple 的設計初衷。 關於您的後續步驟，我建議閱讀有關 802.1X 驗證和訪客 WiFi 分析的 Purple 實施指南。連結在節目資訊中。如果您正處於採購流程中，請聯絡 Purple 團隊進行技術評估 - 在承諾部署之前，確保架構正確是非常值得的。 感謝您的收聽。我們下期再見。 --- 劇本結束