最近WFH，前同事推薦了一部好看的卡通：咒術迴戰～ 裏面主要是咒術師，咒靈和詛咒師的戰爭～裡面說道一句名言：『詛咒就應該用詛咒來拔除』。 防火牆最近對我就像個詛咒一樣，上一篇講過用Script來拔除。沒想到最近親愛的客戶要開始介接GCP上的GKE和地端服務，又跟防火牆扯上關係了。大概的狀況就是想要用GKE裡的Pod，去存取地端的某個特定服務。原本神經大條的我想說 這有什麼問題？不是interconnect已經通了嗎？結果，是因為地端防火牆（對，又是它）必須有白名單Allow-List，資安團隊要求必須提供1~2個IP位置。如果玩過K8S的捧油，大概了解～Pod本身的IP是不固定的～有人可能說，那就透過Node IP的SNAT，把Node的IP加入防火牆白名單吧～這個…GKE支援AutoScaler…所以未來這些Node的IP可能也會變唷~ 真正要實現這個機制，很多地端的K8S Distribution必須仰賴CNI+SDN的方式解決，如: Openshift的Egress Route是通過OVN(open-virtual-networking)，以及Tanzu裡的NSX。但如果部署不了支援的SDN區域怎麼辦呢？我遇到的詛咒就是這樣的一個狀況～那我們就走老派方法，SNAT吧！ 很多人看到SNAT，可能第一時間想到的是『買一台』，其實一台Linux Server(e.g. CentOS or Ubuntu)其實都可以快速支援NAT的功能，底下我們來介紹，如何用GCE快速搭建一對具有自癒能力的NAT Server。 上方圖示是大概的架構圖。這裡面橘色部分是通過GCE創建的SNAT Server，主要創建的方法是通過設定GCE VM（標示為橘色SNAT)，使用IPTables的masquerade機制，並在VPC內強迫Worker Node(標示為N1)節點的靜態路由導向SNAT的兩台GCE VM。 同時考量是企業使用，我們一併通過Instance Group搭建出具有自癒能力的GCE VM，自癒能力是通過Healthcheck偵測GCE VM上的http服務是否回覆200 OK。結合這兩種需求，我們可將SNAT的Cloud-Init安裝腳本設置如下： 接下來，我們使用以下的Script，將安裝腳本快速打包成Instance Template，並將兩台機器快速產出，並將靜態路由設定完畢： 上述Script執行完畢後，需要將Worker Node這些VM，打上no-ip的Tag方能生效，或是我們也可以使用GKE VM上預設的Tag作為routes的選擇標的。 最後，若需要提供固定GCE VM 的IP位置，我們可以使用本文件的建議作法 這樣，當我們訪問外部服務器時(e.g. https://whatismyipaddress.com)