為什麼飯店式訪客 WiFi 在住宅大樓中會失敗

飯店式賓客 WiFi 在住宅大樓中會失敗，因為它假設了短暫停留、只有手機和瀏覽器的情境。一間附家具的公寓可能擁有 10 台或更多聯網裝置，許多裝置沒有瀏覽器可以完成 Captive Portal 登入，而且住戶希望投放和智慧家庭套件能夠正常運作。相反地，應該給予每個住戶其專屬的 iPSK 金鑰和私有網路區段。

住宅大樓中的賓客 WiFi 失敗會呈現什麼樣子？

故障很少表現為網路完全中斷。它表現為付租金（而非只是過客）的住戶接二連三地提出小抱怨。

在租賃專用住宅（BTR）、學生宿舍或多戶住宅（MDU）中的典型症狀包括：

• 智慧電視、喇叭或恆溫器無法加入。 這些裝置沒有瀏覽器，因此無法完成 Captive Portal（即賓客網路在授予存取權限之前顯示的網頁登入頁面）。
• 投放失敗。 住戶的手機找不到自己的 Chromecast 或 AirPlay 接收器，或者找到了鄰居的。
• 每個人每天都要重新登入。 Portal 工作階段在 24 小時計時器上過期，這適合飯店旅客，但會讓住在那裡的人感到惱火。
• 軟體更新後裝置斷開連接。 輪替其硬體位址的手機會看起來像新裝置，因此網路會忘記它們。
• 搬出後仍留有存取權限。 前住戶的筆記型電腦在租約結束數週後仍能連線。

如果您經營 飯店 並正在擴展到服務式或長期住宿公寓，您將在長期住宿樓層首先遇到這些症狀。

為什麼飯店式賓客 WiFi 會對住戶失效？

一旦有人搬進來，飯店賓客 WiFi 背後的四個設計假設就不再成立。

裝置數量不同

飯店賓客網路是圍繞著一兩晚的手機和筆記型電腦而建構的。相反地，計算一房公寓中的裝置：兩部手機、兩台筆記型電腦、一台智慧電視、一個串流棒、一個喇叭、一個視訊門鈴、一個恆溫器和一台印表機。在任何人來訪之前就有 10 個裝置。它們之中的每一個都需要連線，而且大多數都沒有螢幕可以打字。

無周邊裝置無法使用 Captive Portal

Captive Portal 的運作原理是攔截瀏覽器請求並顯示登入頁面。智慧喇叭永遠不會開啟瀏覽器，因此它永遠看不到該頁面，也永遠無法進行驗證。通常的因應對策是 MAC 位址註冊，住戶在表單中輸入每個裝置的硬體位址。但這也會失效。

MAC 隨機化破壞了裝置記憶

Apple 在 iOS 14 中推出了每個網路的私有位址，而 Android 10 預設會隨機化硬體位址。藉由 MAC 位址來記住裝置的 Portal，每當位址變更時就會失去對裝置的記憶。住戶需要重新驗證，而您的服務台就會接到電話。

用戶端隔離阻礙了家庭網路體驗

訪客網路通常會隔離用戶端，以防止陌生人存取彼此的裝置。這在飯店大廳是正確的做法。但 Chromecast 和 AirPlay 是使用多播 DNS (mDNS，定義於 RFC 6762) 來尋找接收器，這是一種僅在同一網路區段的裝置之間才能運作的探索協定。在啟用隔離的情況下，投放會失敗。而在共享網路上關閉隔離時，每個住戶都能看到其他所有住戶的裝置。

短期住宿信任是錯誤的信任模型

飯店 WiFi 信任某個裝置一次住宿的時間，然後就會遺忘它。住戶 WiFi 必須在整個租期內 (有時長達數年) 信任住戶家庭的裝置。它還必須在特定日期撤銷該信任。入口網站工作階段計時器無法表示這兩種規則。

您如何查明是哪種原因造成的？

在變更任何內容之前，請先將投訴與原因進行比對。大多數建築物都有不只一個原因。

住戶回報的症狀	最可能的原因	如何確認
智慧電視或喇叭無法連線	無螢幕裝置上的 Captive Portal	在您的控制器記錄中檢查該裝置是否曾到達入口網站頁面
手機找不到自己的 Chromecast	用戶端隔離阻擋了 mDNS	在單一測試 SSID 上停用隔離並測試投放功能
住戶在投放時看到鄰居的裝置	關閉隔離的共享扁平網路	從住戶裝置掃描 mDNS 廣告
每個裝置每天都需要登入	專為短期住宿設計的入口網站工作階段逾時	讀取訪客 SSID 上的工作階段逾時時間
手機更新後裝置被「遺忘」	MAC 隨機化對抗基於 MAC 的記憶	比較更新前後的裝置硬體位址
前住戶仍可連線	租約結束與網路存取之間沒有連結	對照目前的租約記錄稽核作用中的憑證

