跳到主要內容

AWS 與 GCP VPN 窮連與富連設定

 


在工作場景中，自己接觸到很多客戶透過VPN來連結多雲架構，於是決定實作連結AWS和GCP。

這篇文章整理 GCP Cloud VPN 與 AWS Site-to-Site VPN 的對接架構，並分別省錢版與企業版。

情境一：只是想連線測試或主管叫我省錢

這是省錢版，當你只是想測試連線功能，或主管叫你要省錢。

AWS 端設定

  1. 一個 Customer Gateway
    • 填入GCP的固定IP
  2. 一個 Virtual Private Gateway
    • 建立並與要測試連線的 VPC 關聯
  3. 一個 VPN Connection
    • 確認Connection Static Route頁面有出現VPC網段
  4. 要測試連線的VPC子網路由表啟用Route Propagation（或手動加上要測試的網段）

GCP 端設定

  1. 一個固定IP
    1. 建立一個固定IP
  2. 一個Classic VPN Gateway
    1. 因為在GCP建立VPN Gateway預設會啟用HA設定（也就是給你兩個Interface），所以必須手動調整為建立Classic VPN Gateway
  3. 一條VPN Tunnel
    1. 按照AWS Tunnel 1 or 2的資訊來填入Remote peer IP address（也就是Outside IP address）、Remote network IP ranges（也就是Inside IPv4 CIDR）、IKE PSK Key（下載配置檔從裡面得到Key）
  4. Routes
    1. 當你看到兩邊的Tunnel都亮綠燈時，想要用Ping測試連線，卻發現怎麼連不上
    2. 因為前面是設定靜態路由，所以我們還需要手動加上回AWS的路由
      1. Destination IPv4 range > AWS子網網段
      2. Next hop > 選擇建立的VPN Tunnel

注意事項

  • 注意Tunnel 的IKE version一致
  • AWS預設一個 VPN Connection就會給你兩條Tunnel，你也不能更改，不管有沒有兩條都用都收一樣的錢（一個 Connection 跟兩個公有IP的錢）。
  • 以上方案AWS Tunnel只會有一條有通，只要AWS或GCP Gateway IP所在的區域故障就會斷線，故不適合作為正式環境使用

情境二：企業正式系統連線

企業正式環境連線的作法，目標是任一雲端的單一地區故障都不會影響連線，提升連線高可用性。

GCP 端設定

在設定GCP VPN Gateway時，預設會使用 High Availability 的選項，也就是會產生兩個公開 IP（Interface 0 與 Interface 1），分別位於不同的可用地區，以提供保證的 SLA。

  1. 一個HA VPN Gateway
    1. GCP會自動分配兩個公有IP
  2. 一個Peer VPN Gateway
    1. 選擇 four interfaces，並填入 AWS 四條Tunnel產生的 Tunnel Outside IP
  3. 一個 Cloud Router
    1. 用於 BGP 動態路由
  4. 四條VPN Tunnel
    1. 對應 AWS 的 4 條線路
  5. 四個 BGP Sessions
    1. 每條 Tunnel 一個 BGP Session

AWS 端設定

每個 AWS Customer Gateway只能填寫一個 IP，並且每個 VPN Connection只能連接一個 Customer Gateway（代表 GCP 端的設備）和一個 Virtual Private Gateway（代表 AWS 端的設備）。

所以當今天 AWS 要對接 GCP VPN Gateway 的兩個 IP 時，我們在 AWS 端必須建立兩個 Customer Gateway，以及建立兩個 VPN Connection。

  1. 兩個 Customer Gateway
    1. 對應GCP HA VPN 的兩個 Interface IP
  2. 一個 Virtual Private Gateway
    1. 建立並與要測試連線的 VPC 關聯
  3. 兩個 VPN Connection
    1. 分別關聯上述的 CGW 與 VGW

關鍵參數對照

我們在 AWS 下載的VPN設定檔（通常選 Generic vendor），這份文件是從 AWS 的視角出發的。AWS 把 GCP 當作一般的客戶端機房，所以這份檔案是在告訴 GCP「你的 IP 應該設成這樣，你要連過來的目標 IP 是那樣」。

1. Outside IP 建立隧道

這組 IP 是在公共網路上使用，目的是為了讓兩邊的 VPN gateway 能找到對方並建立加密隧道。

  • VPN Gateway Interface IP (GCP) ↔ Outside IP Address (AWS Customer Gateway 側)
    • 對 GCP 來說，這是它自己的 VPN 接口公共 IP，但對 AWS 來說，這是它要連過去客戶端 (GCP)的公共 IP。
  • Peer VPN Gateway Interface IP (GCP) ↔ Outside IP Address (AWS Virtual Private Gateway 側)
    • GCP 把 AWS 當成對等端 (Peer)，而 AWS 對自己內部的 VPN 節點稱為 Virtual Private Gateway (VGW)。所以 AWS 的公共 IP 就是 GCP 眼中的 Peer IP。

2. Inside IP 進行路由交換

