ルートの順序

このページでは、Cloud VPN トンネルがネクストホップとなっているカスタムルートの、Google Cloud における動作について説明します。

ルートの適用範囲と順序、静的ルートのパラメータなど、Google Cloud ルートの背景情報については、Virtual Private Cloud（VPC）のルートの概要をご覧ください。

ルートのタイプ

Cloud VPN トンネルは、VPC ネットワーク内のカスタムルートのネクストホップとなりえます。ネクストホップの Cloud VPN トンネルを持つ各カスタムルートでは、VPC ネットワークから出るパケットの下り（外向き）パスが定義されます。

  • Cloud Router は常に、動的ルーティングを使用する Classic VPN トンネル、または HA VPN トンネルを管理します。Cloud Router はピア VPN ゲートウェイから BGP アドバタイズを受信し、BGP メッセージを送信します。Cloud Router は、VPC ネットワーク内のカスタム動的ルート（ピア ネットワーク内の宛先を持つルート）を自動的に作成して削除します。また、ピア ネットワークへのルート（VPC ネットワーク内のサブネットの IP 範囲へのルート、または Cloud Router 構成で指定したカスタム宛先へのルート）をアドバタイズします。VPC ネットワークの動的ルーティング モードは、Cloud Router がインポート、エクスポートする一連のルートを制御します。

  • ポリシーベース、またはルートベースの Classic VPN トンネルでは、静的ルーティングが使用されます。Google Cloud Console を使用してこのようなトンネルを作成すると、Cloud VPN 構成で指定したリモート IP 範囲に基づいてカスタム静的ルートが自動的に作成されます。Google Cloud CLI を使用して作成する場合は、トンネルをネクストホップとして使用する静的ルートを手動で作成する必要があります。

シナリオ例

Google Cloud は、パケットを送信するネクストホップを選択するときに、明確に定義された適用範囲と順序に従います。次の例は、ルートと Cloud VPN との間の一般的なやり取りを示しています。

サブネット ルートとのやり取り

次の表に、サブネット ルートとカスタムルートの操作方法を示します。各行は、VPC ネットワーク内のサブネットの有効な IP 範囲を表します。オンプレミスの範囲は、10.2.0.0/16（IPv4 の場合）または fd20:a:b:c::/64（IPv6 の場合）です。

IPv6 トラフィックは、IPv4 と IPv6 のデュアル スタック タイプで構成された HA VPN ゲートウェイでのみサポートされます。

VPC ネットワーク Cloud VPN トンネル ルーティング
Google Cloud サブネットの IP 範囲 静的（ポリシーベース、ルートベース）
Classic VPN のみ		 動的（BGP）
Classic VPN または HA VPN
10.2.0.0/16
オンプレミス IP 範囲と同じ		 Google Cloud では、宛先が 10.2.0.0/16 でネクストホップが Cloud VPN トンネルのカスタム静的ルートは作成できません。 トンネルに関連付けられた Cloud Router は、宛先 10.2.0.0/16 へのアドバタイズされたルートを無視します。10.2.0.0/16 を宛先とするトラフィックは VPC ネットワークに残ります。
fd20:a:b:c::/64
オンプレミス IP 範囲と同じ		 Classic VPN は IPv6 をサポートしていません。 トンネルに関連付けられた Cloud Router は、宛先 fd20:a:b:c::/64 へのアドバタイズされたルートを無視します。fd20:a:b:c::/64 を宛先とするトラフィックは VPC ネットワークに残ります。
10.0.0.0/8
オンプレミス IP 範囲より広い
（サブネット マスクは短くなる）		 Google Cloud では、宛先が 10.2.0.0/16 でネクストホップが Cloud VPN トンネルのカスタム静的ルートは作成できません。 トンネルに関連付けられた Cloud Router は、宛先が 10.0.0.0/8 と一致またはそれに収まるアドバタイズされたルート（10.2.0.0/16 を含む）をすべて無視します。10.0.0.0/8 を宛先とするトラフィックは VPC ネットワークに残ります。
fd20:a:b::/48
オンプレミス IP 範囲より広い
（サブネット マスクは短くなる）		 Classic VPN は IPv6 をサポートしていません。 トンネルに関連付けられた Cloud Router は、宛先が fd20:a:b::/48 と一致またはそれに収まるアドバタイズされたルート（fd20:a:b:c::/64 を含む）をすべて無視します。fd20:a:b::/48 を宛先とするトラフィックは VPC ネットワークに残ります。
10.2.99.0/24
オンプレミス IP 範囲より狭い
（サブネット マスクは長くなる）		 Google Cloud では、宛先が 10.2.0.0/16 でネクストホップが Cloud VPN トンネルのカスタム静的ルートの作成が可能です。ただし、10.2.99.0/24 の IP アドレスへのトラフィックは VPC ネットワーク内に残ります。 トンネルに関連付けられた Cloud Router は、宛先が 10.2.0.0/16 のアドバタイズされたルートを受け入れます。ただし、10.2.99.0/24 の IP アドレスへのトラフィックは VPC ネットワーク内に残ります。
fd20:a:b:c::/80
オンプレミス IP 範囲より狭い
（サブネット マスクは長くなる）		 Classic VPN は IPv6 をサポートしていません。 トンネルに関連付けられた Cloud Router は、宛先が fd20:a:b:c::/64 のアドバタイズされたルートを受け入れます。ただし、fd20:a:b:c::/80 の IP アドレスへのトラフィックは VPC ネットワーク内に残ります。

