こんにちは！クラウドの世界へようこそ。AWSやGCPといったメガクラウドの世界では、サーバー（インスタンス）を安全に動かすために「パブリックサブネット」と「プライベートサブネット」という部屋を使い分けるのが鉄則です。
でも、「プライベートサブネットにあるサーバーから、どうしてもインターネットへ出ていきたい！」そんな時に登場するのが、お助けマンである「NATゲートウェイ（NAT Gateway）」ですよね。
今日は、このNATゲートウェイを通過する通信が「あれ、なんか繋がらないぞ？」となった時、ベテランSREたちはどうやって原因を突き止めるのか、その裏側のデバッグ手法を一緒に覗いてみましょう。難しい用語も身近な例えで優しく解きほぐしていくので、一歩ずつ理解していきましょうね！
—
1. 例え話でスッキリ！NATゲートウェイと通信の仕組み
まずは、パケット（データの小包）がどうやって旅をしているのか、現実世界の「郵便配達」に例えてイメージしてみましょう。
プライベートサブネットは「秘密基地」
プライベートサブネットにあるサーバーたちは、外の世界から直接お手紙（アクセス）をもらえない「秘密基地」の中にいます。セキュリティ的にはすごく安全なのですが、この基地の中にいるサーバーが「どうしてもインターネット上のアップデートサーバーから最新情報をダウンロードしたい！」と言い出しました。
外の世界に出るための「総合窓口（NAT）」
でも、秘密基地の住所は外の世界（インターネット）からは見えない特別なもの（プライベートIPアドレス）なので、そのままでは外にお手紙を出せません。
そこで登場するのが、秘密基地の門番である「NATゲートウェイ」です。
サーバーが外へお手紙を出すとき、NATゲートウェイはこう言います。
> 「おっ、外に出たいんだね？ じゃあ、この私（NATゲートウェイ）の名前と外用の住所（グローバルIPアドレス）に書き換えてから、外に投函してあげるよ！」
これが、IPアドレスを変換する「SNAT（Source Network Address Translation）」という仕組みです。外の世界からは、すべてNATゲートウェイという「代表者の窓口」からお手紙が届いているように見えます。
—
2. デバッグの二大武器：「VPCフローログ」と「パケットキャプチャ」
さて、そんなある日、「プライベートサブネットのサーバーから外に出られない！」というトラブルが発生したとします。ここで私たちが取り出すべき武器が、以下の2つです。
1. VPCフローログ（VPC Flow Logs）：通信の「通話明細書（誰と誰が通信しようとして、成功したか失敗したか）」
2. パケットキャプチャ（Packet Capture）：通信の「中身そのもの（お lembraの中身や封筒の宛先）」
まずは、この通話明細書であるVPCフローログの解析から始めてみましょう！
—
3. ENIレベルのVPCフローログ解析と「REJECT」の謎を追う
VPCフローログは、AWSなどのクラウド上で、ネットワークの出入り口（ENI：Elastic Network Interface）を通過するすべてのパケットの履歴を記録してくれる、いわば「防犯カメラのログ」です。
フローログの読み方とREJECTの正体
フローログを有効にすると、以下のようなテキストが出力されます。
# バージョン アカウントID ENIのID ソースIP 宛先IP 送信元ポート 宛先ポート プロトコル パケット数 バイト数 開始時刻 終了時刻 アクション ログステータス
2 123456789012 eni-0abcd12345ef67890 10.0.1.15 192.0.2.1 45123 443 6 15 1200 1600000000 1600000060 REJECT OK注目してほしいのは、末尾のほうにある REJECT という文字と、その手前の ACTION の部分です。ここが ACCEPT であれば通信成功ですが、REJECT になっている場合は「途中で門前払いされた」ことを意味します。
よくある「REJECT」の原因と切り分け
プライベートサブネットからNATゲートウェイへ向かう通信、あるいはNATゲートウェイから外へ向かう通信で REJECT が起きた場合、疑うべきポイントは主に以下の3つです。
1. セキュリティグループ（SG）の壁
- 送信元のサーバー（プライベート側）のセキュリティグループで、外向き（アウトバウンド）の通信が許可されていますか？ 「すべて許可（
0.0.0.0/0）」になっていますか？ ここが塞がっていると、そもそもお家から一歩も出られません。
2. ネットワークACL（NACL）の壁
- サブネットの門限であるNACLで、インバウンド・アウトバウンドのルールが厳しすぎて弾かれていませんか？ NACLは「ステートレス（行きと帰りのルールを個別に書く必要がある）」なので、返りの通信（エフェメラルポート）が許可されているか要チェックです。
3. ルートテーブルの迷子
- 「外の世界（
0.0.0.0/0）へ行くには、NATゲートウェイの方向に行きなさい」という道しるべ（ルート）が、プライベートサブネット側のルートテーブルに正しく書いてあるでしょうか？
—
4. SNAT前後のIPアドレス変化を追跡する
さあ、セキュリティグループやルートテーブルを正しく設定し、無事に通信が流れるようになったとします。ここでインフラエンジニアとして気になってくるのが、「本当にちゃんとIPアドレスが変換（SNAT）されているのか？」という点です。
これを追跡するには、NATゲートウェイを通る前と後で、IPアドレスがどう変化しているかを想像（またはキャプチャで確認）する必要があります。
追跡のステップ
1. 送信元（プライベートサブネットのインスタンス）
- IPアドレス：
10.0.1.15（プライベートIP） - この状態でパケットが送り出されます。
2. NATゲートウェイのENI
- ここでマジックが起きます。ソースIPが、NATゲートウェイに割り当てられたパブリックIPアドレス（例：
203.0.113.50）に書き換えられます。
3. インターネット上の宛先サーバー
- 宛先サーバーから見ると、通信の相手は
10.0.1.15ではなく、綺麗にスワップされた203.0.113.50からやってきたように見えます。
現場で使える！tcpdumpによるパケットキャプチャの基本
もし、インスタンスの内部や、踏み台サーバーからパケットの動きをリアルタイムで覗き見したい場合は、Linuxの tcpdump コマンドが非常に強力な相棒になります。
例えば、特定の宛先への通信をキャプチャしたい時は、次のようなコマンドを叩きます。
# 宛先IPアドレス「192.0.2.1」との通信を、ネットワークインターフェースを指定してキャプチャする
sudo tcpdump -i eth0 host 192.0.2.1 -nnvv
# 【パラメータの簡単な解説】
# -i eth0 : キャプチャするネットワークカードを指定
# host 192.0.2.1 : 指定したIPアドレスに関するパケットだけに絞り込む
# -nn : IPアドレスやポート番号を名前解決せず、数字のまま表示する（解析が早くなります）
# -vv : より詳細なヘッダー情報を表示するこのキャプチャ画面の中で、自分のプライベートIPから出ていったパケットが、NATゲートウェイを抜けた後にどんなIPアドレスを背負っているのかを追っていくと、「あ、ちゃんとSNATされているな！」と確信が持てるようになります。この瞬間が、ネットワークエンジニアにとってたまらない瞬間だったりします。
—
5. おわりに
パブリック/プライベートサブネットとNATゲートウェイ、そしてVPCフローログやパケットキャプチャを用いたデバッグ手法について、イメージを掴んでいただけたでしょうか？
最初は「暗号のようなログだな…」と感じるパケットの記録も、郵便配達や秘密基地の例えに置き換えてみると、データがどこでつっかえているのかが見えてきます。
「なぜ繋がらないのか？」に直面した時は、慌てずにフローログでREJECTを探し、セキュリティグループやルートテーブルという名の「門番と道しるべ」を一つずつ確認する。この基本のステップを踏めば、どんな複雑なクラウドネットワークのトラブルも必ず解決の糸口が見つかります。
皆さんのクラウドインフラライフが、より快適で安心なものになりますように。それではまた、次の技術でお会いしましょう！
コメント