Aruba Central 與 Purple WiFi：雲端管理整合

Aruba Central 與 Purple WiFi：雲端管理整合。為 IT 領導者提供的簡報。 歡迎。如果您正在管理多個場地的訪客 WiFi，且正在使用 Aruba Central，本集節目與您直接相關。我將帶您詳細了解 Purple 如何與 Aruba Central 整合——架構、設定步驟、多站點部署模式，以及讓團隊措手不及的陷阱。這是一份實用的簡報，而非產品推銷。讓我們開始吧。 第一節：背景以及為何重要。 Aruba Central 是 HPE 的雲端管理網路平台。它是部署在飯店、零售連鎖店、體育場、會議中心和公營部門建築中數以萬計的 Aruba Instant Access Points 的控制平面。如果您已從內部部署的 Aruba 控制器——行動控制器或行動導體——遷移到 Central，您已經歷了從依賴 CLI、站點專屬設定到以群組為基礎、由雲端推送的政策管理之轉變。這種轉變從根本上改變了您整合像 Purple 這樣的訪客 WiFi 平台的方式。 在傳統的內部部署 Aruba 控制器上，您會直接在控制器本身上設定 captive portal 重新導向和 RADIUS 驗證。控制器是政策執行點，位於您的資料中心或通訊室中。使用 Aruba Central，政策執行仍然發生在存取點上——但設定是從雲端下推的。這表示您的整合接觸點有所不同。您使用的是存在於 Central 設定階層中的群組範本、SSID 設定檔和外部 captive portal 設定檔物件，而不是機架上的某個盒子。 Purple 位於這一切之上，作為雲端託管的訪客 WiFi 智慧平台。它提供 captive portal——訪客看到的歡迎頁面——處理驗證邏輯，在獲得同意的情況下擷取第一方資料，並將分析資料回饋給您的行銷和營運團隊。問題是：您如何在潛在數百個站點之間，乾淨俐落地、大規模地將這兩個雲端平台串聯起來？ 第二節：技術架構。 讓我描述一下當訪客連線時的資料流。訪客裝置與您的訪客 SSID 連線——我們稱之為 Hotel-Guest——該 SSID 由 Aruba Instant AP 廣播。該 AP 已透過 Aruba Central 設定了一個外部 Captive Portal 設定檔。該設定檔包含兩個關鍵資訊：指向 Purple captive portal 伺服器的重新導向 URL，以及指向 Purple RADIUS即服務端點的 RADIUS 伺服器詳細資料。 當訪客開啟瀏覽器時，AP 會攔截 HTTP 請求，並將其重新導向至 Purple 的歡迎頁面。訪客進行驗證——根據您的 Purple 設定，透過社群登入、電子郵件、簡訊或自訂表單。Purple 的後端接著發送 RADIUS Access-Accept 訊息回 AP，該訊息授予訪客網際網路存取權限，並將其從預驗證角色移至已驗證的訪客角色。RADIUS 帳戶處理封包在整個工作階段中流通，使 Purple 能夠掌握工作階段持續時間和數據使用量。 現在，與內部部署 Aruba 的關鍵區別在於：在 Aruba Central 中，您只需在群組層級設定一次外部 Captive Portal 設定檔，它就會傳播到該群組中的每個 AP。您無需接觸個別 AP。這對於多站點部署來說非常強大，但要求您在開始之前先建立正確的群組結構。 Aruba Central 將裝置組織成群組，而在群組內，您可以擁有站點。群組是設定的單位——SSID、無線電設定檔、安全政策都存在於群組層級。站點是位置和監控的單位。對於飯店連鎖店來說，一個明智的結構是根據物業類型建立群組——例如，全方位服務飯店和經濟型物業——每個實體飯店作為適當群組內的一個獨立站點。Purple 的設定再對應到群組：每個群組一個外部 Captive Portal 設定檔，指向同一個 Purple RADIUS 端點，但可能使用 Purple 的場地層級自訂功能，為每個站點提供不同的歡迎頁面主題。 圍牆花園是團隊經常出錯的關鍵設定元素。在訪客驗證之前，AP 僅允許 DNS 和 DHCP 流量，以及您明確列入白名單的任何網域。為了讓 Purple 正常運作，您必須將 Purple 的 captive portal 網域、Purple 用於資產的任何 CDN 網域，以及如果您使用社群驗證時任何社群登入提供者的網域——Facebook、Google、Apple——列入白名單。如果您遺漏某個網域，歡迎頁面將部分載入或驗證會無聲地失敗。Purple 的支援文件提供了目前的圍牆花園清單，值得將該清單視為一份動態文件，每當 Purple 更新其平台時，您都應該檢視它。 第三節：Aruba Central API 的自動化表面。 如果您要部署到超過二十個站點，透過 Central UI 手動設定將成為瓶頸。Aruba Central 提供了一個全面的 REST API——Central API——讓您可以自動化 SSID 建立、captive portal 設定檔指派和圍牆花園設定。該 API 使用 OAuth 2.0 驗證，您需要從 Central 入口網站產生 API 憑證。 Purple 整合的主要 API 端點有：WLAN 設定端點，讓您建立和更新 SSID 設定檔；外部 captive portal 設定檔端點，您在此定義 Purple 重新導向 URL 和 RADIUS 伺服器詳細資料；以及站點和群組管理端點，讓您以程式化方式將裝置指派到站點和群組。如果您要上線一個新的場地，您可以編寫一個指令碼，在 Central 中建立站點，將 AP 指派給該站點，套用正確的群組範本，並設定 Purple 專屬的 captive portal 設定檔——完全無需操作 UI。 Purple 也提供了自己的 API，讓您建立場地記錄、設定歡迎頁面主題，以及提取分析資料。一個成熟的整合將同時使用這兩個 API：Central 的 API 用於管理網路層，Purple 的 API 用於管理訪客體驗層。這是大型零售連鎖店和飯店集團在每季上線數十個新站點時所使用的模式。 第四節：逐步設定。 讓我帶您完成單一站點的設定順序，之後您將自動化此流程以進行擴展。 首先，在 Aruba Central 中，導覽至您的目標群組並開啟 WLAN 設定。建立一個新的 SSID——例如 Venue-Guest——並將安全等級設定為訪客。這是 Aruba 對於開放式或 captive-portal 驗證網路的術語。 第二，在安全性索引標籤下，將 Splash Page 類型設定為外部 Captive Portal。建立一個新的外部 Captive Portal 設定檔。給它一個描述性名稱——Purple-Guest-Portal 就很適合。將驗證類型設定為 RADIUS 驗證。在 IP 或主機名稱欄位中輸入 Purples 的 captive portal 伺服器主機名稱。輸入重新導向 URL。啟用 HTTPS。將 Captive Portal 失敗行為設定為拒絕網際網路，這是更安全的預設值。 第三，設定 RADIUS 伺服器。在 Central 中，前往驗證伺服器設定並新增 Purple 的 RADIUS即服務伺服器。您將需要伺服器 IP 或主機名稱、共用密碼——您在 Purple 的平台中產生——以及驗證埠，標準是 1812，帳戶處理埠為 1813。將此伺服器新增為您訪客 SSID 的主要伺服器。 第四，設定圍牆花園。在 SSID 的存取規則中，將 Purple captive portal 網域和任何社群登入網域新增至允許清單。請仔細測試——遺漏某個網域是歡迎頁面失敗最常見的原因。 第五，儲存並推送設定。Central 會將設定推送至群組中的所有 AP。在測試裝置上驗證重新導向是否正確觸發，以及驗證是否完成。 第五節：多站點部署模式。 對於跨越五十個或更多站點的部署，您需要一個有紀律的方法。我建議的模式是：試行、範本化、自動化、驗證。 在單一站點上進行試行。確保設定完全正確——圍牆花園完整、RADIUS 正常運作、歡迎頁面順利載入、帳戶處理流暢。記錄每個參數值。然後將該設定建置到 Central 群組範本中。該範本將成為您的真實來源。 對於部署，在您上線站點時，使用 Central API 將範本推送至新的群組。如果您的 Purple 部署為每個品牌或地區使用不同的歡迎頁面主題，請將 captive portal 設定檔參數化——重新導向 URL 可以包含查詢參數，Purple 使用這些參數來提供正確的主題。這表示您可以擁有單一的 RADIUS 端點，但有多種歡迎頁面體驗，全部由中央管理。 上線後驗證每個站點。一個簡單的驗證指令碼，它會連線一個測試裝置，檢查重新導向，進行驗證，並驗證網際網路存取，將在訪客遇到問題之前發現設定漂移。Purple 的分析儀表板也會顯示工作階段是否被記錄——如果某個站點在 Purples 的報告中呈現空白，那就是網路層出現問題的訊號。 第六節：實作陷阱。 圍牆花園是頭號故障點。使用沒有快取 DNS 或入口網站工作階段的裝置進行測試。使用全新的瀏覽器設定檔或無痕模式。 第二個陷阱是 RADIUS 共用密碼不符。您在 Central 中設定的密碼必須與 Purples 平台中的密碼完全相符。一個字元的差異就會導致無聲的驗證失敗——AP 將不會收到來自 RADIUS 伺服器的回應，並且會拒絕該訪客，或者如果您將 captive portal 失敗模式設定為允許網際網路，則可能在未經驗證的情況下授予存取權限，這帶來合規風險。 第三個陷阱是 VLAN 設定錯誤。訪客流量應該在專用的 VLAN 上，與您的公司網路隔離。在 Aruba Central 中，這在 SSID 設定檔的 VLAN 設定中設定。如果您的訪客 VLAN 在上行交換器埠上沒有正確地中繼，AP 將會啟動，但訪客不會獲得 DHCP 位址。 第四個陷阱是 captive portal 重新導向時的憑證信任。現代瀏覽器和作業系統對於 HTTPS 強制執行越來越嚴格。Purple 的 captive portal 伺服器使用有效的 TLS 憑證，但如果您的圍牆花園封鎖了用戶端用於驗證該憑證的 OCSP 或 CRL 端點，您將會在歡迎頁面上看到憑證錯誤。請將這些端點加入到您的圍牆花園中。 第七節：快速提問。 Purple 是否相容於 Aruba Central 的 AOS-10 架構以及 AOS-8？是的。外部 captive portal 機制在兩個韌體流中都是一致的。UI 路徑略有不同，但底層設定物件是相同的。 我可以使用 Purple 的 RADIUS即服務，而無需運作自己的 RADIUS 基礎設施嗎？可以，這就是重點。Purple 的 RADIUS即服務是一個雲端託管的 RADIUS 伺服器，您可以將您的 Aruba AP 指向它。您不需要在內部部署 FreeRADIUS 或 Cisco ISE。 此整合是否支援 WPA3？Aruba Central 在相容的 AP 上支援 WPA3，您可以在訪客 SSID 上啟用 WPA3 轉換模式。Purple 的 captive portal 機制與加密層無關——它運作在 HTTP 重新導向層級，而非 802.11 關聯層級。 Purple 收集的數據是否符合 GDPR 規範？Purple 在設計時就將 GDPR 合規作為核心要求。歡迎頁面提供同意機制，而 Purple 的數據處理受您與他們簽訂的數據處理協議所約束。對於歐盟的場地，在上線前，請確保您的 Purple 設定包含適當的同意用語，且您的數據處理協議已就位。 第八節：總結與下一步。 總結來說：Aruba Central 和 Purple 透過外部 Captive Portal 機制進行整合，並由 Purple 的雲端 RADIUS 服務處理 RADIUS 驗證。設定存在於 Central 的群組層級，並傳播到群組中的所有 AP——這是與內部部署 Aruba 的主要架構差異。對於多站點部署，請使用 Central API 自動化佈建，並將您的試行站點設定視為後續一切作業的範本。 您的立即下一步：首先，確認您的 Aruba Central 群組結構對應到您的 Purple 場地階層。第二，從 Purple 的支援入口網站取得 Purple 目前的圍牆花園網域清單和 RADIUS 端點詳細資料。第三，在單一站點上進行試行，並在擴展之前驗證完整的驗證流程。第四，並行使用 Central API 和 Purple API 建立您的自動化指令碼。 如果您是第一次評估 Purple，purple.ai 上的訪客 WiFi 和分析平台頁面可以讓您清楚了解在 captive portal 之外您還能獲得什麼——第一方資料擷取、行銷自動化、人流分析。這就是為這個專案獲得資金的商業案例。 感謝收聽。如果您對此整合有疑問，Purple 的解決方案團隊可以針對您的特定 Aruba Central 環境，引導您完成概念驗證。