隨機化 MAC 位址：重新掌控 WiFi 分析

! ==============================================================================
! WLAN Controller Profile: Passpoint Hotspot 2.0 and ANQP Identity Architecture
! Purpose: Neutralize MAC randomization impact and enable authenticated CRM roaming
! Network: RFC 1918 Private Subnet (10.10.30.0/24) | Safe RFC 5737 Doc RADIUS
! ==============================================================================

wlan passpoint-profile "PURPLE-SECURE-IDENTITY"
  enable
  he-profile "WIFI-6-AX-ENTERPRISE"
  venue-group "Commercial"
  venue-type "ShoppingMall"
  network-type "FreePublic"
  internet-access
  asra-capability
  ip-addr-type-avail "IPv4-Single-NAT,IPv6"

  ! ANQP Roaming Consortium OI for OpenRoaming / Hotspot 2.0
  roaming-consortium "5A-03-BA-00-00"
  roaming-consortium "BA-A2-F0-00-00"

  ! Domain list matching venue identity domain
  domain-name "guest.purple.ai"
  domain-name "connect.venue.internal"

  ! NAI Realm matching authenticated visitor federations
  nai-realm 1 name "purple.ai"
    eap-method eap-tls
    eap-method eap-ttls
      inner-auth mschapv2

  ! 3GPP Cellular Data Offload PLMN hints
  3gpp-plmn 234-15
  3gpp-plmn 234-30

exit

wlan ssid "Purple-Secure-Passpoint"
  vlan 30
  security wpa3-enterprise
  pmf-mode required
  passpoint-profile "PURPLE-SECURE-IDENTITY"

  ! Client Isolation on internal private broadcast domain
  station-isolation enable

  ! Remote RADIUS AAA Configuration (Safe RFC 5737 doc endpoints, placeholder secrets)
  radius-server primary host 192.0.2.10 auth-port 1812 acct-port 1813
    key <RADIUS_SHARED_SECRET>
    timeout 3
    retransmit 2

  radius-server secondary host 192.0.2.11 auth-port 1812 acct-port 1813
    key <RADIUS_SHARED_SECRET>
    timeout 3
    retransmit 2

  accounting-server-group "PURPLE-RADIUS-CLUSTER"
    interim-update-interval 600
exit

interface vlan 30
  description "Purple Guest Isolated Client Network"
  ip address 10.10.30.1 255.255.255.0
  ip access-group "ISOLATE-INTERNAL-SUBNETS" in
exit

您的場域非常繁忙。大廳人滿為患，咖啡廳排隊排到門口，但您的 WiFi 儀表板卻顯示回訪訪客數量急劇下降。昨天連線過的裝置今天看起來卻像全新的一樣。Captive Portal 工作階段不斷重複出現。人流量趨勢也無端產生波動。

這通常是團隊開始歸咎於分析平台、AP 廠商或不正常的韌體版本之處。在許多環境中，實際的變化更為簡單。用戶端現在預設會 randomize mac address 值，而網路卻仍試圖將 MAC 位址視為穩定的身分。

這種不匹配打破的不僅僅是報表。它會影響存取控制、策略執行、疑難排解和訪客體驗。而且它不會消失。隱私功能現在已內置於主流作業系統中，並且正在發揮其設計初衷的作用：使跨網路的裝置追蹤變得更加困難。

實際的因應方式並非永遠與該功能對抗，而是要體認到 MAC 位址已不再是現代 WiFi 可靠的主索引鍵，然後圍繞更強大的身分訊號進行重新設計。這正是 Passpoint、OpenRoaming、基於憑證的註冊以及基於目錄的存取開始發揮作用的地方。

裝置憑空消失的神秘事件

週一早晨，訪客 WiFi 數據看起來不太對勁。回訪遊客減少、新裝置增加，而服務台前排起了一長串使用者，他們發誓上週明明就已經完成了註冊流程。在飯店、零售園區、醫院和多住戶住宅（MDU）中，我見過這種狀況每次都會引發相同的反應。IT 團隊開始檢查控制器、Captive Portal 日誌和韌體說明，儘管 WLAN 通常運作得完全符合預期。

改變的是識別訊號。用戶端裝置依然會出現，只是它們不再提供您可以視為持久性的硬體位址。一隻手機在不同的掃描、關聯或 SSID 中，可能會呈現不同的 MAC 值，具體取決於所採用的平台與隱私設定。

這會在錯誤的地方打破信任。如果網路仍將 MAC 位址視為主要鍵，那麼一般的使用者行為看起來就會像是流失、重複註冊或策略失效。

