紐西蘭第二大行動與固網營運商 2degrees（其固網骨幹源自前 Snap 網路）被證實正在干擾（scrambling）經由 TCP 443 通訊埠進入用戶端 WatchGuard Firebox 的 SSL VPN 連線。 受害 IT 管理員回報，使用 2degrees 光纖的遠端使用者無法從 Firebox 下載組態設定、無法建立連線，或即使連線成功，遠端桌面協定（RDP）也會出現嚴重遲滯。值得注意的是，切換至標準 OpenVPN `.ovpn` 檔案連線並未解決問題，唯有徹底將流量繞道至該用戶端作為備援線路的 Voyager 光纖線路，連線才恢復正常。
此一故障目前影響約六名 Starlink 衛星網路使用者，以及兩名使用企業級託管光纖但無法確認上游供應商身分的用戶。技術社群推測，故障根源可能在於2degrees 內部骨幹網路（BNG 至核心網路之間）疑似採用 GRE 通道進行路由，導致 MTU 封包大小產生碎片化或被中間設備丟棄。2degrees 自助服務平台雖提供關閉通訊埠過濾（Port Filtering）的選項，但帳號往往被轉發至位於奧克蘭的第三方行動經銷商，缺乏第一線技術回應能力。
這起事件本質屬於「網路基礎設施除錯事件」，並非傳統意義上的地緣政治或企業壟斷利益角力，其核心矛盾在於網路技術演進遺留的相容性陷阱。因此，應從歷史脈絡與技術原理進行深度拆解，而非強行套用政商陰謀論。
一、歷史遺產的幽靈：Snap 網路併購後的整合陣痛
2degrees 於 2010 年代透過併購 Snap（後更名為 2degrees Broadband）取得全國性的 DSL 與 UFB 光纖骨幹。Snap 原本在 Invercargill 等偏遠地區以自有寬頻網路閘道器（BNG）佈建，並透過 GRE 通道（Generic Routing Encapsulation）將流量回送至奧克蘭的核心機房。這種「買一送一」的網路架構雖然短期內可快速擴展覆蓋率，卻也讓 GRE 通道的 MTU 處理成為長年的技術負債。當新一代防火牆（如 WatchGuard）與 VPN 加密協定預設使用標準 1500 位元組 MTU 時，內部骨幹若夾帶額外的 GRE 封裝標頭（通常為 24 至 50 位元組），便會觸發封包碎片化或黑洞路由。
二、CGNAT 與 Port Filtering 的雙重夾擊
另一個結構性誘因在於IPv4 位址枯竭迫使 2degrees 大規模啟用 CGNAT（Carrier-Grade NAT），並預設開啟商業用戶端的「通訊埠過濾」功能以緩解安全威脅。CGNAT 雖然讓多位用戶共用同一個公開 IP，卻會導致 IPSec 或 SSL VPN 的 NAT 穿透（NAT-T）失敗；而 Port Filtering 則會直接丟棄非標準的入站封包。這也是為何 Starlink 使用者會出現 VPN 不穩、遊戲連線與 BT 下載異常等「CGNAT 前兆症狀」。
三、底層成因與深層意涵
此事件揭示了已開發市場電信業者在後併購時代面臨的營運挑戰：當核心網路仍由多重異質技術疊床架屋時，任何資安設備的更新（如 WatchGuard 韌體變更）都可能瞬間引爆骨幹相容性危機。同時，缺乏專業企業支援窗口的問題，也凸顯出電信業者在「批發給行動經銷商」商業模式下的服務斷層。
在比對 2010 年代各地電信業者在 4G 轉 5G、骨幹光纖升級時出現的類似大規模 VPN 故障事件後，可預測以下三種未來情境：
針對此類電信骨幹級故障，IT 決策者應採取以下分層行動：
01 起因觸發：2degrees 內部骨幹（Snap BNG 至核心網路）的 GRE 通道 MTU 處理異常或 Port Filtering 政策異動
02 一階傳導：使用 WatchGuard SSL VPN 的企業遠端員工出現 RDP 遲滯與連線失敗，生產力直接受損
03 二階擴散：採用相同 GRE 骨幹架構的 WatchGuard、SonicWall 用戶群開始大規模排查，新興市場資安部署複雜度上升
04 宏觀終局：紐西蘭 IT 社群重新審視電信骨幹相容性問題，加速企業用戶從 CGNAT 與老舊光纖遷移至 Starlink 與新世代 ISP
因果網路圖譜 3 節點
可拖曳節點 · 點兩下開啟文章