建 Azure 的網路資源時，會有好幾個欄位要你填 IP 網段。虛擬網路一個、MySQL 的子網一個、閘道的子網一個。

這些欄位看起來就是填數字，隨便給一個沒被佔用的就好。我一開始也是這樣想的。

為什麼不能隨便填

問題出在地端。我們的架構是雲端和地端各有一套網路，中間用 VPN 打通。從雲端送到地端的封包，會先進到地端那台跑 VPN 的機器，然後由路由表決定要往哪送。重點是：地端只有一張路由表。

而我們有兩個環境要接回地端，測試環境一套、生產環境一套。這兩套都會透過同一台機器、查同一張路由表。如果兩個環境的網段一樣，會發生什麼事？

假設測試用 10.10.0.0/16，生產也用 10.10.0.0/16。地端要回一個封包到 10.10.1.4，路由表上有兩筆規則，兩筆長得一模一樣，一筆指向測試、一筆指向生產。

路由器沒辦法判斷該送哪邊。 它不知道這個封包是要回測試那台還是生產那台，因為位址本身沒有這個資訊。

所以規則很簡單：凡是會經過同一個路由匯集點的網段，都必須是唯一的。

我們實際怎麼切

測試環境的 MySQL 用 10.10.0.0/16。生產環境改用 10.30.0.0/16。除了避開測試，還要避開另外兩個：

• 澳洲那邊的環境已經佔了 10.20.0.0/16
• Kubernetes 自己的 Pod 網路預設是 10.224.0.0/12，這個範圍很大，會蓋掉 10.224 到 10.239

把這些都排掉之後，10.30.0.0/16 是安全的。

這件事我沒有踩到。規劃網段的時候問了 AI，它直接就提醒我兩個環境不能用一樣的網段，我照著填，後來也沒出過問題。

子網要切多大

決定完整個虛擬網路用哪一段之後，還要往下切成幾個子網。我們切了三個，而它們的需求差很多。

資料庫的子網只會放一台託管的資料庫，用不到幾個位址，切一個 /24（兩百多個位址）已經是綽綽有餘。

Kubernetes 節點的子網要留大一點，因為節點數量會隨著負載變。今天兩台，明天可能四台，如果切太小，之後要擴就會卡住，而子網的大小是建立之後不能改的。所以我切了 /23。

閘道的子網需求固定而且很小，/27 就夠。

一個放位置的小技巧

閘道那個子網，我把它切在整個網段的最尾端。

假設虛擬網路是 10.30.0.0/16，我沒有把閘道放在 10.30.3.0，而是放在 10.30.255.0/27，也就是最後面那一小塊。

理由是：中間那一大片要留給會長大的東西。 Kubernetes 節點會變多、之後可能加新的服務、也可能多切幾個子網，這些都往前面擴。而閘道這種基礎設施不會長大，把它釘在最尾端，它就永遠不會擋到別人。

這件事現在做不用花任何力氣，但如果一開始把閘道切在 10.30.3.0，某天你要把節點子網擴大的時候，就會發現它正好卡在路中間，而子網一旦有東西在跑就不能隨便動。

另外兩個填了就改不了的欄位

除了網段，建立過程中還有兩個地方，填錯的代價比想像中高。

MySQL 的子網要「委派」給資料庫服務。 這是一個下拉選單，選了之後，這個子網就專屬於 MySQL，不能再放任何其他資源進去。所以子網要開多大、要不要留空間給別的東西，得在這一刻想清楚。

閘道的子網名稱必須一字不差叫 GatewaySubnet。 不能叫 gateway-subnet，不能叫 GatewaySubnet1，就是這個名字、這個大小寫，因為後面建閘道時 Azure 是去那個名字底下找它。

這兩個都不是什麼高深的設計，就是規則。但它們共同的特徵是：建立當下不會報錯，要等到很後面才發現不對。

帶得走的東西

在填任何一個網段之前，先問「這個位址將來會跟誰在同一張路由表上見面」。

單一個環境的時候，網段填什麼都無所謂，反正不會撞。但只要有第二個環境、第二個站點、第二條 VPN，它們就會在某個地方匯集，而匯集點只有一張表可以查。

這件事的麻煩在於，你在建第一個環境的時候，根本不會想到會有第二個。等到要建第二個的時候，第一個已經在跑了，改不動了。

所以如果你正在建第一套，值得先花十分鐘畫一張表，把「公司現在用到的所有內部網段」列出來，然後刻意選一個離大家都遠的。這件事現在做要十分鐘，之後做要停機。

明天要講一個更基本的東西：這些資源要建在哪個地區。我們原本規劃建在馬來西亞，結果連一台資料庫都建不起來。