GCPとAzureをVPNゲートウェイで冗長接続する！

Azure
2022.02.15

GCPとAzureで冗長VPN接続を試してみた。フルメッシュの冗長接続こそ実現できなかったが、2重化されたVPN接続は簡単に構成できた。

  1. 今回の構成
  2. 構成のポイント
      1. AzureではBGPピアIPにAPIPA IPアドレスを指定する
      2. GCPとAzure間のBGPフルメッシュ冗長化はできない
  3. 設定
      1. GCPの設定
      2. Azureの設定
          1. 冗長Azure VPN GWの有効化
          2. VPNゲートウェイの構成
          3. しょうがないConnecting問題
  4. 疎通確認
      1. つながらない
      2. つながった
      3. AzureからGCP VPCのasia-northeast2リージョン(Osaka)につながらない
      4. グローバルルーティング有効化
      5. つながった
  5. 障害テスト
  6. あとがき

今回の構成

  • Azure VPN Gateway(vpngw1,Active/Active)
  • GCP Cloud VPN(HA VPN Gateway)

構成のポイント

  • AzureではBGPピアIPとしてAPIPA IPアドレスを指定する
  • GCPとAzure間のBGPフルメッシュ冗長化はできない

AzureではBGPピアIPにAPIPA IPアドレスを指定する

GCPではCloud RouterとBGPピアの間をリンクローカルアドレスによりBGPセッションを確立する。一方、AzureのVPNはvNetに作成したGatewaySubnetの範囲からBGPインターフェイスのIPが構成されるのがデフォルトの挙動になっていて、そのままだとGCPとBGPセッションを確立することはできない。そこでGCPの仕様にあわせてAzure VPNゲートウェイ構成時にBGP IPとしてAPIPA IPアドレスを構成する必要がある。

GCPとAzure間のBGPフルメッシュ冗長化はできない

Azure HA VPNゲートウェイとGCP Cloud Routerの仕様がかみあわずBGPセッションをフルメッシュで構成することができない。

Azure

  • GCP VPNゲートウェイはグローバルIPとBGPピアIPのペアによって定義される
  • 同じGCP VPNゲートウェイIPに対応する新しいAzureローカルネットワークゲートウェイを定義して別のBGPピアIPを持たせても接続先GCP VPNゲートウェイIPが同じ場合使わせてもらえない。
    file

GCP

  • GCP VPNゲートウェイ内ではリンクローカルアドレスはトンネルごとにユニークである必要がある(BGPセッションごとにCloud Routerにインターフェイスがアタッチされ使いまわしできない)
    file

これらの仕様により、おのおの2つずつあるVPNゲートウェイ間で確立されるVPNトンネルは4つだが、BGPセッションが2つしか確立されないなんだか中途半端な状態となる。
図中のAAAA.AAAA.AAAA.AAAAとDDDD.DDDD.DDDD.DDDDのゲートウェイが同時にダウンするような複合障害の発生には耐えられず、VPNセッションはあっても経路をロストし通信断が発生する。

設定

GCPの設定

  1. 高可用性(HA) VPNを選択してVPNをゲートウェイを作成する
    file
    file

  2. 対向VPNゲートウェイは非Google Cloudを選ぶ
    VPNトンネルを冗長にするのでVPNトンネルのペアを作成する
    file

  3. お互いのプライマリVPNゲートウェイ同士でトンネルを構成
    file

  4. Azureの一番目のVPNゲートウェイに指定したAPIPA IPアドレスを指定してBGPピアを構成
    file

  5. Azureの2番目のVPNゲートウェイに指定したAPIPA IPアドレスを指定して2つめのトンネル経由でBGPピアを構成
    file

  6. Azure VPNゲートウェイのBGP IPはVPNゲートウェイの構成から確認できる
    file

  7. GCP側の準備ができたら次はAzure側のVPNトンネルを構成する。GCPで構成されたものは以下の通り。

    - 二つのVPNトンネル

    - 二つのBGPセッション

file

Azureの設定

冗長Azure VPN GWの有効化
  • アクティブ/アクティブモードを有効化
  • BGPを有効化
  • GCP VPNゲートウェイと接続するためにAPIPA BGP IPアドレスを構成
VPNゲートウェイの構成

  1. Azure側ではGCP Cloud VPNの各VPNゲートウェイインスタンスをローカルネットワークゲートウェイとして定義する。
    file

    file

  2. GCP Cloud VPN ゲートウェイとのVPNトンネルは二本ともアップになった。なお、GCP側でもVPNゲートウェイ間をクロスするVPNトンネルを追加し、トンネルだけ4本のフルメッシュ構成にするこ ともできるが、BGPセッションを確立できないのでやらない。
    file

