ルートの順序

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

ルートのタイプ

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

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

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

サンプル事例

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

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

次の表に、サブネット ルートとカスタムルートの操作方法を示します。各行は、VPC ネットワーク内のサブネットの有効な IP 範囲を表します。オンプレミス IP の範囲は 10.2.0.0/16 です。

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 ネットワークに残ります。
10.0.0.0/8
オンプレミス IP 範囲より広い
(サブネット マスクは小さくなる)
Google Cloud では、宛先が 10.2.0.0/16 でネクストホップが Cloud VPN トンネルのカスタム静的ルートは作成できません。 トンネルに関連付けられた Cloud Router は 10.2.0.0/16 を含め、宛先が 10.0.0.0/8 と一致または収まるアドバタイズされたルートをすべて無視します。10.0.0.0/8 を宛先とするトラフィックは VPC ネットワークに残ります。
10.2.99.0/24
オンプレミス IP 範囲より狭い
(サブネット マスクは長くなる)
Google Cloud では、宛先が 10.2.0.0/16 でネクストホップの Cloud VPN トンネルを持つカスタム静的ルートの作成が可能です。ただし、IP アドレス 10.2.99.0/24 へのトラフィックは VPC ネットワーク内に残ります。 トンネルに関連付けられた Cloud Router は、宛先が 10.2.0.0/16 のアドバタイズされたルートを受け取ります。ただし、IP アドレス 10.2.99.0/24 へのトラフィックは VPC ネットワーク内に残ります。

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

動的(BGP)ルーティング

Classic VPN トンネルが動的ルーティングを使用している、または HA VPN トンネルがダウンした場合、Cloud Router により学習済みのカスタム動的ルートは 40 秒以内に自動的に削除されます。トンネルが再確立されると、カスタム動的ルートを再追加できます。

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

静的ルーティング

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

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

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

    たとえば、宛先 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 つのデータからのみ計算されます。

次のステップ