Cloud Run からオンプレミス VPN へ：Direct VPC egress の設定

Cloud VPN トンネルだけでは Cloud Run はネットワークに入りません。サービスを正しいサブネットに接続し、実際の送信元レンジをルーティングしてから、そのリビジョンをテストします。

トンネルは上がっており、VM はオンプレミスのサーバーに到達しているのに、同じホストへの Cloud Run サービスの呼び出しがタイムアウトする。これはこの作業のよくある出発点であり、トンネル自体が原因であることはほとんどない。 Cloud Run のリビジョンは既定では VPC 内に存在しない。存在するようになっても、すでにルーティングした VM サブネットではなく、独自の送信元アドレスを使う。以下の手順では、サービスを接続し、実際の送信元レンジをルーティングし、リクエストを処理したリビジョンから経路を証明する。この順序で実行すること。最初の手順を飛ばすと、何も直らない VPN 変更で終わる事例がこれほど多いからだ。

トンネルをデバッグする前にリビジョンを接続する

Cloud Run は Direct VPC egress に対応しており、Serverless VPC Access コネクタなしでサービスの通信を VPC 内のサブネットに載せられる。既存サービスでは更新は次のようになる：

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

プレースホルダーを置き換え、デプロイが稼働中の通信に何をするか確認し、サービスのリージョンで十分なアドレス容量と正しいネットワーク権限を持つサブネットを選ぶ。

宛先に合った egress モードを選ぶ

private-ranges-only は、プライベートと分類した宛先を VPC 経由で送る。これは「VPN 経由で到達できるものすべて」という意味ではなく、オンプレミスのサービスがその設定でそう分類されないレンジにあるときに、その差が現れる。宛先が対象外なら、all-traffic がもう一つの文書化されたモードであり、サービスの公開依存関係を含め、すべてを VPC 経由で送る。意図して選び、その結果を変更記録に書く。

すでにコネクタを使っているサービスは切り替えではなく移行なので、両方を設定するのではなく計画する。

VM の送信元ではなく Cloud Run の送信元をルーティングする

Direct VPC egress は選択したサブネットから一時的なアドレスを割り当てるため、オンプレミス側はそのレンジへ通信を戻す必要がある。別の VM サブネット向けに書かれた戻りルートやファイアウォール許可は、図では正しく見えても実際には失敗する。サブネットの CIDR は記憶ではなく VPC から取得し、リモート機器の crypto ACL やルートテーブルに含まれていることを確認する。

動的ルーティングでは、Cloud Router が実際に広告している内容と VPC が取り込んでいる内容を、カスタム広告ポリシーも含めて確認する。コンソールに存在してもこの宛先に選択されていないルートは、ルートがないのと同じである。

すべて満たす必要がある三つの条件

動作する経路には次のすべてが必要で、それぞれが独自の形で失敗する：

  • VPC 内に、意図した Cloud VPN 接続を経由してオンプレミスのプレフィックスへ向かうルート。
  • オンプレミス側に Cloud Run サブネットへの戻りルート。
  • 送信元、宛先、ポートを許可するファイアウォールと IPsec の保護範囲。

ルートの欠落は通常、リモート側に証拠のないタイムアウトとして現れる。戻りルートの問題は、リクエストが届いて応答が消える形で現れる。ファイアウォールやセレクタの問題は、機器によって拒否にも無言の破棄にも見える。三つのどれなのかを特定できれば、次のコマンドはかなり絞り込める。

一時的な Cloud Run アドレスを一つだけ許可リストに入れないこと。サブネットのレンジと、アプリケーションに合った認可設計を使う。

リクエストを処理したリビジョンをテストする

テストの前に、デプロイ済みのネットワーク設定と通信の配分を確認する。更新で新しいリビジョンができても、リクエストがまだ古い方に届くことがあるからだ。そのうえで、ユーザーのリクエストが行うのと同じ操作を、そのリビジョンから実行する。宛先がプライベートなホスト名なら、その環境での名前解決と得られたアドレスを確認する。手元のノート PC の社内 DNS の答えは、サービスの名前空間について何も証明しない。TLS のホスト名検証とリモートアプリケーション自身の認証は維持する。

Direct VPC の起動時の接続遅延は文書化されているので、それを想定し、コールドスタートのたびに壊れたトンネルと診断するのではなく、クライアントに準備完了や再試行の戦略を渡す。

ロールバックと、これがしないこと

ロールバックするには、サービスのネットワーク設定と egress 設定を以前の値に戻し、以前のリビジョンがまだ通信を処理していることを確認する。gcloud コマンドは変更記録に残すこと。部分的な変更の逆操作は六週間後には自明ではない。VPC の接続を外すと、サービスは以前の egress 経路に戻る。インシデント中はまさにそれが望ましいこともある。

この設計は Cloud Run が開始する接続とその応答を対象とする。オンプレミスネットワークにサービス内部のアドレス可能なソケットを与えるものではない。内向きの公開は ingress の判断だからだ。

関連記事