GCP の VM への Cloud VPN：NAT IP ではなく内部 IP を使う

ゲートウェイのエンドポイント、VM の内部アドレス、外部の一対一 NAT アドレスは、それぞれ異なる役割を持ちます。どれをルートが使っているかを確認してください。

オンプレミスのネットワークが Cloud VPN 経由で VPC に到達すると、Compute Engine のサービスの宛先は通常 VM の内部アドレスになります。外部 IPv4 アドレスは、同じプライベートルートに置き換えて使える二つ目のアドレスではありません。この分野の混乱の多くは、三つの役割を持つ三つのアドレスを互換的なものとして扱うことから生じます。まず、あるパケットがどれを使っているのかを名指しするところから始めてください。

三つのアドレス、三つの役割

どれかをデバッグする前に三つとも名指ししてください。答えによって、次に調べる対象が変わるからです。

AddressJob
Cloud VPN endpointwhere the IPsec peers meet
Internal IPthe address your route and firewall must name
External IPv4the platform's inbound mapping, not a guest address

一つ目はトンネルに属します。二つ目はルートとファイアウォールの設計に属します。三つ目は受信のインターネットアクセスに属し、マッピングされるものであって、アタッチされるものではありません。どれか一つでうまくいく設計は、残りの二つについて何も語りません。

外部アドレスが二つ目のインターフェースではない理由

アドレス指定ガイドは、Compute Engine で内部と外部の到達性がどう異なるかについての権威です。Compute Engine の外部 IPv4 は、インスタンスの単一の内部 NIC への一対一のマッピングです。そのため、ゲストがその NIC 上で二つ目のインターフェースや二つ目のアドレスを見ることはありません。VM が内部で報告するのは、依然として一つの主内部アドレスです。

だからこそ、トンネル経由で 10.24.1.7 へルーティングするプライベートクライアントと、VM の外部アドレスを対象とするクライアントは別の経路にあります。公開アドレスに対してファイアウォールルールを開いても、トンネルのトラフィックを運ぶ必要がある VPC ルートは何も変わりませんし、ゲストのルートを編集してもプラットフォームのマッピングは動きません。ルートが名指しするアドレスを選び、そのアドレスを統制するオブジェクトだけを確認してください。この規律により、このトラブルシューティングの道筋から推測の大部分が除かれます。

gcloud で経路をたどる

インスタンスから始め、同じオブジェクトから両方のアドレスを読み取ります。どちらをドキュメントが指しているのかが分かります。

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

次に、経路が実際に依存するルーティングと権限を確認します。

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

トンネルが広告し学習した範囲を読む、ワークロードサブネットの VPC ルート、オンプレミスの送信元を許可するファイアウォールルールです。ゲスト上のリスナーが意味を持つ前に、この三つが一致している必要があります。

次にゲストを確認します。サービスは内部アドレスで待ち受けているか、戻り経路は VPC を通って戻るか。公開アドレスだけにバインドされたリスナーは、クラウド側のオブジェクトがすべて正しくても、このテストに失敗します。

公開プレフィックスは別の問い

以上のどれも、VPN 内で運ばれるすべてのアドレスが RFC1918 でなければならないという意味ではありません。リモートネットワークは、プラットフォームがルーティングをサポートし、運用者がアドレスの権限を持っていれば、公開空間から正当に採番できます。これは通常の設計上の選択です。

これは、通常の外部 NAT アドレスを別の内部サブネットアドレスのように扱うこととは違います。一方はルーティングするプレフィックスであり、もう一方はプラットフォームが受信アクセスに適用するマッピングです。

外部 IPv6 と特別に設計されたアドレス構成には独自の意味論があります。計画がそのいずれかに依存するなら、IPv4 の場合から一般化するのではなく、その機能のプラットフォームドキュメントを読んでください。IPv4 のマッピングは一般的なケースであって唯一のケースではなく、例外にはそれぞれ独自のルールがあります。

重複する範囲は別の問題

プライベート範囲の重複は、人が公開アドレスに手を伸ばす実際の理由であり、それは間違ったレバーです。宛先を VM の NAT アドレスに変えても重複は解決しません。パケットがどのアドレス宛だと主張するかが変わるだけで、戻り経路がどう機能するかは定義されません。

重複は意図的に解決してください。採番し直す、サポートされた変換設計を使う、プレフィックスが衝突しないネットワーク経由でルーティングする、のいずれかです。どれも担当者のいる設計です。NAT アドレスは設計ではありません。

二つのフィールドを別々に文書化する

トンネルのピアとワークロードの宛先を、二つの別々のランブックフィールドとして記録し、それぞれを支えるルートとファイアウォールルールを添えます。IPsec トンネルが上がったことは、両側が合意したことだけを伝えます。ワークロードがどのアドレスで到達可能かは何も語らず、プライベートルートが完全かどうかも語りません。

反対側の実クライアントで検証します。名前を解決し、内部アドレスが返ることを確認し、接続し、戻りのトラフィックを確認します。Compute Engine の IP アドレスのドキュメント が、上記で使った内部と外部の区別の参照先です。

関連記事