管理員通常最先注意到什麼

最初的線索通常出現在營運面，而非理論面：

• 重複訪客計數產生偏差： 熟悉的裝置看起來像新裝置，因此分析會高估新客獲取並低估忠誠度。
• Captive Portal 提示重複出現： 使用者重新連線，但因為位址不再與原始工作階段相符，而被視為首次造訪的訪客。
• 基於 MAC 的策略失效且狀況不一： 當用戶端輪替身分識別後，與特定位址綁定的規則將不再適用。
• 疑難排解變慢： 支援團隊會看到單一手機的多個裝置記錄，因而浪費時間追蹤錯誤的歷程記錄。

網路仍然在承載該用戶端。只是不再有穩定、基於 MAC 的方式來識別它。

為什麼這超出了分析的範疇

這不僅僅是報表問題。一旦位址輪替成為常態，依賴 MAC 的控制措施就會迅速顯現其老舊之處。DHCP 保留位址、MAC 驗證免除、裝置允許清單、某些網路存取控制設定檔分析方法，以及較舊的訪客工作流程，全都依賴於許多現代用戶端已不再提供的連續性。

這並不代表 MAC 隨機化是個錯誤。它解決了真實存在的隱私問題，尤其是在過去非常容易被進行被動追蹤的公共 WiFi 環境中。營運上的問題在於，許多網路在建立時所圍繞的識別碼，現在已被作業系統視為可丟棄的臨時資訊。

解決方法在於架構。僅在仍然有幫助的地方使用 MAC 位址，然後將存取控制與原則轉移到更強大的身分識別訊號，例如憑證、使用者驗證、裝置狀態、Passpoint 設定檔，以及像 OpenRoaming 這樣的聯盟模型。如果您目前的設計仍然嚴重依賴靜態硬體身分識別，請檢視 WiFi 上的 MAC 位址驗證在哪些地方開始失效，以及基於身分識別的註冊在哪些地方能為您提供更乾淨的原則、更好的可稽核性與更可靠的分析。

適應此模式的網路不再去追蹤正在消失的裝置，而是開始追蹤已驗證的使用者、受信任的裝置以及有效的作期。

什麼是 MAC 位址隨機化

出廠的 MAC 地址就像是製造時印製的永久名牌。而 MAC 地址隨機化 則是裝置選擇配戴的拋棄式名牌，如此一來，鄰近的網路就無法輕易地追蹤它從一個場域移動到另一個場域。

簡單來說，這就是隱私保護的主張。公共 WiFi 營運商、廣告商和第三方過去高度依賴穩定的 MAC 地址進行被動識別。隨機化藉由將硬體地址替換為本機管理的地址，來減少這種能見度。

如何識別隨機化位址

大多數管理員可以立即使用一個快速的技術線索。隨機化的 MAC 位址可以被識別，因為其第二個十六進位數字會是 2、6、A 或 E，如 Mist 的 MAC 位址隨機化指南 中所述。同一指南指出，預期製造商分配 OUI 的舊版原則在面對這些位址時，將會面臨 100% 的拒絕率。

範例：

• 92:B1:B8:42:D1:85 表示本機管理的位址
• 第二個十六進位數字就是線索
• 這點很重要，因為基於 OUI 的假設已不再適用

如果您的 WLAN 控制器、NAC 平台或 RADIUS 記錄能在加入時公開用戶端 MAC，您通常可以快速篩選出此模式。

為什麼較舊的 WiFi 設計會失效

舊版 WiFi 設計假設 MAC 位址代表一部裝置的穩定度足以用來錨定存取和策略。這就是為什麼許多環境仍然將其用於：

• 存取決策：MAC ACL 與 MAC 驗證繞過
• 位址管理：靜態 DHCP 對應
• 分段捷徑：特定裝置的 VLAN 或角色指派
• 舊版註冊：簡單的預共用金鑰對應

當硬體識別碼保持不變時，那些工作流程是有意義的。但當用戶端在設計上採用隨機化時，這些流程就行不通了。

如需深入瞭解這與舊版註冊引導衝突的詳細內容，這份 WiFi 的 MAC 位址驗證指南 是個實用的輔助閱讀材料。

實用規則：如果您的策略依賴製造商的 OUI，請假設它會對啟用了隱私功能的用戶端裝置進行錯誤分類。

跨裝置隨機化的演進