加密隧道建立好了，兩邊會透過隧道內部的虛擬 IP 來溝通路由資訊，並使用 BGP 協定。這組 IP 通常是在 169.254.x.x 網段。

  • Cloud Router BGP IP (GCP) ↔ Inside IP Address (AWS Customer Gateway 側)
    • GCP 的 Cloud Router 負責跑 BGP 協議，它需要一個內部的 BGP IP。因為 AWS 把 GCP 當成客戶端，所以 AWS 設定檔中寫給 Customer Gateway 側的 Inside IP，就是 GCP 該設在 Cloud Router 上的 IP。
  • Peer BGP IP (GCP) ↔ Inside IP Address (AWS Virtual Private Gateway 側)
    • GCP 也需要知道對面的 BGP 是誰，在 AWS 設定檔中會註明 Virtual Private Gateway 側（即 AWS 自己）的內部 IP。對 GCP 來說，這就是它的 BGP Peer。

3. 為什麼BGP session的IP是選手動填入不是自動分配？

因為我們AWS已經把對應的IP設定好了，GCP 的BGP session只能配合他才能找到路。如果要選擇自動分配，GCP要作為連線設定方。

整體網路流通路徑

AWS EC2 ↔VPC Private Subnet ↔ Virtual Private Gateway ↔ Customer Gateway ↔ AWS VPN Tunnel 1/2 ↔ Internet（加密傳輸）↔ GCP VPN Tunnel 1/2 ↔ Peer VPN Gateway ↔ Cloud VPN Gateway ↔ VPC Subnet ↔ GCP Compute Engine


標籤：

留言

張貼留言

這個網誌中的熱門文章

2025 GCP Associate Cloud Engineer 題型分享

考試時間：2025/07 考試時長：2 小時 權限設定相關問題佔比重大：Organization、IAM 和 Service Account 至少十題以上 帳單分析：透過 Export 功能結合 BigQuery Spanner 全球關聯式資料庫核心概念 gcloud Compute 常用指令 SSH 安全連線最佳實踐 Cloud Run 服務特性與應用場景 GKE 基礎架構與使用方式 Load Balancer 類型與應用（內部/外部、全球/區域） Storage Bucket 版本控制與生命週期管理 Storage Data Lake 應用（結構化與非結構化資料儲存） AlloyDB 特點與優勢（增強版 PostgreSQL） Filestore 作為 VM 的 NFS 解決方案 GCP 現代化與全託管服務特性 Pub/Sub 訊息系統與其他服務整合應用 VPC 網路架構與 Landing Zone 網路設計
張貼留言
閱讀完整內容

YouTube Music 無法一鍵按讚整個播放清單？這個 Chrome 擴充功能解決它

如果你剛從 Spotify 或 Apple Music 搬歌單到 YouTube Music，你很可能與我面對同一個問題： 那幾千首的 Liked Songs Playlist，要一首一首手動按讚嗎？ 問題出在哪裡？ 最近把 Spotify 歌單搬移到 YouTube Music，過程中發現一個讓人頭痛的地方，Spotify 的 Liked Songs （那個你一首一首按愛心的清單），搬過來之後，會以「新建立播放清單」的方式出現。但 YouTube Music 本身也有一個預設的 Liked Songs 清單，而且是完全分開的兩個東西。 更麻煩的是，目前所有的轉移工具都沒辦法把歌曲直接匯入那個「預設清單」。YouTube Music 也沒有提供「對整個播放清單一鍵按讚」的功能。 也就是說，如果你有 1000 首歌，你只能一首一首手動按讚，太辛苦了。 網路上有解法嗎？ 搜尋了一圈，發現這個問題其實非常多人遇到，但答案都不太讓人滿意。 有人說「只能手動」，有人分享了 JavaScript 腳本，但不是已經過時跑不起來，就是需要自己打開 DevTools 手動執行，對一般使用者來說門檻太高。 既然沒有好用的現成工具，那就自己做。 用 Chrome 擴充功能來解決這件事 透過 AI 協助開發，我做出一個 Chrome 擴充功能，可以自動對 YouTube Music 播放清單裡的所有歌曲按讚。 不需要任何技術背景，安裝完就能直接使用。 為了讓大家能直接從 Chrome 線上應用程式商店搜尋下載，花了 5 美元購買了上架資格。雖然只是一筆小錢，目的就是讓整個流程盡量簡單。你不用懂程式、不用開終端機，搜尋、安裝、點一下，完成。 使用方式 前往 Chrome 線上應用程式商店，搜尋並安裝擴充功能（點此前往） 開啟並登入 YouTube Music，複製你想要批次按讚播放清單的網址 點擊擴充功能按鈕，貼上網址，讓它自動幫你完成剩下的事 總結 這個擴充功能適合你，如果你符合以下任一條件： 剛從某個音樂串流平台搬到 YouTube Music 想把播放清單裡的歌一次加入 Liked Songs 不想一首一首手動按讚 歡迎試用，如果有問題或建議也非常歡迎留言回饋 🙌 更新 我在遞交1.1版...
張貼留言
閱讀完整內容