跳到主要內容

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 網路設計
張貼留言
閱讀完整內容

AWS雲端資料中心第一次因為戰爭導致服務中斷？

AWS UAE Region 因被不明物體擊中導致其中AZ服務斷線。這應該是有史以來第一次雲端資料中心因為戰爭導致服務中斷的案例，特別紀錄起來，以後就可以嚇嚇客戶了。 AWS多次在其Well-Architected Framwork當中提到你要部屬Muti-Region, Muti-AZ架構，為了 就是要賺更多錢， 避免因為單一數據中心斷線而你的服務跟著一起斷線。提到的原因通常是天災、戰爭、斷水斷電等各種不可抗力因素。 但AWS用久了你就會發現（好像也不用多久？），AWS斷線幾乎都是因為人為錯誤原因（ 例如又有人搞壞了DNS ），而不是這些聽起來有點遙遠的不可抗力因素。而這次美以伊戰爭示範給大家看，即使你不是戰爭國家的Region，還是有可能被波及到，導致服務斷線。 然而一個AZ可以被建立的資源是有限的，當今天突然有大量的請求要在某AZ新增資源（大家開始執行DR），這時可能就要拼建立速度，誰先建先贏。晚到的可能又出現錯誤訊息的情況，這時資料有沒有Muti-Region備份就變得很重要。 但重點是，現在政府各種強調資料主權，如果是被法規限制的行業，資料不可能在其他國家進行備份。所以這些企業或政府可能要Muti-Cloud架構，並且祈禱另一個雲服務的資料中心所在位置不會有事。但實務上有多少企業或機關有錢到可以做Muti-Cloud架構呢？ 3月1日 太平洋時間上午9時41分 我們希望提供有關ME-CENTRAL-1地區單一可用區電力問題的額外資訊。在太平洋時間上午4時30分左右，我們的其中一個可用區(mec1-az2)受到撞擊資料中心的物體影響，產生火花和火災。消防部門在滅火過程中關閉了設施和發電機的電源。我們仍在等待開啟電源的許可，一旦獲准，我們將確保安全地恢復電源和連接。 上述說明當地消防部門因為要滅火關閉了電源，AWS正在等待電源開啟許可，所以他們也無法做什麼。聽起來有點耳熟？好像平常代理商會跟客戶說的，因為你用的是AWS全託管服務，所以如果服務壞了我們也不能做什麼。 事故截至目前從本來只有 mec1-az2被斷線，現在 mec1-az3也斷了。雖然 mec1-az1現有資源正常，但也無法新增機器了。
張貼留言
閱讀完整內容