管理學生宿舍中的公網 IP 耗盡問題
本指南為網路架構師提供權威的技術參考，介紹如何部署電信級 NAT (CGNAT) 與連接埠位址轉譯 (PAT)，以解決高密度學生宿舍和多租戶 WiFi 環境中的 IPv4 耗盡問題。內容涵蓋 NAT444 架構、RFC 6598 共享位址空間、連接埠區塊分配 (PBA) 規劃、符合 GDPR 規範的記錄策略，以及雙棧 IPv6 遷移路徑。對於在受限的公網 IP 池上管理數百或數千個同時連線裝置的任何營運商而言，本指南至關重要，可提供具體可行的配置指導、真實案例研究和投資報酬率 (ROI) 分析。
Video overview
收聽此指南
查看播客逐字稿
核心系列的一部分：多租戶 WiFi 指南 →
Student housing and MDU CGNAT capacity planner
Calculate subscriber-to-public-IP ratios, Port Block Allocation (PBA) sizing, session table memory footprint, and IPv4 market cost savings for high-density multi-tenant networks.
Network parameters
執行摘要
隨著 IPv4 位址枯竭的速度加快，在密集的多租戶環境中 - 例如學生宿舍、餐飲旅宿 和大型公共場所 - IT 經理和網路架構師正臨顯著的營運挑戰。一個擁有 1,000 名居民的單一學生宿舍區，就能產生超過 7,000 個同時連線的 IP 裝置。標準的連接埠位址轉換 (PAT) 架構在此規模下會失效，導致連接埠枯竭、連線中斷以及使用者體驗下降。
本技術參考指南概述了使用 NAT444 模型部署電信級 NAT (CGNAT) 以管理 IP 枯竭的架構與部署。透過利用 RFC 6598 共享位址空間並實施策略性連接埠區塊分配 (PBA)，網路營運商可以實現高訂閱用戶密度 - 每個公用 IP 最多可支援 128 個用戶 - 同時保持對 GDPR 和合法攔截法規的合規性。對於使用 Guest WiFi 和 WiFi Analytics 等平台的場所，強大的 CGNAT 架構可確保穩定的連線能力和精確的數據收集，而無需購買額外 IPv4 位址區塊的資本支出 (CapEx)。
技術深入探討
學生宿舍的規模化難題
現代學生宿舍中的設備密度幾乎是其他任何託管網路環境都無法比擬的。單一住宿生通常會連接智慧型手機、筆記型電腦、智慧電視、遊戲主機以及至少一個智慧家居設備。以每位住宿生擁有五到七台設備計算，一個擁有 1,000 個床位的校區所產生的同時線上工作階段負載，甚至讓同等規模的飯店都相形見絀。使用模式更讓這一挑戰雪上加霜：晚間尖峰時段（18:00 - 23:00）在遊戲、視訊串流和社群媒體上幾乎同時出現高頻寬活動，且所有設備都保持著持續的背景連線。
IPv4 位址空間在區域網際網路註冊機構（RIR）層級已實際枯竭。管理歐洲和中東分配的 RIPE NCC 已於 2019 年達到了其最後的 /8 分配政策。在公開市場上取得額外公共 IPv4 網段的成本目前介於每個位址 40 到 60 美元之間 - 對於管理數百個子網路的任何營運商而言，這都是一筆令人望而卻步的資本支出（CapEx）。
標準 PAT 的限制
在傳統的單一站點佈署中，連接埠位址轉換（PAT）會將整個私有區域網路（RFC 1918 空間：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）對應到單一公共 IP 位址。單一 IPv4 位址在 TCP 和 UDP 中擁有 65,535 個可用連接埠。雖然這對於小型辦公室來說已經足夠，但在高密度的學生宿舍中，背景應用程式（雲端同步、即時通訊平台、串流服務）的激增意味著單一用戶可以輕鬆消耗數百個同時線上的連接埠。當 PAT 邊緣路由器耗盡其可用連接埠時，新的工作階段請求將會被無聲捨棄。這表現為應用程式逾時、VoIP 通話失敗以及客服工單的增加。
CGNAT (NAT444) 架構
為了突破單一層級 NAT 的限制，企業網路必須採用電信級 NAT 架構，特別是 NAT444 模型。這個名稱是指轉換鏈中涉及的三個 IPv4 位址空間層級。
第 1 層 - CPE / 存取點層： 為訂戶設備分配 RFC 1918 空間（例如 192.168.x.x）中的私有 IP 位址。存取點或用戶端設備（CPE）執行第一次 NAT 轉換。
第 2 層 - CGNAT 閘道器： CPE 將私有 RFC 1918 位址轉換為 RFC 6598 共用位址空間（100.64.0.0/10）。此中間空間專門保留用於服務提供商基礎設施與 CGNAT 閘道器之間。使用 RFC 6598 代替另一個 RFC 1918 範圍，可防止在複雜的多租戶環境中發生位址重疊和路由衝突。
第 3 層 - 公共網際網路： CGNAT 閘道器執行從 RFC 6598 位址到共用公共 IPv4 位址的最終轉換。這就是外部服務所能看到的位址。
埠區塊分配：關鍵設計決策
在 CGNAT 部署中，最關鍵的組態選擇是埠分配策略。存在兩種方法：
動態埠分配 (DPA)： 從共享池中按每個工作階段分配埠。這能最大限度地提高埠利用效率，但每次工作階段建立和終止都會產生一條記錄 - 在大規模部署時會造成巨大的合規和基礎架構負擔。
埠區塊分配 (PBA)： 在訂戶發起第一個工作階段時，為其分配一個連續的埠區塊。該區塊將保持分配狀態，直到訂戶的工作階段結束。這種方法僅在分配和釋放區塊時產生記錄，可減少高達 98% 的記錄量。
| 組態參數 | 建議值 | 原理 |
|---|---|---|
| 每個訂戶的埠數 (PBA 區塊大小) | 500 | 足以滿足現代網路應用程式的使用，且不會耗盡位址池 |
| 每個訂戶的最大同時工作階段數 | 2,000 | 防止單一受感染的裝置耗盡位址池 |
| 工作階段逾時 (TCP 已建立) | 7,440 秒 (RFC 5382) | 符合 IETF 對 NAT 行為的建議 |
| 工作階段逾時 (UDP) | 300 秒 | 防止過期的 UDP 對應佔用埠空間 |
業界基準： NFWare 是一家在 100 多個 ISP 中擁有部署經驗的專業 CGNAT 廠商，建議每個公共 IP 最多容納 128 個訂戶，且每個訂戶分配 500 個埠。超出此限制 - 例如將每個 IP 延伸至 256 個訂戶且每個訂戶僅分配 250 個埠 - 會大幅增加高峰負載期間工作階段中斷的風險。
雙堆疊 IPv6 作為長期轉移路徑
CGNAT 是一種緩解策略，而非永久解決方案。正確的架構方向是雙堆疊部署：原生執行 IPv6，並與使用 CGNAT 的 IPv4 並行。現代裝置和主要 CDN（Google、Netflix、Meta、Cloudflare）在可用時會強烈偏好使用 IPv6。在配置良好的雙堆疊環境中，60% 至 70% 的總流量可以分流到 IPv6，從而大幅減輕 IPv4 CGNAT 池的負載，並延長其有效使用壽命。
對於傳承裝置支援至關重要的 醫療保健 和 交通運輸 環境，雙堆疊也提供了一條清晰的轉移路徑：支援 IPv6 的裝置可進行原生轉移，而僅支援 IPv4 的舊型裝置則能透過 CGNAT 繼續運作，不會對使用者造成任何干擾。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。
實作指南
步驟 1：稽核您目前的 IP 分配與裝置密度
在部署 CGNAT 之前，請先建立一個基準。從您現有的網路管理系統中收集以下資料：
- 每個子網段的尖峰同時線上裝置數量
- 每個裝置的平均與尖峰工作階段數
- 目前的公用 IP 使用率百分比
- 現有的 NAT 逾時設定
這些資料將直接決定您的 PBA 區段大小與公用 IP 池的需求。
步驟 2：設計 RFC 6598 傳輸網路
分配 100.64.0.0/10 區段給電信級傳輸網路。規劃子網路劃分以符合您的校園拓撲 - 通常每個建築物或存取層區段使用 /24 或 /23。確保您的路由基礎架構不會將 RFC 6598 前綴洩露至公用網際網路或對等互連夥伴。
步驟 3：部署與設定 CGNAT 閘道器
CGNAT 閘道器通常是專用硬體設備，或是執行在通用伺服器硬體上的虛擬化網路功能 (VNF)。關鍵設定參數如下：
- NAT 池： 將您的公用 IPv4 區段分配給 NAT 池。確保該池的大小適合您的目標訂戶對 IP 比率。
- PBA 設定： 將區段大小設定為 500 個連接埠。將每個訂戶的最大區段數設定為 1 (當訂戶用盡其初始區段時，可選擇將其擴展至 2，而非增加基礎區段大小)。
- 記錄： 設定傳送至 SIEM 的 syslog 輸出。使用 PBA 時，每個記錄項目會記錄：訂戶內部 IP、分配的公用 IP、分配的連接埠區段起點、區段終點、分配時間戳記以及釋放時間戳記。
- 工作階段限制： 對每個訂戶套用最多 2,000 個同時工作階段，以防止濫用。
步驟 4：與身分識別與驗證層整合
在採用 Guest WiFi 平台的環境中，Captive Portal 驗證必須發生在 Level 1 NAT 邊界或之前。這可確保身分識別提供者在流量彙整到 CGNAT 池之前，能將 MAC 位址與使用者憑證精確對應到唯一的內部 IP 位址。Purple 的平台在存取點層級處理此問題，維持清晰的使用者與 IP 繫結關係，並在整個 NAT 轉換鏈中持續保留。
對於無密碼存取部署 - 如 How a WiFi Assistant Enables Passwordless Access in 2026 中所述 - 適用相同的原則：身分識別繫結必須在 CGNAT 閘道器的上游建立，以確保精確的工作階段歸屬。
步驟 5：設定 IPv6 雙堆疊
在所有存取點上啟用 IPv6，並透過 DHCPv6 或 SLAAC 為每個 VLAN 分配 /64 前綴。透過您的上游供應商宣告 IPv6 路由。在縮減 IPv4 NAT 池的大小之前，請確認主要 CDN 流量 (Google、Netflix、YouTube) 均已解析為 AAAA 記錄並透過 IPv6 路由。
最佳實踐
盡可能實施確定性 NAT (Deterministic NAT)。 確定性 NAT 在訂閱者的內部 IP 位址與其獲分配的公用 IP 和連接埠區塊之間，使用演算法進行對應。由於這種對應關係可透過數學計算得出，因此無需維護或記錄工作階段表 - 在需要進行合法攔截時，可以按需對該對應關係進行反向工程。這是符合合規要求部署的金科玉律。
分散 CGNAT 閘道負載。 避免將所有 CGNAT 流量集中通過單一設備。將閘道分散部署在校園或建築物中，以防止單點故障。分散式閘道還能減輕 IP 商譽風險：如果公用 IP 池中的某個 IP 因可疑流量模式而被 CDN 標記（例如出現 CAPTCHA 問題），則只有一部分使用者會受到影響。
主動監控 IP 商譽。 訂閱 IP 商譽資訊（例如 Spamhaus、SURBL）並監控您的公用 NAT 池 IP。維持一個備用的乾淨 IP 池，以便在活動位址被列入黑名單時進行輪替。這在學生宿舍中尤為關鍵，因為少數使用者可能會進行觸發濫用標記的活動。
強制執行每個訂閱者的工作階段限制。 嚴格限制每個訂閱者最多 2,000 個並行工作階段，可防止單一受感染的裝置 - 例如參與 DDoS 放大攻擊的裝置 - 耗盡分配給該公用 IP 的整個連接埠區塊。有關監控網路效能的更多詳細資訊，請參閱我們關於如何測量 WiFi 訊號強度和覆蓋範圍的指南。
結合 802.1X 進行存取控制。 在存取層部署 802.1X 埠存取控制，可確保只有通過驗證的裝置才能獲得 IP 分配。這降低了未授權裝置消耗連接埠分配的風險，並為合法攔截目的提供了清晰的稽核軌跡。
疑難排解與風險緩釋
記錄與合規負擔
在英國和歐洲，根據 GDPR 和 2016 年調查權力法案（Investigatory Powers Act 2016），網路營運商必須能夠在特定時間戳記將公用 IP 位址和連接埠號碼追溯到特定使用者。這是一項不可妥協的法律義務。
風險： 使用動態 CGNAT，記錄每次工作階段的建立和關閉每天會產生數 TB 的系統記錄 (syslog) 資料。一個擁有 1,000 名使用者的動態分配部署每天會產生 5 億條記錄項目。這會使 SIEM 基礎設施超出負荷、增加儲存成本，並使法證調查變得不切實際。
緩釋措施： 連接埠區塊分配 (PBA) 可減少高達 98% 的記錄量。使用 PBA，您只需記錄區塊分配和釋放事件 - 通常每個使用者工作階段只需兩條記錄項目，而不是數百或數千條。確保您的 SIEM 將這些記錄保留至少 12 個月，以符合英國的資料保留要求。
CAPTCHA 與 IP 商譽問題
當 128 個使用者共用單一公用 IP 時，累計的流量可能會觸發各大網站的限速或防機器人保護機制。Google 的 reCAPTCHA、Cloudflare 的機器人管理以及類似系統，都會使用基於 IP 的啟發式演算法，這可能會將共用的 CGNAT IP 誤判為機器人來源。
**緩解措施：**將您的 CGNAT 位址池分配到多個公用 IP 上。主動監控信譽評分。考慮部署 DNS-over-HTTPS (DoH) 或 DNS-over-TLS (DoT)，以防止基於 DNS 的信譽問題。向使用者說明，在共用 IP 環境中，偶爾出現 CAPTCHA 驗證提示是已知行為。
應用程式相容性問題
某些應用程式（特別是點對點通訊協定、特定 VoIP 實作和較舊的遊戲平台）依賴持續性的連接埠對應或入站連線發起。這些在雙重 NAT 下可能會無法運作。
**緩解措施：**針對 VoIP，請確保您的 CGNAT 閘道支援適用於 SIP 的 ALG (Application Layer Gateway)。針對遊戲，請考慮實作 UPnP 代理或配備獨立、低密度 NAT 位址池的專用遊戲 VLAN。對於銷售時點情報系統需要入站連線的 零售 環境，請將這些裝置放置在完全繞過 CGNAT 層的獨立 VLAN 上。
投資報酬率與商業影響
資本支出 (CapEx) 節省
部署 CGNAT 可提供立即且實質的 CapEx 節省。以每個 IPv4 位址 50 美元的市場價格計算，一所擁有 5,000 個床位、需要 1:1 裝置與 IP 比例的大學，需要購買大約 35,000 個 IP 位址，成本達 175 萬美元。透過部署比例為 128:1 的 CGNAT，相同的部署只需要不到 300 個公用 IP，將 IP 購置成本降低至約 15,000 美元。
即使將 CGNAT 閘道硬體或虛擬化網路功能的成本（校園規模部署通常為 20,000 至 80,000 美元）計算在內，淨節省金額依然非常可觀。
營運支出 (OpEx) 減少
穩定的連線能力能直接減少技術支援中心的負擔。連接埠耗盡事件（大規模標準 PAT 的主要故障模式）會產生大量的支援工單。配置完善且具有適當工作階段限制與 PBA 的 CGNAT 部署可消除此故障模式，預估可減少 30% 至 40% 與網路相關的技術支援中心工作量。
學生宿舍的競爭優勢
在競爭激烈的學生宿舍市場中，網路品質是潛在租戶的首要篩選標準。營運商若能展示穩定且高吞吐量的連線能力（透過 WiFi Analytics 儀表板驗證，顯示運作時間、工作階段品質和裝置密度指標），就能獲得更高的租金收益並實現更高的入住率。這種基礎設施的穩定性也是部署先進定位服務的基石，正如 Purple launched offline maps mode for seamless, secure navigation for WiFi hotspots 中所強調的。
案例研究 1：擁有 800 個床位的大學宿舍
一間由英國大學營運、擁有 800 個床位的宿舍在晚上尖峰時段經常遇到連線問題。調查發現，其單級 PAT 設定使用的是 /29 公共子網路（6 個可用 IP），每天晚上 19:30 就會耗盡所有可用連接埠。該營運商部署了具有 PBA 的 CGNAT 解決方案（每位訂戶 500 個連接埠，每個 IP 128 位訂戶），升級為 /27 公共子網路（30 個可用 IP），並啟用了 IPv6 雙疊。部署後的指標顯示，與最初的動態分配試點相比，連接埠耗盡事件減少了 94%，與網路相關的服務台工單減少了 38%，CGNAT 記錄磁碟區減少了 65%。在部署後的 60 天內，IPv6 卸載率達到了 62%。
案例研究 2：擁有 1,200 間客房的專用學生宿舍 (PBSA) 營運商
一家在兩個英國城市管理三個站點的私人 PBSA 營運商，需要在開設第四個站點之前標準化其網路架構。他們現有的基礎設施混合使用單級 NAT 和臨時 VLAN 分段，且沒有一致的記錄策略。我們在所有三個站點實作了採用確定性 NAT 的 CGNAT 部署，實現了可透過數學計算的訂戶對 IP 對應，而無需承擔工作階段記錄開銷。這種方法在合法攔截合規性方面滿足了營運商法律團隊的要求，消除了工作階段記錄的 SIEM 儲存成本，並為第四個站點提供了標準化的架構範本。該營運商還整合了 Purple 的 Guest WiFi 平台以進行 Captive Portal 驗證，在 CGNAT 閘道上游建立身分綁定，以確保分析報告中精確的使用者歸因。
關鍵定義
CGNAT (Carrier-Grade NAT)
一種網路架構，營運商在集中式閘道器執行網路位址轉換，使多個用戶能夠共用單一公用 IPv4 位址。定義於 RFC 6264 和 RFC 6888。亦稱為大規模 NAT (LSN) 或 CGN。
當單一公用 IP 不足以為網路上的所有設備提供服務時，IT 團隊就會遇到 CGNAT。在學生宿舍中，CGNAT 是在不購買額外公用位址空間的情況下，管理 IPv4 耗盡問題的主要機制。
NAT444
一種特定的 CGNAT 拓撲，包含三層 IPv4 位址空間：用戶私有位址 (RFC 1918)、電信業者級共用位址 (RFC 6598) 以及公用網際網路位址。其名稱是指所橫跨的三個 IPv4 網路。
NAT444 是多租戶環境中部署 CGNAT 的標準架構。網路架構師必須瞭解這三層模型，以正確設計中間網路並避免位址重疊。
RFC 6598 共用位址空間
由 IANA 保留用於 CPE 與 CGNAT 閘道器之間中間網路的 100.64.0.0/10 IPv4 位址區塊（100.64.0.0 至 100.127.255.255）。此空間在公用網際網路上不可路由，是專為防止 NAT444 部署中的位址衝突而設計。
IT 團隊必須將 RFC 6598 - 而非 RFC 1918 - 用於中間 CGNAT 網路。在此網段使用 RFC 1918 會在用戶網路使用相同的 RFC 1918 範圍時，帶來位址重疊的風險。
連接埠區塊分配 (PBA)
一種 CGNAT 連接埠分配策略，其中在用戶的工作階段期間，向其分配一個連續的連接埠區塊（例如 500 個連接埠），而不是針對每個連線單獨分配連接埠。定義於 RFC 7422。
PBA 是符合 GDPR 規範的 CGNAT 部署之推薦方法。與動態連接埠分配相比，它可減少高達 98% 的記錄（logging）開銷，使大規模的合法攔截合規在營運上切實可行。
確定性 NAT
一種 CGNAT 設定，其中用戶內部 IP 位址與其分配的公用 IP 及連接埠區塊之間的對應關係是透過演算法計算出來的，而無需維護工作階段表（session table）。該對應關係在數學上是可逆的，因此無需檢索記錄即可識別用戶。
對於注重合規性的部署，確定性 NAT 是黃金標準。它完全消除了記錄開銷，同時滿足合法攔截的要求，因為可以使用已知演算法，從公用 IP、連接埠和時間戳記來識別用戶。
PAT (Port Address Translation)
一種網路位址轉換形式，其中多個私有 IP 位址透過使用唯一的來源連接埠號碼來區分連線，從而對應到單一公用 IP 位址。亦稱為 NAT 多載（NAT overload）或多對一 NAT。
PAT 是大多數企業邊緣路由器中使用的標準單級 NAT。它是 CGNAT 的前身，由於大規模部署時會面臨連接埠耗盡，因此不適用於密集的多租戶環境。
工作階段表 (Session Table)
由 NAT 閘道器維護的資料結構，用於記錄每個作用中連線的內部（私有）IP 位址與連接埠，以及外部（公有）IP 位址與連接埠之間的對應關係。工作階段表是 CGNAT 所消耗的主要記憶體與處理資源。
工作階段表大小是 CGNAT 閘道器關鍵的容量規劃參數。擁有 1,000 個用戶且每個用戶最多 2,000 個工作階段的部署，需要至少 200 萬個條目的工作階段表容量。工作階段表容量不足會導致連線失敗。
Dual-Stack
一種網路組態，其中 IPv4 和 IPv6 協定在同一個網路基礎架構和終端設備上同時啟用。支援 dual-stack 功能的設備在連線至支援 IPv6 的目的地時，會優先選擇 IPv6。
Dual-stack 是 CGNAT 部署中推薦的過渡策略。透過將支援 IPv6 的流量分流至原生 IPv6 路徑，dual-stack 可減輕 IPv4 CGNAT 位址池的負載，並提供向 IPv6 為主網路遷移的路徑。
RFC 1918 Private Address Space
保留給私有網路使用的三個 IPv4 位址範圍：10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。這些位址在公有網際網路上無法路由，僅用於內部網路定址。
RFC 1918 位址在 CGNAT 部署中用於訂戶設備定址。網路架構師必須確保訂戶網路中使用的 RFC 1918 範圍不會與中間 CGNAT 網路中使用的範圍重疊 - 這也是為什麼中間層要使用 RFC 6598 的原因。
Lawful Intercept
由執法機關依法授權進行的通訊攔截。在英國受 2016 年調查權力法（Investigatory Powers Act 2016）管轄。網路營運商在收到 lawful intercept 請求時，必須能夠識別與特定公有 IP 位址、連接埠和時間戳記相關聯的訂戶。
合規的 Lawful intercept 是 CGNAT 日誌記錄需求的主要驅動力。營運商必須保留足夠的日誌，以便從公有 IP 和連接埠資料中識別訂戶。PBA 和 Deterministic NAT 是兩種能在大規模環境下實現此目標，且不會讓日誌記錄基礎架構超出負荷的架構。
範例
一棟擁有 600 個床位的學生宿舍目前使用單一 /29 公網子網路（6 個可用 IP）搭配標準 PAT。在晚上尖峰時段 (19:00 - 23:00)，使用者反映出現大範圍的連線失敗。網路團隊已確認 PAT 路由器上發生連接埠耗盡。營運商有預算購買 CGNAT 閘道硬體，但無法取得 /27（30 個可用 IP）以外的額外公網 IP。請設計一個 CGNAT 部署方案，以消除連接埠耗盡問題並支援未來增長至 900 個床位。
步驟 1 - 基準評估：以 600 個床位、每位房客 5 台裝置計算，尖峰同時連線裝置數約為 3,000 台。在每個訂戶 500 個連接埠 (PBA) 的情況下，每個公網 IP 支援 128 個訂戶。利用 /27 中的 30 個可用 IP，理論上最大訂戶容量為 3,840 個 - 足以滿足 900 個床位、每位房客 4.3 台裝置的需求。步驟 2 - RFC 6598 中介網路：為中介電信級網路分配 100.64.0.0/20，為 CPE 到 CGNAT 閘道的流量提供 4,096 個位址。每個大樓翼部的子網路：100.64.0.0/24、100.64.1.0/24 等。步驟 3 - CGNAT 閘道規格規劃：部署一個工作階段表容量至少為 768,000 個項目（3,000 個訂戶 × 每個訂戶最大 2,000 個工作階段，並留有 20% 的緩衝空間）的 CGNAT 閘道。設定含有 500 個連接埠區塊的 PBA。將每個訂戶的最大區塊數設為 1，並允許超過 500 個同時連線工作階段的訂戶溢出至 2 個區塊。步驟 4 - IPv6 雙棧：在所有存取點上啟用 IPv6。透過 SLAAC 分配 /64 前綴。目標是在 90天內實現 60% 的 IPv6 卸載，這能將 IPv4 CGNAT 負載有效減少至 1,200 個同時連線的 IPv4 訂戶 - 遠在 /27 的容量範圍之內。步驟 5 - 記錄：將 syslog 設定為僅向 SIEM 傳送 PBA 區塊分配/釋放事件。記錄至少保留 12 個月。步驟 6 - 工作階段限制：在 CGNAT 閘道上對每個訂戶強制執行最大 2,000 個工作階段的限制，以防止濫用。
一家學生專用宿舍 (PBSA) 營運商使用動態連接埠分配在一個擁有 1,000 個床位的區域部署了 CGNAT。他們的法務團隊指出，目前的記錄方法每天會產生 400GB 的 syslog 資料，這讓 SIEM 負荷過重，並導致難以履行執法部門的合法攔截請求。請重新設計記錄策略，以滿足 UK GDPR 合法攔截義務，同時將記錄量減少到可管理的水平。
步驟 1 - 遷移至連接埠區塊分配 (PBA)：將動態連接埠分配替換為每個訂戶 500 個連接埠的 PBA。這能立即將日誌事件從「每工作階段一次」減少為「每區塊分配一次」和「每區塊釋放一次」。對於擁有 1,000 名使用者且每人每天平均進行 3 次區塊分配/釋放循環的部署，這每天僅產生約 6,000 筆日誌項目，與動態分配基準相比減少了 99% 以上。步驟 2 - 日誌結構：確保每個 PBA 日誌項目擷取：(a) 訂戶內部 IP 位址、(b) 分配的公網 IP 位址、(c) 分配的連接埠區塊起始與結束、(d) 區塊分配時間戳記 (UTC)、(e) 區塊釋放時間戳記 (UTC)、(f) 訂戶識別碼 (MAC 位址或 RADIUS 使用者名稱)。步驟 3 - 決定性 NAT 選項：如果 CGNAT 平台支援，請遷移至決定性 NAT。這能完全免除常規操作的日誌記錄，因為其映射可透過數學計算得出。僅針對非決定性的溢流情況保留 PBA 日誌。步驟 4 - 保留政策：將日誌在具備防竄改功能的日誌儲存空間 (例如：寫入一次的 S3 相容物件儲存空間) 中保留 12 個月。實施存取控制，使因應合法攔截請求而調閱日誌時需要雙重授權。步驟 5 - 事件回應程序：記錄回應合法攔截請求的程序，包括在決定性 NAT 下，如何根據公網 IP、連接埠和時間戳記反向計算出訂戶的公式。
某大學的 IT 團隊回報，學生在使用 Google、Netflix 和遊戲平台時，頻繁遇到 CAPTCHA 驗證挑戰和速率限制。調查顯示，有 200 名學生透過 CGNAT 共用單一公網 IP 位址。該團隊被告知短期內無法取得更多公網 IP。在不變更 IP 分配的情況下，可以立即實施哪些緩解措施？
步驟 1 - 降低訂戶密度：200:1 的比例是主要原因。即使沒有額外的公網 IP，也應檢視 CGNAT 位址池是否得到高效利用。確保完整啟用 IPv6 雙疊排 (dual-stack) - 如果 60% 的流量分流至 IPv6，則有效的 IPv4 訂戶數將降至每 IP 約 80 名，遠低於 128:1 的建議閾值。步驟 2 - IP 輪替：針對公網 IP 位址池實施輪替政策。如果 CGNAT 閘道支援，請為每個訂戶群組設定定期輪替分配的公網 IP。這可以防止任何單一 IP 累積持續性的不良信譽。步驟 3 - DNS 最佳化：確保提供給用戶端的 DNS 解析器優先傳回 AAAA 記錄。許多 CAPTCHA 觸發是基於 DNS 的 - 如果用戶端不必要地將服務解析為 IPv4 位址，則在原本可以原生使用 IPv6 的情況下，仍會透過 CGNAT 進行路由。步驟 4 - 工作階段逾時調整：針對非 DNS 的 UDP 流量，將 UDP 工作階段逾時從預設值 (通常為 300 秒) 縮短至 60 秒。這能更快釋放連接埠空間，並從外部服務的角度減少表觀的工作階段量。步驟 5 - 與受影響的平台溝通：針對持續被列入黑名單的問題，向主要的 IP 信譽資料庫 (Spamhaus、SURBL) 提交除名請求。說明該 IP 是為合法教育機構提供服務的共用 CGNAT 位址。
練習題
Q1. 一個擁有 2,000 個床位的學生宿舍園區擁有一個 /26 公有子網路（62 個可用 IP）。網路團隊正在規劃 CGNAT 部署。請計算：(a) 在推薦的 128:1 比例下可支援的最大訂戶數、(b) 可用的總連接埠容量、(c) 推薦的 PBA 區塊大小，以及 (d) 現有的 /26 是否足夠，或者是否需要額外的 IP。
提示：先從一個 /26 的可用 IP 總數開始，然後套用 128:1 的訂戶比例。將結果與 2,000 床位在實際每人設備比例下的設備數量進行比較。在最終建議中考慮 IPv6 dual-stack 的分流效果。
查看標準答案
一個 /26 提供 62 個可用公有 IP。在每 IP 支援 128 個訂戶的情況下，最大 IPv4 CGNAT 容量為 62 × 128 = 7,936 個訂戶。若按每人 5 台設備計算，2,000 個床位將產生大約 10,000 台並行設備。在沒有 IPv6 的情況下，/26 是不夠的（7,936 < 10,000）。然而，若透過 IPv6 dual-stack 實現 60% 的分流，實際的 IPv4 負載會降至約 4,000 台設備 - 遠低於 /26 的 7,936 個容量限制。推薦的 PBA 區塊大小為每個訂戶 500 個連接埠。總連接埠容量：62 個 IP × 64,000 個可用連接埠 = 3,968,000 個連接埠。若每個訂戶分配 500 個連接埠：3,968,000 / 500 = 最大 7,936 個訂戶。建議：部署啟用 PBA 的 CGNAT（每個訂戶 500 個連接埠），並將啟用 IPv6 dual-stack 作為必備前置條件，如此現有的 /26 即足夠使用。如果無法保證 IPv6 分流率高於 50%，請獲取額外的 /27 作為緩衝。
Q2. 某個擁有 500 個床位的學生宿舍所部署的 CGNAT 正在引發合規疑慮。營運商的法律團隊收到執法部門針對特定公用 IP 位址 (203.0.113.45)、連接埠 51432 於時間戳記 2025-11-15 21:47:33 UTC 的合法攔截請求。該 CGNAT 閘道器設定為動態連接埠分配。SIEM 包含 180 天的記錄，但鑑識團隊回報，從記錄中定位特定訂戶每次請求需要花費超過 4 個小時。請找出根本原因並提出能將回應時間縮短至 15 分鐘以內的補救措施。
提示：4 小時的響應時間是日誌架構導致的現象，而不是資料保留問題。請思考在動態分配與 PBA 模式下分別記錄了哪些資訊，以及 Deterministic NAT 會如何完全改變響應流程。
查看標準答案
根本原因：動態連接埠分配會針對每個工作階段產生一個記錄條目。由於 500 個使用者 × 每位使用者每小時數百個工作階段，SIEM 每天會包含數百萬個記錄條目。要透過 IP、連接埠和時間戳記定位單一條目，需要對可能多達數十億筆的記錄進行全文檢索 - 這就是需要 4 小時回應時間的原因。補救方案 1 (PBA)：移轉至連接埠區塊分配 (Port Block Allocation)。使用 PBA 時，連接埠 51432 的記錄條目會記錄區塊分配（例如，連接埠 51001 - 51500 於 21:30:00 UTC 分配給訂戶 192.168.1.23，並於 23:15:00 UTC 釋放）。對公用 IP + 連接埠範圍 + 時間戳記進行單一索引查詢，即可在數秒內傳回結果。估計回應時間：2 分鐘以內。補救方案 2 (確定性 NAT)：若平台支援，移轉至確定性 NAT (Deterministic NAT)。連接埠 51432 可以透過數學方式反向計算出訂戶的內部 IP，而無需進行任何記錄查詢。回應時間：30 秒以內。立即行動：在規劃 PBA 移轉的同時，對現有的 SIEM 記錄進行 (public_ip, port, timestamp) 索引，以縮短目前的回應時間。
Q3. 網路架構師正在為一個擁有 800 個床位的新 PBSA 開發項目設計 CGNAT 基礎架構。上游 ISP 已提供一個 /27 公用子網路，並確認 IPv6 傳輸可用。營運商還希望部署 Purple 的 Guest WiFi 平台以進行 Captive Portal 驗證。請說明 Captive Portal 驗證相對於 CGNAT 閘道器的正確部署位置，並解釋不正確的部署位置為何會帶來合規風險。
提示：請考慮 Captive Portal 需要擷取哪些資訊（使用者身分、裝置 MAC、內部 IP），以及在 NAT 轉換鏈的哪一個點上仍可取得這些資訊。思考內部 IP 位址在通過 CGNAT 閘道器後會發生什麼變化。
查看標準答案
Captive Portal 驗證必須發生在第 1 層 NAT 邊界或之前 - 也就是在存取點或 CPE 層，在流量進入 RFC 6598 中間網路之前。正確部署位置：Purple 的 Guest WiFi 平台在存取點對使用者進行驗證。平台記錄以下綁定關係：使用者身分 → MAC 位址 → RFC 1918 內部 IP → 時間戳記。此綁定關係是在 CGNAT 閘道器執行其轉換之前建立的。然後，CGNAT 閘道器將 RFC 1918 IP 對應至公用 IP 和連接埠區塊，且 PBA 記錄會記錄：RFC 1918 IP → 公用 IP → 連接埠區塊 → 時間戳記。這兩個記錄條目可以透過 RFC 1918 IP 和時間戳記進行關聯，以產生完整的鏈結：使用者身分 → 公用 IP + 連接埠。不正確的部署位置（Captive Portal 位於 CGNAT 閘道器之後）：如果驗證發生在 CGNAT 閘道器之後，平台只能看到公用 IP 和連接埠 - 而看不到內部 IP。此時，同一個 CGNAT IP 後面的多個使用者將無法區分。平台無法建立可靠的使用者與 IP 綁定，導致無法進行合法攔截歸因，並違反 GDPR 的問責制要求。這就是合規風險。透過 Purple 的架構，身分綁定是在 CGNAT 層的上游建立的，從而確保在分析平台和合規記錄鏈中都能進行精確的使用者歸因。
常見問題
What is Carrier-Grade NAT (CGNAT) and why is it needed in student housing?
Carrier-Grade NAT (CGNAT), also known as Large-Scale NAT (LSN) or NAT444, is a network architecture defined in RFC 6888 where network translation occurs at a centralised operator gateway. In dense student accommodation and multi-tenant residential buildings, thousands of student devices (laptops, phones, gaming consoles, smart TVs) quickly exhaust standard single-public-IP PAT capacity. CGNAT maps private RFC 1918 subnets across an intermediate RFC 6598 shared address space (100.64.0.0/10) to a compact pool of public IPv4 addresses, avoiding costly public IP address block purchases.
What is the recommended subscriber-to-public-IP ratio for multi-tenant CGNAT?
The industry standard golden rule for residential multi-tenant networks is a maximum ratio of 128 subscribers per public IPv4 address. When using Port Block Allocation (PBA) with a block size of 500 ports per subscriber, each public IP (providing ~63,000 usable ports from port 1024 upward) cleanly accommodates 126 subscribers with dedicated, non-overlapping port ranges, preventing session starvation during peak evening streaming and gaming.
How does Port Block Allocation (PBA) solve lawful intercept logging challenges?
Under traditional dynamic PAT, the gateway must log every single TCP and UDP session establishment and teardown to satisfy lawful intercept regulations (such as RIPA or the Investigatory Powers Act), producing terabytes of log data per week that overwhelm SIEM infrastructure. Port Block Allocation (RFC 7422) allocates a fixed contiguous block of ports (e.g., 500 ports) to a subscriber for their entire lease duration. The gateway logs only the block allocation event, reducing logging volume by up to 98%.
Why must captive portal authentication sit upstream of the CGNAT gateway?
To maintain regulatory compliance, accurate analytics, and lawful intercept audit trails, captive portal authentication and user identity binding (such as Purple Guest WiFi) must be positioned upstream on the internal Layer 2/Layer 3 access edge before traffic reaches the CGNAT translation gateway. This preserves the direct 1:1 binding between the authenticated user identity, MAC address, and internal IP address before packet headers are translated into RFC 6598 or public pool addresses.
How does deploying IPv6 dual-stack extend the life of an IPv4 CGNAT pool?
IPv6 dual-stack allows modern operating systems and major content platforms (such as YouTube, Netflix, Meta, and Google) to establish end-to-end native IPv6 connections without traversing the CGNAT translation engine. In university and student housing environments, enabling native IPv6 offloads 50% to 65% of total egress network traffic from the IPv4 translation tables, effectively doubling or tripling the capacity and lifespan of the existing public IPv4 pool.
繼續閱讀本系列
為多租戶辦公大樓設計 WiFi 網路
本指南為 IT 經理、網路架構師和 CTO 提供了一個中立於廠商的藍圖，用於在多租戶辦公大樓中設計可擴展、安全且隔離的 WiFi 網路。內容涵蓋 IEEE 802.1Q 下的 VLAN 劃分、透過 802.1X 和 RADIUS 進行的動態 VLAN 分配、高密度環境的 RF 規劃，以及 GDPR 和 PCI-DSS 下的合規性考量。場地營運商和建築經理將獲得實用的架構指導、真實案例研究，以及在部署前需要避免的配置陷阱。
平均自證清白時間：如何證明問題不在 WiFi
平均自證清白時間（MTTI）是衡量 IT 團隊花費多少時間來證明網路問題非其責任的關鍵指標。本指南詳述了一套五步驟的觀測方法論，旨在消除多租戶環境中的推諉責任現象，以共享證據取代互相指責，進而降低平均修復時間（MTTR）。
共用 WiFi 基礎設施的法律與合規性要求
本具權威性的技術參考指南概述了部署和管理共用 WiFi 基礎設施的重要法律、法規和架構要求。它為 IT 經理、網路架構師和場所營運商提供了實用的框架，以確保利用企業標準來實現強大的數據保護、嚴格的付款安全合規性以及高效能的租戶隔離。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。