昨天講完雲端那一側。今天換地端。地端要做的事只有兩件：在一台機器上裝 VPN 軟體，然後在路由器上加一條路由。第一件事有文件可以照做，第二件事沒人會提醒你，而少了它會出現一個很容易誤判的現象。

第一件事：裝 strongSwan

Azure 的 VPN 閘道用的是 IPsec 這套協定，所以地端也要有東西能講同樣的語言。我們用的是 strongSwan，一套開源的 IPsec 軟體，裝在機房裡一台 Linux 上。

要改的東西是兩個設定檔。一個放昨天講的那組共用密碼，另一個描述這條連線：對方的公網 IP、用什麼加密演算法，還有最關鍵的兩個欄位：我這邊的網段是什麼、對方的網段是什麼。

這兩個欄位就是昨天在 Azure 上填「本地網路閘道」的同一組資訊，只是換一邊填。雲端那側要知道地端是 192.168.50.0/24，地端這側也要知道雲端是 10.30.0.0/16，而且兩邊填的必須一致。

IPsec 在建立隧道的時候會比對這一對網段，對不起來就不會協商成功。所以這裡填錯，你不會看到「網段設定錯誤」這種訊息，只會看到隧道建不起來，然後開始懷疑是不是密碼打錯了。

為什麼要打開 IP 轉發

還有一個設定容易漏：這台機器的 IP 轉發。

Linux 預設不轉發封包。一台機器收到封包時，如果目的地不是自己，就直接丟掉。這對大部分機器來說是合理的預設，因為幫別人轉送封包既不是它的職責，也是個風險。

但這台機器的角色正好就是路由器：它不只要自己連到雲端，還要幫整個機房的其他機器把封包送過去。所以要手動把轉發打開。

改完之後啟動，ipsec status 顯示 ESTABLISHED 就代表隧道通了。

測起來是通的，但只有那一台

隧道顯示 ESTABLISHED 之後，我在那台機器上測連線，連得上、回應正常。

但這時候整個機房裡，只有那一台連得到雲端。

ESTABLISHED 證明的事情比它看起來少。它只代表兩端談成了金鑰、確認了彼此的身分，不代表有任何一個封包真的送到了對面，更不代表機房裡其他機器用得到這條隧道。

第二件事：路由器上的那條路由

機房裡的其他機器想連雲端的資料庫時，會先問路由器：這個位址要往哪送？

而路由器的路由表裡，沒有任何一條規則提到雲端那個網段。所以它會走預設路徑，把封包順著對外的那個口送出去，丟到網際網路上。但那是一個私有網段的位址，在網際網路上根本不存在，封包就這樣消失了。

只有裝 strongSwan 那台知道要走隧道，因為隧道就建在它身上，這件事沒有告訴過任何人。

解法是在路由器上加一條靜態路由，把那些封包倒回來：往雲端那個網段的封包，不要往外送，交給 strongSwan 那台機器。加完之後，機房裡任何一台機器都能連到雲端了。

為什麼這一步容易被漏掉

因為驗證的時候，最順手的那台機器剛好就是唯一不需要那條路由的。

你剛在 strongSwan 那台上改完設定、啟動服務，人就在那台機器的終端機裡。要確認通不通，直接在當下這台測是最自然的動作。而它是全機房唯一不靠路由器就能走隧道的機器。

所以那個測試會過，但整件事其實還沒做完。

我把這件事寫進了驗證清單，而且特別註明：要從「不是裝 strongSwan 的那一台」再測一次。

同一條指令，從三個地方測

驗證清單最後寫成三條，因為它們擋下的是不同的錯：

從裝 strongSwan 那台測，驗的是隧道本身。這條過了，代表 IPsec 協商成功、兩邊的網段對得上、密碼是對的。

從其他地端節點測，驗的是路由器上那條靜態路由。這條過了，代表機房裡的機器真的用得到這條隧道。

從雲端的叢集裡測，驗的是雲端那一側的網路。資料庫關在自己的子網裡，叢集連不連得到它，跟地端通不通是兩件事。

三條測的都是「連得到資料庫的 3306 埠」，指令幾乎一模一樣。決定它在測什麼的，是你從哪裡把它送出去。

帶得走的東西

驗證的時候要多問一句：我測的這個對象，有沒有什麼特別之處？

在這個例子裡，那台機器的特別之處是「隧道建在它身上」。在別的情境裡可能是「這台機器有 sudo 權限」「這個帳號是管理員」「這個環境有快取」。只要你測的對象和真實使用者的處境不同，測過了也不代表能用。

後面還會再出現幾次同型的狀況：驗證腳本讀到上個視窗的舊快照給了假的「完全一致」，匯入腳本回報「匯入成功」但資料庫裡一筆都沒有。

明天講換掉共用密碼之後，隧道就連不起來的那次。診斷紀錄顯示握手的前半段成功、後半段失敗，這個組合後來變成我判斷 VPN 問題最快的一條規則。