如果前兩行描述了您的建築物情況，那麼修正工作階段逾時將無濟於事。您需要不同的驗證模型，而不是微調的入口網站。

哪種驗證模型適合住戶？

下表比較了建築物實際執行的四個選項。

方法	註冊引導	無螢幕裝置	投放與智慧家庭	撤銷單一家庭	最適合
Captive portal (飯店模式)	每個裝置上透過瀏覽器登入，逾時後重複登入	若無手動 MAC 註冊則失敗	被用戶端隔離阻擋	等待工作階段過期	飯店旅客、購物者、粉絲、乘客
每棟建築一個共享複雜密碼	所有人使用同一個複雜密碼	連線	可運作，但每個住戶都能看到所有裝置	變更整棟建築的複雜密碼	無多租戶建築
每個家庭一個 iPSK	每個公寓一個不重複的複雜密碼	連線	僅在家庭區段內運作	刪除一個金鑰	BTR、學生宿舍、MDU、長期住宿

iPSK (identity pre-shared key) 運作於單一 WPA2-Personal 網路，其中每個住戶擁有專屬的金鑰。當裝置加入時，作為檢查憑據之驗證服務的 RADIUS 伺服器會識別其所使用的金鑰。接著網路會將該裝置分配到該住戶的 VLAN (虛擬網路區段)。住戶擁有的每部裝置 (不論有無螢幕) 均只需使用其已知的金鑰加入一次即可。

其結果是在每間公寓內建立一個私有網路泡泡。住戶的手機可以找到自己的 Chromecast，因為兩者處於同一個區段。但無法看到隔壁鄰居的裝置，因為該住戶持有不同的金鑰且處於不同的區段。

IEEE 802.1X 對於每個人來說安全性更高，但大多數智慧電視、喇叭和恆溫器都無法使用。請將其保留給員工網路使用。

如何在 Cisco Meraki、HPE Aruba、Ruckus 及其他硬體上解決此問題？

您不需要購買新的無線存取點。每個主要供應商都以自己的名稱支援單一金鑰驗證：

• Cisco Meraki: Identity PSK (iPSK)
• HPE Aruba: MPSK (Multiple Pre-Shared Key)
• Ruckus: DPSK (Dynamic Pre-Shared Key)
• Juniper Mist: Multi PSK
• Ubiquiti UniFi: Private Pre-Shared Keys
• Cambium: ePSK
• Extreme: PPSK (Private Pre-Shared Key)
• Fortinet: MPSK

在切換之前，請確認您供應商文件中的兩件事。第一，確認您的控制器版本上每個 SSID 的最大金鑰數量。第二，確認是否支援 WPA3-Personal 搭配單一金鑰驗證，因為許多部署仍運作於 WPA2-Personal。

Purple 的多租戶 WiFi 作為雲端重疊層運作於該硬體之上，因此無需拆除並更換設備。Purple 提供將每個金鑰對應到其住戶的雲端 RADIUS 服務。您可以從單一介面管理每棟建築的金鑰。Purple 擁有 ISO 27001 認證並符合 GDPR 規範，且該平台已在 80,000 多個實體場域中運作 (此為 Purple 的自家數據)。

請將您的訪客網路保留給訪客使用。Purple 的 Guest WiFi 會為每位連線的訪客建立 WiFi Visitors 紀錄。根據 Purple 的 WiFi Visitors 支援文章，該紀錄包含造訪過的場域、造訪次數及連線方式。這適用於大廳或一樓的咖啡廳，而不適用於住戶的家用連線。

實際案例情境：酒店新增長期住宿樓層

狀況： 一家擁有 180 間客房的城市酒店將其中一個樓層改建為 40 間服務式公寓，供住宿一至六個月的旅客使用。長期住宿房客使用現有的訪客 SSID，配有 captive portal、用戶隔離及 24 小時工作階段逾時限制。

所做的調整。 該酒店保留了短期住宿客房和大廳的入口網站 SSID，並為長期住宿樓層新增了一個 iPSK SSID，配有 40 組金鑰，每組金鑰各自對應到其專屬的 VLAN。金鑰在辦理入住時發放，並在退房時刪除。

成果。 每位長期住宿旅客的登入次數從每週七次減少到抵達時的一次。智慧電視和投影裝置在首次嘗試時就成功連線，因為它們不再遇到入口網站。在退房時，只要刪除一組金鑰，即可移除該公寓已連線的所有裝置。

實際案例：大學宿舍取代 MAC 註冊

背景。 一所公立大學擁有一個設有 600 個床位的學生宿舍，原本使用 Captive Portal。學生必須在網頁表單中輸入每個 MAC 位址來註冊遊戲主機和智慧喇叭。手機上的隨機化位址意味著每學期都必須重新註冊。

所做的調整。 IT 部門在現有的無線基地台上，為每個書房臥室發放了一組 iPSK 金鑰。每位學生在分配到房間時都會收到其專屬金鑰。金鑰與住宿合約的結束日期連動。

