Zenn
🐯

IPアドレス枯渇の救世主！Cloud NAT の ハイブリッド NAT をご紹介

2024/10/11に公開
network
Google Cloud
VPC
cloudnat
hybridnetwork
tech

はじめに

こんにちは、\textcolor{red}{赤髪}がトレードマークの Shanks です。

皆さんは Google Cloud のフルマネージド NAT サービスである Cloud NAT をご存知でしょうか。
本日はその中でも新たに GA（一般提供）された「ハイブリッド NAT」についてご紹介します。

ReleaseNotes

https://cloud.google.com/nat/docs/release-notes#September_30_2024

Cloud NAT 概要

Cloud NAT とは

GCPSketchnote
図：What is Cloud NAT?? / 公式ブログより引用

Cloud NAT とは、Google Cloud のフルマネージド NAT（ネットワーク アドレス変換）サービスです。
Cloud NAT を使うことで、外部IPアドレスを持たない VM が Cloud NAT を通じてインターネットへアクセス可能になります。

ポイントは"フルマネージド"であることと、"SNAT（Source NAT）"であるという点です。

Cloud NAT アーキテクチャ
図：Cloud NAT アーキテクチャ / 公式ブログより引用

ポイント①：フルマネージド
フルマネージドとは、すべて Google Cloud によって管理してくれることを指します。
これにより、利用者は一度構築してしまえば「障害対応」「パッチ適用」「適切なスケールアップ/ダウン」などの保守・運用から開放され、大幅に運用コストを削減できます。

https://cloud.google.com/nat/docs/ports-and-addresses?hl=ja
https://cloud.google.com/nat/docs/troubleshooting?hl=ja

ポイント②：SNAT（Source NAT）
SNAT とは、多数の 送信元（VM）IPアドレス を別の IPアドレス に変換する機構のことです。
これにより、VM からはインターネットへアクセスできるが、外部からはアクセスされない安全なインターネットアクセスの経路を確保することができます。

https://cloud.google.com/nat/docs/overview?hl=ja
https://e-words.jp/w/SNAT.html

プライベート NAT とは

Private NAT
図：プライベート NAT 変換の例

プライベート NAT とは、Cloud NAT の構成の1つで Private-to-Private なアドレス変換をすることを指します。
これにより、プライベートIPアドレスからプライベートIPアドレスに変換することができます。

プライベート NAT には2種類存在します。
本記事では2のハイブリッド NAT をご紹介します。

  1. Network Connectivity Center の Private NAT
  2. ハイブリッド NAT

ハイブリッド NAT とは（新機能）

ハイブリッドNAT
図：ハイブリッド NAT 変換の例 / 公式ドキュメントより引用

ハイブリッド NAT とは、Cloud Interconnect または Cloud VPN を介して Google Cloud に接続されているオンプレミスネットワークやクラウド プロバイダ ネットワークとの間で Private-to-Private NAT を利用することができるものです。

ハイブリッド NAT の注目点

IP アドレス枯渇問題の解決

アドレス枯渇
図：IPアドレス枯渇

オンプレミスネットワークやクラウド プロバイダ ネットワークと Google Cloud との間で相互接続（閉域網接続や VPN 接続）をしているとよく遭遇するのが「IP アドレス枯渇問題」です。
Google Cloud 側のIPアドレス空間と、接続先ネットワーク空間とが重複すると正しく通信することができません。
そのため、双方でIPアドレス空間が重複しないよう設計する必要があります。

とはいえ、システムが大きくなり IP アドレス消費量が多くなると、IP アドレス不足に陥ってしまいます。
本来 Google Cloud はスケーラビリティに優れたインフラを持つため、このような状況ではその利点を活かせません。

そこで、ハイブリッド NAT を活用することで IP アドレス空間が重複していても IP アドレスそのものを変換させることで重複回避することができます。

影響を受けない安定した送受信性能

これはハイブリッド NAT に限らず Cloud NAT 全般に言えることです。
Cloud NAT を使用してもしていなくても、VM が使用できる送信または受信帯域幅の総量は変わりません。

つまり、利用者自身で何かしらの NAT 機構を用意するよりも、Cloud NAT を活用した方が安定したパフォーマンスを引き出すことができます。
大容量の通信であっても、帯域幅の仕様は VM のマシンタイプ毎の性能に依存します。

https://cloud.google.com/compute/docs/network-bandwidth?hl=ja

ハイブリッド NAT を構成してみた

アーキテクチャ

Architecture
図：アーキテクチャ

本記事を執筆するにあたり、2つの VPC ネットワークを作成しました。
また、それぞれに共通する IP アドレスを持つサブネットワークを作成しました。