しょうがないConnecting問題

Azureは冗長化された二つのVPNゲートウェイのそれぞれからすべてのGCP Cloud VPN ゲートウェイにBGPセッション確立する動きがデフォだけど半分はつながらないので、1/2のBGPセッションが接続をリトライする状態になってしまう。(Connectingのところ)
file

疎通確認

つながらない

root@test-ubuntu:/home/testvpnuser# ping 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.

GCPのVPCには暗黙のInbound Denyルールが存在するため、ファイアウォールを開放しないとVMからPINGが返ってこない。
file

つながった

ファイアウォール解放後、PINGも通るようになった。

root@test-ubuntu:/home/testvpnuser# ping 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=63 time=3.54 ms
64 bytes from 172.16.0.2: icmp_seq=2 ttl=63 time=3.41 ms
64 bytes from 172.16.0.2: icmp_seq=3 ttl=63 time=4.73 ms
^C
--- 172.16.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.411/3.894/4.728/0.592 m

AzureからGCP VPCのasia-northeast2リージョン(Osaka)につながらない

AzureからVPNで直接つながっているTokyoサブネット(asia-northeast1)を経由して同一VPC上にあるOsakaサブネット(asia-northeast1)のVMにも到達できるようにしたい。

root@test-ubuntu:/home/testvpnuser# ping 172.24.0.2
PING 172.24.0.2 (172.24.0.2) 56(84) bytes of data.
^C
--- 172.24.0.2 ping statistics ---
118 packets transmitted, 0 received, 100% packet loss, time 119811ms

グローバルルーティング有効化

グローバルルーティングを有効化するとGCPのVPC内でリージョンの異なるサブネット同士で経路を学習するようになる。
file

つながった

Cloud VPNとCloud Routerがあるasia-northeast1リージョンのサブネットがasia-northeast2リージョンのサブネットへの経路を学習し、Azureからもつながるようになった。

root@test-ubuntu:/home/testvpnuser# ping 172.24.0.2
PING 172.24.0.2 (172.24.0.2) 56(84) bytes of data.
64 bytes from 172.24.0.2: icmp_seq=1 ttl=63 time=18.2 ms
64 bytes from 172.24.0.2: icmp_seq=2 ttl=63 time=11.6 ms
64 bytes from 172.24.0.2: icmp_seq=3 ttl=63 time=11.1 ms
^C
--- 172.24.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 11.098/13.625/18.228/3.259 ms

障害テスト

Azureから片方のGCP VPNゲートウェイへのトンネルを切断してVPNトンネルの障害を再現してみた。

file
file

切断時に88.5msの応答遅延が確認されたが通信は継続。

64 bytes from 172.24.0.2: icmp_seq=44 ttl=63 time=11.4 ms
64 bytes from 172.24.0.2: icmp_seq=45 ttl=63 time=21.0 ms
64 bytes from 172.24.0.2: icmp_seq=46 ttl=63 time=48.5 ms
64 bytes from 172.24.0.2: icmp_seq=47 ttl=63 time=16.3 ms
64 bytes from 172.24.0.2: icmp_seq=48 ttl=63 time=88.5 ms
64 bytes from 172.24.0.2: icmp_seq=49 ttl=63 time=40.5 ms
64 bytes from 172.24.0.2: icmp_seq=50 ttl=63 time=55.1 ms
64 bytes from 172.24.0.2: icmp_seq=56 ttl=63 time=12.7 ms

file

セッションを戻したときのPING応答遅延は最大63.7msだった。

64 bytes from 172.24.0.2: icmp_seq=204 ttl=63 time=18.4 ms
64 bytes from 172.24.0.2: icmp_seq=205 ttl=63 time=34.9 ms
64 bytes from 172.24.0.2: icmp_seq=206 ttl=63 time=31.1 ms
64 bytes from 172.24.0.2: icmp_seq=207 ttl=63 time=21.1 ms
64 bytes from 172.24.0.2: icmp_seq=208 ttl=63 time=63.7 ms
64 bytes from 172.24.0.2: icmp_seq=209 ttl=63 time=18.8 ms
64 bytes from 172.24.0.2: icmp_seq=210 ttl=63 time=15.6 ms

あとがき

Azure上で常に接続中になっているBGPセッションがあるのはすっきりしないけど、冗長はとれているのでしばらく通信が安定していればこの構成を採用してみてもよさそう。AzureやGCPのVMにStrongSwanあたりを入れてVPNゲートウェイとして仕立てるのはいろいろと管理が面倒でやりたくないからね。

タイトルとURLをコピーしました