成果。 手動 MAC 註冊次數降至零，因為主機和喇叭現在可以透過複雜密碼直接連線。在學年結束時，IT 部門一次整批撤銷了所有 600 組金鑰，而不需要逐一追查個別裝置的記錄。

如何防止這種情況再次發生？

圍繞著租期而非訪客體驗來規劃住戶網路。

1. 按受眾區分網路。 為訪客運行一個帶有入口網站的訪客 SSID，並為住戶運行一個 iPSK SSID。保持較低的 SSID 數量，因為每個額外的 SSID 都會增加信標流量並佔用空口時間。
2. 將金鑰與入駐、異動和遷出流程綁定。 在搬入時發放金鑰，在住戶更換單元時重新分配，並在租約結束日撤銷。Purple 的 Multi-Tenant WiFi 可集中管理此生命週期。
3. 按公寓而非按人頭規劃容量。 評估每個單元所需的完整裝置數量，包括傍晚尖峰時段的串流傳輸需求。
4. 區分數據模型。 訪客 WiFi 的存在部分是為了透過自願同意來建立第一方數據。住戶 WiFi 是您在租約下提供的服務，因此請勿對其進行行銷數據收集。如果您想了解共享空間的使用情況，請閱讀 Presence analytics vs engagement analytics。如果您使用的是 HPE Aruba，請閱讀 HPE Aruba Central presence analytics: setup, exports and limits。
5. 在混合用途場所應用相同的模式。 一棟一樓設有 零售 店鋪、或是設有員工宿舍的 醫療保健 園區大樓，需要為公眾提供入口網站，並為居住在那裡的人員提供 iPSK。

常見問題

我可以對住戶使用 captive portal 嗎？

不行，不能將其作為主要的住戶網路。Captive Portal 在每個裝置上都需要瀏覽器，而智慧電視、喇叭和恆溫器並沒有瀏覽器。Portal 也會讓工作階段過期，並忘記硬體位址輪替的裝置。請為訪客和短期留宿的賓客保留 Portal。為住戶提供每戶一個 iPSK 金鑰，讓每個裝置只需加入一次，並在整個租期內保持連線。

iPSK 可以在我已擁有的基地台上運作嗎？

可以，如果您使用的是主要廠商的最新控制器。Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 都以各自的功能名稱支援單一金鑰驗證。請查看您的廠商文件，以瞭解您的控制器版本中每個 SSID 的最大金鑰數量。Purple 在該硬體上以雲端重疊的方式運作，因此您不需要更換基地台即可將住戶轉移到 iPSK。

訪客 WiFi 和住戶 WiFi 可以在相同的基地台上運作嗎？

可以。將它們作為相同基地台上的獨立 SSID 運作，每個 SSID 都對應到各自的 VLAN。訪客會看到帶有 Captive Portal 的訪客網路，而住戶則使用其家庭金鑰加入 iPSK 網路。請保持較低的 SSID 總數，因為每個額外的 SSID 都會增加信標流量，從而消耗廣播該 SSID 的每個基地台之無線電傳輸時間。

當住戶搬出時，他們的裝置會發生什麼事？

您只需撤銷他們的金鑰，使用該金鑰的每個裝置就會失去存取權限。因為每個家庭都擁有自己的密碼，一次刪除即可同時移除手機、筆記型電腦、電視和喇叭，而不會影響任何其他住戶。將金鑰撤銷與租期結束日期相綁定，如此一來，存取權限就會在合約結束當天終止，而不是在有人想起要更改密碼時才終止。

iPSK 是否與 802.1X 一樣安全？

不，但它是適合住宅裝置的控制方式。IEEE 802.1X 賦予每個人個別的憑證，這適合員工的筆記型電腦。大多數智慧電視和喇叭都無法使用它，因此它在公寓中無法發揮作用。iPSK 為每個家庭提供唯一的金鑰，並將其隔離在各自的 VLAN 中，因此金鑰外洩只會暴露一間公寓，而不會影響整棟大樓。請對員工使用 802.1X，對住戶使用 iPSK。

GDPR 如何以不同方式適用於住戶 WiFi？

根據 UK GDPR，住戶的連線是您在租賃合約下提供的服務，因此法律依據可能是第 6(1)(b) 條規定的合約，而不是行銷同意書。訪客 WiFi 通常會透過選擇性加入來收集行銷資料。請將這兩者分開：不要在住戶網路上進行行銷資料收集。Purple 通過 ISO 27001 認證並符合 GDPR 規範，並在此基礎上處理住戶網路資料。

從 Portal 移轉到 iPSK 需要花費多少心力？

這是一項設定變更，而非硬體專案。您只需在現有的控制器上建立一個 iPSK SSID，將其連線至 RADIUS 服務（例如 Purple 的雲端 RADIUS），並將金鑰對應到住戶的 VLAN。較大的人力工作在於營運面：在入住時發放金鑰，並將金鑰撤銷與租約結束日期進行連動。在轉換期間並行運作入口網站與 iPSK 網路，確保沒有任何住戶會失去連線。