這種轉變並非同時影響所有的 WLAN。在掃描隨機化時代建立的網路，在數年內看起來都可能運作良好，但隨後在例行性的行動裝置更新後，就開始出現重複裝置、重新登入失敗以及干擾過多的分析數據。基礎設施完全沒變，改變的是用戶端識別模型。

從掃描隱私到連線身份識別

早期的 MAC 隨機化主要保護探測流量。裝置在搜尋網路時會遮蔽身分，但在加入後通常會使用穩定的位址。雖然這依然打破了被動客流量分析與某些定位服務，但許多運作中的 WLAN 策略得以倖存，因為關聯的用戶端 MAC 對於存取控制而言仍具有足夠的可預測性。

重大的營運中斷發生在稍後，當時主要的用戶端平台開始將隨機化套用到網路關聯（association），並將其作為預設的隱私行為。自此，MAC 不再是用於註冊、原則執行和報告的可靠錨點。原本容忍隨機探測的系統管理員，突然必須在作用中的工作階段中處理隨機產生的身份。

這種區別至關重要。探針隨機化主要影響的是觀察者。而關聯隨機化則會直接影響您每天依賴的系統。

各家作業系統也採取了不同的發展路徑。Apple 早期就推動了強大的預設隱私設定並持續改進。Android 採取了相同的大方向，但行為仍因供應商、晶片組和管理政策而異。Windows 通常最為複雜，特別是在桌上型電腦或筆記型電腦於受管的企業 SSID 與非受管的訪客或家用網路之間移動時。

截至 2026 年各作業系統的 MAC 隨機化行為

作業系統	預設行為	隨機化範圍	管理員注意事項
iOS	在現代 WiFi 網絡上預設為啟用	通常為每個 SSID 持續固定	強效隱私預設。除非明確管理該 SSID，否則舊版基於 MAC 的控制通常會失效。
Android	在現代版本上預設為啟用	通常為每個 SSID，部分因裝置與策略而異	品牌商之間的差異很重要。請分別測試 Samsung、Pixel、Zebra 及其他機隊類型。
Windows 10 and 11	因設定檔與裝置功能而異	可基於設定檔，並提供選用的輪替行為	注意混合使用的筆記型電腦。公司 SSID 可能需要受管理的設定，而訪客 SSID 則可保持隱私友善。

為什麼這個時間表在營運上至關重要

許多企業設計仍反映出過渡時期的假設。團隊可能還記得隨機化「主要是掃描問題」，卻低估了在新版 OS 發佈、使私有 MAC 成為正常關聯行為的一部分後所帶來的改變。這就是為什麼舊有的 MAB 工作流程、特定裝置的 DHCP 保留，以及與 MAC 綁定的訪客記錄，在用戶端停止配合運作很久之後，仍然留在生產環境中的原因。

這也是更廣泛隱私趨勢的一部分，而非孤立的 WiFi 特例。Apple 的 iCloud Private Relay 隱私模型 也指向了同一個方向。終端供應商正在減少整個技術棧中的被動識別碼，這意味著網路團隊需要採用能夠在這種轉變中生存下來的身份識別方法。

實際的因應方式並非將永久硬體身分強加回設計中，而是將信任決策移至堆疊的更上層。Passpoint、基於憑證的註冊和 OpenRoaming 為管理員提供了一種穩定識別使用者和裝置的方法，而無需依賴現代平台越來越視為隱私的工廠 MAC。

如果 WiFi 設計依賴永久的硬體位址來辨識用戶端，那麼該設計就已經過時了。與試圖重新奪回 MAC 可見性相比，基於身分的存取能為您提供更為順暢的途徑。

隨機化如何干擾網路營運

描述這種損害最直白的方式是：隨機化切斷了「看到裝置」與「認識裝置」之間的舊捷徑。一旦這個捷徑消失，幾種常見的營運實踐就會同時瓦解。

根據 CUJO 針對網路服務營運商受影響情況的分析，超過 30% 的行動裝置預設啟用 MAC 隨機化，這會在實體裝置與其回報的 MAC 之間建立 1 對多關係，進而使得獨特裝置計數變得複雜，並干擾分析和個人化體驗。

不再可靠的安全控制措施

最先受到波及的通常是基於 MAC 的控制措施：

• MAC ACL 失去意義： 裝置可能會呈現與您核准的位址不同的位址。
• MAB 類型的控制工作流程變得脆弱： 白名單的穩定性僅取決於它所包含的識別碼。
• 靜態 DHCP 保留失效： 保留對象是使用者端可能不再使用的位址。
• 舊版 iPSK 對應變得支離破碎： 單一使用者或單一手機看起來可能像多個端點。