トンネルがダウンした場合

動的（BGP）ルーティング

動的ルーティングを使用している Classic VPN トンネル、または HA VPN トンネルがダウンした場合、学習したルートはトンネルを管理している Cloud Router によって自動的に削除されます。障害の検出にかかる時間は、Bidirectional Forwarding Detection（BFD）が有効になっているかどうかによって異なります。BFD が有効になっている場合は、BGP ホールドダウン タイマーが切れると検出が行われます。それ以外の場合は、検出は 60 秒未満で行われます。トンネルが再確立されると、学習したルートを再追加できます。

この処理は完全に自動化されていますが、影響を受けるルートを Cloud Router が削除している間にパケットロスが発生する可能性があります。

静的ルーティング

Google Cloud は、IKE セキュリティ アソシエーション（SA）を確立していない Cloud VPN トンネルを、有効なネクストホップとして考慮しません。Cloud VPN トンネルが IKE SA を確立している場合、Google Cloud は運用可能とみなします。運用可能な Cloud VPN トンネルは、ルーティング順序に従ってネクストホップとして選択されている場合にのみ、トラフィックを渡します。代わりに、より具体的な宛先またはより高い優先度を持つ、別のルートのネクストホップが使用される場合があります。

次のシナリオでは、想定される動作を示します。

  • ネクストホップとしてそれぞれ異なる Cloud VPN トンネルを持つ、同じ宛先のカスタム静的ルートが複数ある場合、Google Cloud は IKE SA（フェーズ 1）を確立したトンネルのみを考慮します。ダウンしているトンネル、つまり有効な IKE SA を持たないトンネルは、ルート優先度が考慮される前に無視されます。

    たとえば、宛先 192.168.168.0/24 に次の 3 つのカスタム静的ルートがあるとします。1 番目はネクストホップの Cloud VPN トンネルがダウンしている優先度 10 のルート、2 番目はネクストホップのトンネルが稼働している優先度 20 のルート、3 番目は同様にネクストホップのトンネルが稼働している優先度 30 のルートです。Google Cloud は、ネクストホップがダウンしているルートより優先順位が低い場合でも、2 番目のネクストホップにトラフィックを送信します。最初のトンネルが再確立された場合、Google Cloud はそれを有効なネクストホップとみなして代わりにそのルートを使用します。

  • 同じ宛先のカスタム静的ルートのネクストホップとして機能する Cloud VPN トンネルがすべてダウンすると、トラフィックは破棄されます。より広い範囲の宛先のカスタム静的ルートに運用可能なネクストホップのトンネルがある場合も、トラフィックは破棄されます。

    たとえば、ネクストホップの Cloud VPN トンネルがダウンしている 192.168.168.0/24 へのカスタム静的ルートがあるとします（有効な IKE SA はありません）。ネクストホップが運用中の Cloud VPN トンネルである 192.168.0.0/16 へのルートがある場合でも、192.168.168.0/24 へのトラフィックは破棄されます。これは、Google Cloud が常に最も具体的な宛先のルートを選択するためです。

トラフィックが 1 つのネクストホップの Cloud VPN トンネルから別のトンネルに切り替わると、パケットロスが予想されます。処理中のパケットが破棄された場合、再送信する必要があります。

トンネル経由の ECMP

動的ルーティングと静的ルーティングの両方で、同じ宛先に複数のカスタムルートが存在し、同じ優先度でアクティブな（IKE SA 確立済み）ネクストホップのトンネルの場合、Google Cloud は等価コスト マルチパス（ECMP）ルーティングを使用してトンネル間でパケットを配信します。

このバランシングはハッシュに基づくため、トンネルが稼働している限り、同じフローからのパケットはすべて同じトンネルを通ります。

ECMP 動作をテストするには、iperf3 を使用して、複数の TCP ストリームを（理想的には複数の Google Cloud 仮想マシン（VM）インスタンスから）同時に Cloud VPN トンネル経由で送信します。ECMP の動作を検証する必要がある場合は、ICMP（ping）を使用してテストを実行しないでください。1 つの VM インスタンスからの ping テストでは、Cloud VPN トンネルを介して ECMP ベースの下り（外向き）をテストするために十分ではありません。固定された送信元と宛先がある場合に、1 つのトンネルしか選択されないためです。ICMP にはポートのコンセプトがなく、プロトコルが固定されているため、ハッシュは送信元アドレスと宛先アドレス（2 つのタプルのハッシュ）の 2 つのデータからのみ計算されます。

次のステップ