Captive Portal 與 Splash Page 的比較

CAPTIVE PORTAL VS SPLASH PAGE — A PURPLE TECHNICAL BRIEFING 播客腳本 — 約 10 分鐘 英式英語配音 --- 第 1 節：介紹與背景（約 1 分鐘） 歡迎收聽 Purple 技術簡報系列。我是你們的主持人，今天我們要來釐清客用 WiFi 採購和部署中，最常讓人感到困惑的問題之一：captive portal 與 splash page 之間的區別。 如果您曾在供應商會議上聽到這兩個術語被混用，您並不孤單。這種情況經常發生 - 無論是在 RFP 招標文件、IT 策略簡報中，甚至在理應非常清楚兩者差異的網路工程師之間的對話中。這種混淆非同小可，因為當您將兩者混為一談時，最終可能會對錯誤的組件進行過度規格配置、對正確的組件投資不足，或者更糟的是 - 部署了一個看起來很棒但底層沒有妥善網路控制的客用 WiFi 解決方案，或是部署了一個技術上很穩健但因為介面笨重、無品牌設計的登入畫面而將顧客拒之門外的方案。 所以今天我們就來解決這個問題。在本次簡報結束時，您將對每個組件的功能、它們如何互動，以及在為您的場域（不論是飯店、零售物業、體育場還是公共部門建築）評估解決方案時應該注意什麼，建立起清晰的概念模型。 --- 第 2 節：技術深度剖析（約 5 分鐘） 我們首先從 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（當您連線到新網路時，手機上會出現的彈出視窗），它會使用已知的 HTTP 端點在嘗試進行 HTTPS 連線之前偵測 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 架構整合？它是否可以在網路層依使用者類型對流量進行區隔 - 將訪客流量與員工流量分開？ 對於登入頁面（splash page），您要問的是：它的自訂程度有多高？您的行銷團隊能否在不變動網路配置的情況下進行編輯？它支援 A/B 測試嗎？它能向不同的使用者群組提供不同的內容嗎？例如，忠誠會員與首次訪問者。它支援影片背景、促銷橫幅或連線後的重定向頁面嗎？它在行動裝置上的表現如何？它符合無障礙規範嗎？ 這些在根本上是不同的採購標準，將兩者混為一談會導致錯誤的決策。我們看過有些企業在精美的登入頁面設計上投入重金，隨後卻發現底層的 Captive Portal 不支援其 IT 安全政策所需的驗證方法。我們也見過相反的情況 - 技術上健全的 Captive Portal 部署，但登入頁面設計太差，導致訪客使用率只有百分之三十左右。 讓我們來談談支援這一切的標準。Captive Portal 機制沒有單一的主導標準，但它在幾個重要標準的架構下運作。IEEE 802.1X 是基於連接埠的網路存取控制標準，規範裝置如何使用憑證、證書或權杖向網路進行驗證。它是企業 WiFi 安全的基石，而且在您希望為回訪者提供無縫、基於憑證的存取的訪客 WiFi 情境中也變得越來越重要。WPA3 是最新的 WiFi 安全協定，引入了機會性無線加密（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 控制器，而歡迎頁面本身沒有問題。 其次，一家全國連鎖零售商。他們部署了企業級的 captive portal，支援完整的 802.1X、RADIUS 整合和複雜的流量分段。但他們的歡迎頁面是一個預設範本 - 純白色、無品牌設計，只有一個通用的「連接到 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 嗎？如果實施得當就不會。採用機會性無線加密（OWE）的 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 團隊進行技術評估 - 在承諾部署之前，確保架構正確是非常值得的。 感謝您的收聽。我們下次見。 --- 腳本結束