VPC ネットワーク A のサブネット「Subnet1a」を利用する GCE インスタンスを作成し送信元とします。（src-vm）
VPC ネットワーク B のサブネット「Subnet2b」を利用する GCE インスタンスを作成し宛先とします。（dst-vm）

このままでは dst-vm からの戻りパケットが VPC ネットワーク B の Subnet2b サブネットを参照するため、Cloud VPN で接続しても src-vm ➜ dst-vm 間で正しく通信することができません。

src-vm:~$ curl -m 30 192.168.2.2 #(dst-vm ip)
curl: (28) Connection timed out after 30001 milliseconds

そのため、Cloud NAT をハイブリッド NAT で送信元 VPC ネットワークに構成します。

https://cloud.google.com/nat/docs/set-up-private-nat?hl=ja#create-private-nat

Cloud NAT の構成

Cloud NAT の詳細な設定についてはここでは割愛し、以下の3つのポイントに絞って解説します。

  • NAT タイプ
  • Cloud NAT マッピング
  • Cloud NAT ルール

Settings

ポイント① NAT タイプ
ハイブリッド NAT を利用する場合、NAT タイプは「非公開」に設定します。
これはインターネットへ公開しないプライベート NAT を構成するためです。

ポイント② Cloud NAT マッピング
送信元サブネットと IP 範囲には、「Cloud NAT で変換したい IP アドレス」を指定します。
本件の場合、Subnet1a（192.168.1.0/24）を変換するように指定します。

ポイント③ Cloud NAT ルール
Cloud NAT ルールには、カスタムルールを設定します。
カスタムルールとして設定すべき重要な点として「ハイブリッド接続のマッチング」に必ずチェックを入れるようにしましょう。
Terraform や gcloud コマンドを使用してマッチングルールを定義する場合は以下のように「nexthop.is_hybrid」を設定してください。

https://cloud.google.com/nat/docs/nat-rules-overview?hl=ja
https://cloud.google.com/nat/docs/using-nat-rules?hl=ja

gcloud beta compute routers nats rules create ${NAT_RULE_NUMBER} \
  --router=${ROUTER_NAME} \
  --nat=${NAT_CONFIG} \
  --match='nexthop.is_hybrid' \ # <= Important
  --source-nat-active-ranges=${NAT_SUBNET} \
  --region=asia-northeast1 \
  --project=${PROJECT_ID}

resource "google_compute_router_nat" "hybrid-nat" {
  provider                            = google-beta

  # 省略

  rules {
    rule_number = 100
    match       = "nexthop.is_hybrid"        # <= Important
    action {
      source_nat_active_ranges = [
        module.src.subnets["asia-northeast1/hybrid-nat"].self_link
      ]
    }
  }
}

疎通テスト

宛先（dst-vm）には nginx をインストールしておき、HTTP リクエストを待ち受けておきます。
送信元（src-vm）から Cloud NAT を経由して正しくリクエストが送信できるか確認しましょう。

到達性のシミュレーション

実際に HTTP リクエストを行う前に、Network Intelligence Center というプロダクトの機能である接続テストを用いて理論上の到達性をシミュレーションします。

ConnectTest

結果は、Cloud VPN で接続された VPN トンネル越しにパケットが到達できることが確認できました。
このように、机上の確認であってもそもそもの到達性を確認することでデバッグや検証をスムーズに行うことができます。
https://cloud.google.com/network-intelligence-center/docs/connectivity-tests/concepts/overview?hl=ja

HTTP アクセス

それでは実際に src-vm ➜ dst-vm 間で HTTP リクエストを行いましょう。
HTTP リクエストには curl コマンドを用いてアクセスします。

src-vm:~$ curl -I http://192.168.2.2:80
HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Tue, 08 Oct 2024 05:26:47 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 08 Oct 2024 04:46:18 GMT
Connection: keep-alive
ETag: "6704b91a-267"
Accept-Ranges: bytes

おめでとうございます🎉🎉🎉
正常にリクエストが到達しました。

IP アドレスが重複した相互接続を構成したとしても、Cloud NAT によって送信元 IP アドレスが NAT され、異なる IP アドレスからのアクセスとして認識されることがわかりました。

まとめ

本記事では、Cloud NAT の新機能であるハイブリッド NAT について紹介しました。

既存の Google Cloud との相互接続を結んでいるシステムにおいて、よくある問題として以下のようなものがあります。

  • 「IP アドレスの重複」
  • 「IP アドレスの枯渇」

これらの問題解決の1つの方法論として参考になれば幸いです。

Discussion