這並不總是會發出明顯的錯誤警告。這也正是其營運成本高昂的原因。團隊會看到間歇性的存取抱怨、策略不匹配或套用的裝置角色不一致，而根本原因往往隱藏在症狀的深一層之下。

變得難以信任的分析數據

對於場域而言，分析所受到的影響往往是最顯而易見的業務問題。客流量、停留時間、回訪率以及路徑分析，都仰賴一定程度的信心，以確認重複觀察到的資料屬於同一個實體。隨機化削弱了這種信心。

購物中心可能依然擁有龐大的人流量，但重複到訪率看起來可能偏低，因為以前熟悉的行動裝置現在會以新的識別碼出現。飯店可能會誤以為網路上的首次訪客比實際情況更多。醫療保健場所可能難以乾淨地將員工移動性與訪客活動分開。

如果您的團隊依賴存在感與行為報告，這份 WiFi 分析指南 對於最可能受到影響的指標而言，是一個非常有用的參考。

隱藏在顯眼處的使用者體驗問題

一些最棘手的問題發生在驗證的邊緣：

• Captive Portal 可能會無預警地重新提示使用者
• 多次造訪之間的重新驗證流程變得不一致
• 疑難排解變得更慢，因為昨天的 MAC 不是今天的 MAC
• 裝置歷史紀錄零碎地分散在支援中心記錄中

當射頻（RF）訊號正常，而真正的故障在於身分的連續性時，營運團隊通常會將此描述為「不穩定的 WiFi」。

可用於偵測與緩解的實用技術

如果您不先將問題量化，就無法實現網域的現代化。眼前的目標並非消除隨機化，而是識別隨機化出現在哪裡、哪些工作流程依賴穩定的 MAC，以及哪些 SSID 暴露的風險最高。

從您已在執行的工具中進行偵測開始

大多數企業級 WLAN 堆疊已經暴露出足夠的遙測數據來發現隱私位址。在 Meraki、Aruba、Mist、Ruckus 和類似平台中，檢查用戶端列表、驗證失敗和工作階段歷程記錄，以尋找本地管理 MAC 模式。如果使用網路存取控制或策略引擎，請將其與 RADIUS 記錄進行比對。

請留意以下三點：

1. 第二個十六進位字元為 2, 6, A 或 E 的用戶端
2. 與同一使用者相關但 MAC 位址不同的重複登入失敗
3. 特定 SSID 的異常狀況，特別是出現在訪客、BYOD 和共享式住宅網路上

簡單的內部審查通常會發現，隨機化並非均勻分佈。訪客 SSID 通常最先顯現此情況。當未託管或輕度託管的裝置加入時，員工 SSID 開始出現痛點。多租戶環境通常受到的衝擊最大，因為網路試圖同時支援消費型裝置和策略執行。

決定在何處進行封鎖是合理的

許多團隊接下來會問同一個問題：我們應該封鎖隨機化的 MAC 嗎？坦白說，在極少數的情況下，將其作為暫時性的控制措施可能很有用，但這並非長久之計。

在以下情況下，封鎖會有所幫助：

• 企業 SSID 需要嚴格的託管裝置狀態評估
• 您需要在部署替代方案的同時，保留舊有的工作流程
• 基於合規或營運原因，特定裝置類別必須使用已知的固定識別

在以下情況下，封鎖通常會適得其反：

• SSID 為公開、面向訪客或高流動率
• 使用者不易理解如何停用該功能
• 您的支援團隊沒有配備足夠的資源來指導每種 OS 版本
• 您需要無摩擦的存取，而非另一個例外處理途徑

權衡很簡單。封鎖雖然能恢復部分控制權，但通常會降低使用者體驗，並產生本可避免的支援開銷。

當今行之有效的戰術性緩解措施

短期緩解措施如果能為適當的重新設計爭取時間，那麼就值得採用：

• 按使用案例進行區隔： 將受管理的員工存取與訪客及 BYOD 存取分開。
• 在您控制裝置之處使用 MDM： 在公司 SSID 上推送網絡設定檔，而不是依賴使用者手動變更隱私設定。
• 淘汰依賴 MAC 的假設： 稽核 DHCP 保留、NAC 捷徑與裝置專屬規則。
• 建立例外工作流程文件： 如果醫療裝置、印表機或主控台需要穩定的身分識別，請將其視為特定例外，而非預設模型。

這些修正方法都無法解決底層的身份識別問題。它們只是防止問題蔓延到營運的每個角落。

以基於身份識別的網路擁抱未來

