App Engine は VPN データベースに到達できる：揃えるべき条件

標準 App Engine は Cloud VPN 経由でデータベースに到達できますが、egress、送信元レンジ、リクエスト経路が一致する場合に限られます。揃えるべき点を整理します。

App Engine Standard が Cloud VPN 経由でプライベート データベースに到達できないという説は、プラットフォームの以前の世代の名残です。Standard インスタンスは他の一部のランタイムのように VPC ネイティブ アドレスを取得しませんが、ネットワーク内にある Serverless VPC Access コネクタ経由で egress を送信できます。その経路が存在すれば、Cloud VPN とリモート ファイアウォールはコネクタのトラフィックを他の送信元と同様に扱います。失敗するのは能力そのものではなく、揃わなかった三つの設定のうちの一つであることがほとんどです。

古い回答の出どころ

コネクタが存在する前は、Standard は公開エンドポイントとしか通信できないというのが実際の答えで、チームはそれを回避するためにプロキシ VM や別のランタイムへ移りました。プラットフォームは変わりましたが、俗説は変わりませんでした。オンラインの多くの助言はいまも、egress の選択肢がまったくなかった時代を反映しています。

修正は聞こえるほど狭い話です。Standard はプライベート ネットワークに到達できますが、サポートされた egress 統合を通る場合に限られ、その統合が実際に捕捉する宛先に限られます。

まず egress 経路を選ぶ

サービスに接続したコネクタが、そのトラフィックを VPC に入れます。コネクタのドキュメントにはリージョンの前提条件と egress 設定が記載されています。コネクタはサービスのリージョンに存在し、デプロイする ID が利用できる必要があります。

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only はプライベート宛先を VPC に送り、それ以外は通常のインターネット経路に残します。データベース接続が必要とするのは通常こちらです。all-traffic は送信トラフィックを VPC 経由で広く通すため、通常のインターネット呼び出しも VPC の NAT とファイアウォールの姿勢を引き継ぎます。

ファイルをローカルで編集しても、デプロイするまで何も変わりません。実行中のバージョンは作成時の設定を保持します。

送信元アドレスはコネクタであり、ノート PC ではありません

デバッグ時間の大半はここに費やされます。リモート VPN ゲートウェイとデータベースのファイアウォールは、VPC 内でコネクタに割り当てられたレンジを許可する必要があります。オフィスのアドレスでも、サービスの公開 egress アドレスでもありません。ルールを一つ書く前に、そのレンジをコンソールで確認してください。

さらに二か所が一致している必要があります。VPC ルート テーブルにはリモート データベース ネットワークへのルートが必要で、リモート側にはコネクタ レンジへの戻りルートが必要です。トンネルがトラフィック セレクタを使う場合は、コネクタ レンジがネゴシエートされた範囲内にあることを確認してください。リモートからローカル方向にしか存在しないルートはよくある見落としで、ping は通るのに TCP ハンドシェイクが完了しません。

VM サブネットだけを許可するトンネルは、コネクタのパケットを有用なエラーも出さずに破棄します。だからデータベースのタイムアウトが認証情報の問題に見えるのです。

DNS は別の経路を通る

プライベート データベースのホスト名は、コネクタが到達するネットワーク内で、Cloud DNS ピアリングまたは VPC が使える転送ゾーンを通じて解決される必要があります。ワークステーションで解決できても、デプロイされたサービスについては何も証明できません。ノート PC はそのリゾルバを使っていないからです。

VPC 内から名前が公開アドレスに解決されるなら、間違ったファイアウォールをデバッグしようとしています。

URL Fetch はコネクタを使わない

egress 設定はランタイムの通常の送信ソケットを対象とし、レガシーの URL Fetch サービスはその経路に含まれません。urlfetch 経由のリクエストは、設定が何と言おうとコネクタを無視します。失敗する呼び出しが URL Fetch をまだ使う古いライブラリ内にある場合、修正はその呼び出しを標準の HTTP クライアントへ移すことです。

データベース ドライバではめったに問題になりませんが、同じサービスから一方のエンドポイントが動き、他方が動かない古典的な理由です。

狭いクエリ一つで検証する

デプロイしたら、デプロイ済みバージョンから許可されたデータベース操作を一つ実行し、リモート側を観察します。データベースや VPN ゲートウェイが記録する送信元アドレスはコネクタのものであるはずです。そうでなければ、リクエストは VPC に入っておらず、トンネル設定では直りません。コンソールで調べたレンジと比較してください。不一致は通常、別のコネクタがそのバージョンを処理していることを意味します。

VPC 内の VM からのクエリ成功は、ルートが存在することを示します。サービスがそれを選んだことまでは示しません。

関連記事