ハイブリッドクラウドの「郵便局」：GCP InterconnectとCloud NATの連携を紐解く
みなさん、こんにちは！日夜クラウドの海を泳ぎ回っているSREです。
「ハイブリッドクラウド」という言葉を聞いて、どんなイメージを浮かべますか？オンプレミスのデータセンターと、キラキラしたクラウド（GCP）が専用線で繋がっている様子ですよね。でも、いざネットワークを組もうとすると、「オンプレのサーバーから外部のAPIを叩きたいんだけど、どうやって外に出るの？」「プライベートIPのままでインターネットに出ていいの？」といった疑問が次々と湧いてくるはずです。
今日は、そんな皆さんのために、GCPの「Cloud NAT」がオンプレミス環境の通信をどうやってインターネットまで送り届けているのか、身近な例えを交えてじっくり解説していきます。
—
そもそも、なぜ「NAT」が必要なの？
いきなりですが、インターネットの世界には「プライベートIPアドレス」と「パブリックIPアドレス」という二種類の住所があります。
- プライベートIP: 社内や自宅の中だけで通じる「あだ名」みたいなもの。
- パブリックIP: インターネットという広い世界で通用する「正式な郵便番号と住所」。
オンプレミスのサーバーが持つIPアドレスは、基本的にプライベートなもの。このまま「外部のAPIサーバー（郵便局）」に手紙を出しても、宛先不明で戻ってきてしまいます。そこで登場するのが「NAT（Network Address Translation：ネットワークアドレス変換）」という仕組みです。
これを郵便に例えるなら、「海外に荷物を送る際に、個人の名前ではなく、一度『国際配送センター』でまとめてから、センターの代表名義で発送してもらう」という流れです。この国際配送センターの役割をGCP上で担っているのが Cloud NAT なのです。
—
InterconnectとCloud NATが織りなす「魔法のルート」
GCPの Cloud Interconnect を使っていると、オンプレミスとGCPはまるで同じ敷地内にあるかのように通信できます。しかし、オンプレミスから「インターネット上の外部API」へアクセスする場合、パケットは次のような旅をします。
1. 出発: オンプレのサーバーがパケットを出す。
2. 橋渡し: Cloud Interconnect を通り、GCPのネットワーク（VPC）に到着。
3. 変換（ここが肝！）: GCP上の Cloud NAT がパケットをキャッチ。「君の住所はプライベートだから、僕のパブリックIPに書き換えてあげるよ」とスタンプを押す。
4. 到着: インターネット上のAPIサーバーへ。
5. 帰宅: 戻ってきたパケットも、Cloud NAT が元の宛先（オンプレのサーバー）を覚えていて、正しく転送する。
この仕組みがあるおかげで、オンプレミスのサーバーにわざわざ高いパブリックIPを割り当てたり、複雑なファイアウォール設定をしたりする必要がなくなるんです。
—
実践：Cloud NATを構築してみよう
では、実際にGCP上でどのように設定するか、Terraformコードを例に見ていきましょう。難しく考えず、「郵便局の窓口を作る」イメージです。
# Cloud Routerの設定（郵便局の支店長のような存在）
resource "google_compute_router" "router" {
name = "hybrid-nat-router"
network = "your-vpc-network" # あなたのVPCネットワーク名
region = "asia-northeast1"
}
# Cloud NATの設定（ここで変換ルールを定義します）
resource "google_compute_router_nat" "nat" {
name = "my-cloud-nat"
router = google_compute_router.router.name
region = google_compute_router.router.region
nat_ip_allocate_option = "AUTO_ONLY" # 自動でパブリックIPを割り当てる
source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES" # 全ての通信を対象にする
# ログ設定を有効にすると、後でトラブルシューティングが楽になります
log_config {
enable = true
filter = "ERRORS_ONLY"
}
}ここがポイント！
nat_ip_allocate_option = "AUTO_ONLY": これを設定しておけば、GCP側が勝手にパブリックIPを確保してくれます。source_subnetwork_ip_ranges_to_nat: ここをALL_SUBNETWORKS_ALL_IP_RANGESにすることで、オンプレミスからの通信もこのNATの恩恵を受けることができます。
—
運用時の落とし穴（トラブルシューティング）
現場でよくあるミスが「オンプレからの通信がNATを通らない」というケースです。
- ルート情報の確認: オンプレ側から見て、インターネット宛の通信が本当に
Interconnect経由でGCPのVPCに向かっているか確認してください。 - タグとファイアウォール: NATが正しく動いていても、GCPのファイアウォールルールで「オンプレからの通信を許可する」設定が漏れていると、パケットはそこで門前払いされてしまいます。
困ったときは、gcloud コマンドでNATのステータスを覗いてみるのが一番です。
# NATの動作状況を確認するコマンド
gcloud compute routers get-nat-mapping-info [ROUTER_NAME] \
--region=asia-northeast1このコマンドを打つと、どのプライベートIPがどのパブリックIPに変換されているか、リアルタイムの状況が見えてきます。まるで郵便局の仕分け棚を覗き込むような気分になれますよ！
—
最後に：一歩ずつ進めば怖くない
いかがでしたか？「NAT」と聞くと難しく感じますが、要は「プライベートな住所をパブリックな住所に書き換えて橋渡しする郵便局」のこと。
ハイブリッドクラウドは、最初は複雑に見えても、今回のように「パケットの流れ」を追いかけていくと、必ずどこかで「ああ、なるほど！」と繋がる瞬間が来ます。まずは小さな検証環境でNATを構築し、オンプレのPCから curl で外部サイトにアクセスできるか試してみてください。
その「成功した！」という体験が、皆さんのエンジニアとしての大きな自信になるはずです。それでは、良きクラウドライフを！
コメント