應對 MAC 隨機化最強大的方法，就是停止將 MAC 位址視為信任的核心。這是根本性的架構轉變。基於身分識別的網路將決策點從可變的硬體代記，轉移到網路可以信賴的對象：使用者、憑證、目錄物件、裝置狀態決策，或是聯盟註冊狀態。

為什麼 Passpoint 和 OpenRoaming 能改變局面

因此，Passpoint 與 OpenRoaming 不僅僅是便利的功能。它們減少了對 Captive Portal 和共享密碼的依賴，並讓網路在傳統的訪客工作流程開始之前就做出信任決策。

這非常重要，因為 72% 的英國行動裝置現在預設會隨機分配 MAC，而缺乏妥善支援的網路可能會面臨高達 40% 的首個封包驗證失敗率。同份 IETF 草案指出，實施包含 ANQP 隨機化提示的 Hotspot 2.0，可以減少 35% 的重新關聯，這也是為什麼對於規劃訪客和住宅環境的架構師而言，這份關於 MAC 位址隨機化的 IETF 草案 非常值得仔細閱讀。

Passpoint 將模型從「這個 MAC 是誰？」轉變為「此裝置是否具有此網絡的有效上線關聯？」。這是一個好得多的切入點。

現代化設計的外觀與運作方式

一個實用的架構通常具備以下特點：

• 訪客存取使用 Passpoint 或 OpenRoaming： 使用者只需驗證一次，並在再次造訪時，從第一個封包開始即獲得加密連線。
• 員工存取使用目錄支援的身分識別： Microsoft Entra ID、Google Workspace 或 Okta 可圍繞個人與受管理裝置狀態來錨定存取權限。
• 憑證在可行之處取代共用金鑰： 它們的擴充性更好，且在隱私變更時，其存留度遠比绑定 MAC 的邏輯更為乾淨。
• 舊版裝置可獲得受控的例外通道： iPSK 對於印表機、IoT 和不便處理的端點仍有一席之地，但不應由其來定義您整個存取模型。

為什麼這比試圖走回隱私回頭路更好

您可以花費數月的時間說服使用者關閉隱私功能、為每款手機型號編寫知識庫文章，並在每次作業系統更新後追查不一致的行為。或者，您可以將網路轉移到預設假設用戶端會保護其身分的設計上。

第二條路徑更具永續性，同時也能提升安全性。共享密碼、脆弱的 Captive Portal 和 MAC 查找一直都是妥協的產物。隨機化只是暴露了這些妥協有多麼脆弱。

目標並非恢復舊有的可見性模式，而是建立一個不再需要該模式的網路。

關於 MAC 隨機化的常見問題

MAC 隨機化是提高安全性，還是僅提升隱私性

主要是出於隱私考量。這有助於透過隱藏永久硬體位址來防止跨網路追蹤。它無法自動證明使用者是受信任的、裝置是合規的，或者工作階段是安全的。這就是為什麼身分、憑證和狀態控制依然非常重要的原因。

我們應該要求使用者停用它嗎

僅在少數情況下。對於企業 SSID 上受託管的員工裝置，如果該設定是透過 MDM 推送並與明確的策略相綁定，這可能是合理的。而對於訪客、住戶或臨時訪客，要求人們停用隱私功能通常會導致不良的體驗和支援負擔。

為什麼學生宿舍和建設後出租（Build-to-Rent）受到的衝擊如此嚴重

因為這些環境通常混雜了消費級裝置、舊式註冊模式，且對支援服務極度敏感。在英國，根據 這篇關於隨機化 MAC 位址問題的指南，「租賃專用」（Build-to-Rent）與學生宿舍的 WiFi 存取投訴激增了 31%，其中有 55% 的投訴與隨機化 MAC 導致 iPSK 政策破碎化有關。

在多租戶環境中什麼最有效

將問題分流處理。針對居民和員工使用基於身分的引導流程，對舊版例外狀況進行嚴格控制，並避免圍繞著持久性 MAC 可見性來進行設計。場域對 iPSK 作為萬能方案的依賴度越高，隨著用戶端隱私功能的擴展，系統就會變得越脆弱。

---

如果您正在圍繞身分識別而非硬體位址，重新思考訪客、員工或多租戶 WiFi，Purple 正是為此轉變而打造。它支援 Passpoint 和 OpenRoaming，並與 Microsoft Entra ID、Google Workspace 和 Okta 整合，協助將共用密碼和 Captive Portal 的摩擦，替換為適用於飯店、零售、醫療保健、交通和住宅環境的安全、無密碼存取。