南桃園 - 可能是我用過最爛也最好的網路（三）比擬商規網路的定址模式

Wayne's (Mis)adventure of NTY CATV 系列文：

（一） 前言與服務穩定性

（二） 安裝品質、設備爭議與網路穩定性

（三） 比擬商規網路的定址模式 （你在這裡）

（四） 內部作業流程缺乏整合 - Cable Modem 更換抓馬

公網 IP 提供模式

如果要說南桃園一點好都沒有，那我也不會寫「是我用過最爛也最好的網路」。最爛可能是網路上的人云亦云，還行可能只是我的幸運，但南桃園的 IP 提供方式對架設伺服器的人來說，很可能是能拿到最直覺，設定最容易的。這讓家用寬頻也可以玩出商用的彈性。

(注意！以下 Technical Babbles，TL DR; 不喜者請迴避。)

IPv4 「固定公網 IP」 提供模式

南桃園的固定 IP 提供模式是透過綁該裝置對外的 MAC 之後進行 DHCP 註冊。致使指定裝置上網開機時會自動取得固定 IP，電腦或裝置無需手動設定固定 IP。但除了必須把 WAN 設定為 DHCP 自動取得之外，其他相關連的設定（e.g., 防火牆的 Rule 等）可以比照固定 IP 的方式處理。這可以讓防火牆策略設定更有彈性，而不是死死的綁著一個裝置的某一個 WAN。舉個例子：舊版 Fortinet (6.x) 要設定虛擬 IP 對應，由於設定單位是綁 IP，而不能綁 WAN，這讓設定 Hairpin NAT (有人稱 U-Turn NAT)，變得非常容易。

這樣講得很抽象，我們舉個例子，並假設以下情境開 Virtual Server 到內部網路：

• http://nycu.waynechiu.cc -> (WAN1):80 -> 192.168.1.113:80
• http://ndhu.waynechiu.cc -> (WAN2):80 -> 192.168.1.114:80

如果是中華電信非固定制 PPPoE 撥號，由於每次取得的 IP 都是不同的，防火牆設定 Rule 時必須以接口為單位（e.g., 一個 WAN，一個 PPPoE Tunnel 等等）。以上述的例子來說，在中華電信的網路，我們必須這樣設定：在虛擬 IP 設定中，Fortinet 必須假定所有已知的 WAN IP 的 Port 都是導向到指定地點（e.g., 0.0.0.0:80 -> 192.168.x.x:80），接著設定應該生效的區域（例如：只有WAN1，或是 any）。以下是我第一個防火牆現行的設定，WAN1 是中華電信非固定制 PPPoE：

因為我們無法預料 WAN1 的 IP 會是什麼，我們只能假定所有 IP 都接受（0.0.0.0），接著接受的範圍為 WAN1。

所以我們上述的情境中，我們要設定兩組虛擬 IP:

• 0.0.0.0:80 -> 192.168.1.113:80, WAN1
• 0.0.0.0:80 -> 192.168.1.114:80, WAN2

我們假定透過 PPPoE，WAN1 與 WAN2 的 IP 如下，以及其 DDNS 對應：

• WAN1 (198.51.33.31) -> nycu.waynechiu.cc
• WAN2 (203.0.113.15) -> ndhu.waynechiu.cc

當外部使用者要存取 nycu.waynechiu.cc 或 ndhu.waynechiu.cc 時，一切都沒有問題：

1. DNS 解析 nycu.waynechiu.cc 為 198.51.33.31
2. 傳送 IPv4 TCP 要求到 198.51.33.31 的 80 Port
3. 透過 Fortigate 的 NAT Table 得知這個封包應該更改目的地，並寄送到 192.1681.113:80

但是這樣的設定換成內部使用者存取時，就會發生問題：

1. DNS 解析 nycu.waynechiu.cc 為 198.51.33.31
2. 傳送 IPv4 TCP 要求到 198.51.33.31 的 80 Port
3. Fortigate 設備發現 198.51.33.31 就是他自己（機器本身），這是因為 WAN1 的 IP 就是這個
4. 當調查虛擬 IP 表時，我們規定的對應資訊僅適用於 WAN1，沒有用於 LAN，所以送到 198.51.33.31，只好送給 Fortigate 自己。
5. Fortigate 自己本身沒有 80 Port，或者是把使用者導向路由器系統登入頁面
6. 內部使用者無法連線。

我們其實可以用虛擬 IP 來解決，其解套是虛擬 IP 規定範圍為全部（any），但這樣發生的問題又更妙了：

• 請問這個 80 是哪個 80？

由上述的例子我們能看到，這些對外部通訊都沒有問題，但是要設定內部的  U-Turn NAT 問題一堆。請問是要，HIT 到什麼的時候需要 U-Turn NAT？如果有固定 IP，那很明確，HIT 到指定 IP 就 U-Turn NAT，但如果是連 WAN IP 是什麼都不知道呢？。許多使用者受不了這種麻煩，要嗎 1. 自架內部 DNS，重新指向伺服器的內部 IP， 2. 把機器放 DMZ-NAT，放在 NAT 之外，無論哪一種對於 MIS 來說都很麻煩。（雖然我理解為什麼那些機器會這樣設計。）所以通常都會是 3. 乾脆就直接不處理。

如果今天要用南桃園有線電視的寬頻，那這樣很好解決：

• 就把 WAN IP 加上去對應資訊裡面... 不就解決了嗎...*

* 請記得要把 VIP 的 ARP Reply 功能關閉（預設是開啟的），不然會導致多 WAN 之下 DHCP 失效。設定請見：Technical Tip: ARP reply setting in Virtual IP/IP Pool，至於為什麼 DHCP 會有影響，請見：DHCP Conflicts 與 Technical Tip: Diagnosing DHCP on a FortiGate。

IPv6 提供模式

與 IPv4 相似，但是又有些不同，南桃園有線電視寬頻的 IPv6 提供模式是透過 MAC 管制的方式控制 DHCPv6 與 DHCP-PD 的範圍，以下設定要特別注意，因為跟其他很不同：

• WAN IPv6 的取得是 DHCPv6，不是常見的 SLAAC
• LAN IPv6 區段的取得則是十分典型的 DHCP-PD，至於往下的 IPv6 怎麼發放... 你家的事（看你要 SLAAC 或是 DHCPv6 都行）

備註：有些裝置是不支援 DHCPv6 的，這包含所有 Android 裝置，部分的網路分享器與 IoT 設備，要特別注意。（想想看，SLAAC 只需要一個 Hash Function 跟 ND 就可以自己生成位置... 反觀 DHCPv6 還要浪費空間去寫 Protocol Stack... 何必？）

而且透過觀察，其 IPv6 DHCP-PD 網段的取得似乎跟時間有關係（簡言之，如果你沒有超過兩個禮拜都不開機，那拿到的網段都一樣。）這對於架站來說，等同於就是固定 IPv6。

其實就綜合上述兩點... 除了取得 IP 與 IPv6 是 DHCP 之外，其特性已經跟商用寬頻固定 IP 的特性差不多了，後來我乾脆連 DDNS 都免了...

商用寬頻的代價

回歸到伺服器經營本身，WAN IP 的易管理特性始終都非常重要。雖然中華電信至始至終都會是最穩定的選擇。但如果加上管理容易程度，設定的容易程度，擁有固定 IP 得成本等等，其實 399 這樣的價格，遠超過 100/40M 的價值。

只是要回頭觀望這整件事情來說，我是否有遺憾？也許有。

南桃園的網路上傳 50M 大概會是一個永遠的坎站。在沒有導入 Docsis 3.1 的情況之下... Full-Duplex Docsis，或者是 Even Docsis (上下載速度一樣的 Docsis) 這些都不會發生。考慮 Docsis 3.0 最大上傳只有 8 個 Binding Channel... 最大也不過接近兩百... 何況許多時候還沒有這麼多空間可以拿來做 Upstream Channel。若只有 4 個的情形之下，最大不過 122M 左右...

上載速度要向上推進... 太難太難...

如果未來網站擁有更大的流量時... 我可能只能逼著去用中華電信... 

也許我真的會懷念那個還可接受，卻特性極佳的南桃園。

但請別忘了這是家用寬頻：

但是對於「非架站、非專業、非商用」的一般使用者，這樣的 IP 提供模式一點都不是好事（請別忘了南桃園至始至終都是非商用寬頻）：

1. 客戶需要「公用 IP」時，僅只有「申請固定 IP」一途，沒有其他選項。但要知道的是，非專業用戶須使用公用 IP 的原因有很多，絕大多數根本無需固定 - 例如任何使用 UPnP 開啟通訊埠的服務介接公用網路，像是跟你最有關的：VoWiFi。「公有 IP」即「固定 IP」會增加這些使用者被針對的風險。
2. 雖然中華電信與其他一類電信業者對於非商業用戶的 IPv6 提供是透過 DHCP-PD over PPPoE 的方式，致使 IPv6 /64 的 Prefix 會隨著 PPPoE 撥入序號而更動，這卻提高了一般使用者的使用安全性。由於 IPv6 的 SLAAC 自動定址會讓子網路 bit 之後的主機 bit 是透過個別機器用固定計算模式 (e.g., EUI-64) 產生，致使每一次產生結果都一樣（舉例：若網路長度是 /64，則後面 64 bit 就是透過算而出，如果透過 Neighbor Discovery 沒有發現衝撞，則計算時 Nonce 都不會被加入。這也是為什麼 IPv6 SLAAC Privacy Extension 被提出，支援的系統會預設使用 Privacy Extension 的位置進行通訊，而 SLAAC 的位置仍然會使用，只是會變成被動使用（純 Listening，有 Hit 到才會反應），但不是每一個 OS 都支援 Privacy Extension，例如 IoT 設備，更糟的是他們的安全性比個人電腦或手機更差）。
   然而南桃園的 DHCP-PD 似乎是跟提出 PD 的裝置的 MAC 綁在一起，每次拿到的 Prefix 都一樣，不會改變，沒有 Privacy Extension 功能的裝置又會陷入固定 IP 的針對風險。

但南桃園又能怎麼做呢？

其實講歸講，但我們還是要回歸到實作面上面討論... Cable Modem 位置發放絕大多數都是在 IPoE 上面做文章，如果有用過早期的 CMTS 中的路由模組 Cisco 7280VXR，其最主要的用戶管制只有幾個：Cable Modem HFC 機器註冊，DHCP 登記管制，非註冊 MAC 阻擋。就 DHCP 本身的設計就從未考慮過「怎麼樣讓用戶每次連線都不同」，他的設計是在於發放與管理 IP。

• 不可能設定 DHCP 每數秒或更短就要重新要求一次 IP（把 TTL 設定的很短），這樣 DHCP Server 會忙死，網路上也會有太多的流量都是 DHCP 請求，而且太多機會會發生衝撞。 DHCP 的逾時與間隔是不能設定的非常短，或者是在 Pool 裡面亂跳。
• PPPoE 之所以可以這麼作，是因為 PPPoE 的斷線與連線 BRAS 是知道的，況且，PPPoE (或 PPP 本身) 的 IP 配發從來就不是 DHCP (哪個再跟我說 Hinet IP 是 DHCP 發放，我敲下去。)

- 接續 - （四）內部作業流程缺乏整合 - Cable Modem 更換 Drama 與真實網路測試

Wayne - 8 月 29 日。