【入門編】 ICMPパケット(Ping/Traceroute)のNATゲートウェイ経由における挙動 – クラウド＆コンテナネットワーク実践ガイド

こんにちは！SRE兼クラウドアーキテクトの私です。

日々、AWSやGCPといったメガクラウドの海に飛び込み、Kubernetesの複雑なネットワークの波を乗りこなしていると、「あれ、なんでこのパケットは宛先に届かないんだ？」というトラブルに直面することがよくあります。インフラの現場はいつだって生きたドラマの連続です。

さて、今回はそんなネットワークの世界でも、特に初心者の方が「おや？」と首をかしげやすいテーマを取り上げます。それは、「NATゲートウェイを通るICMPパケット（PingやTraceroute）の挙動」です。

「パケット？ NAT？なんか難しそう……」と思ったそこのあなた、安心してください！一歩ずつ、身近な例えを交えながら優しく紐解いていきましょう！

—

1. そもそもNATゲートウェイってどんな場所？（現実世界で例えてみよう）

パケットの旅に出る前に、まずは舞台となる「パスタやピザのデリバリー」を想像してみてください。

ここに、外の世界（インターネット）に出られない、プライベートなマンションの一室（プライベートサブネット）があります。この部屋に住んでいるインスタンス君は、外の世界へ荷物を送りたいのですが、自分の部屋の住所（プライベートIPアドレス）をそのまま外に出すわけにはいきません。なぜなら、その住所は世界中にたくさんある「どこにでもある部屋番号」だからです。

そこで登場するのが、マンションの管理人さんである NATゲートウェイ です！

管理人さんは、プライベートな部屋から荷物を受け取ると、自分の外向きの立派な住所（グローバルIPアドレス / パブリックIPアドレス）に書き換えて、外の世界へ送り出してくれます。そして、外から返事が返ってきたら、「あ、これはあの部屋のインスタンス君宛てだな」とメモ帳（NATテーブル）を確認して、元の部屋番号に直して届けてくれるのです。

この「住所の書き換え」こそが、NAT（Network Address Translation）の正体なんですよ。

—

2. プライベートインスタンスからの「Ping（ICMPエコー）」の旅立ち

さて、プライベートインスタンス君が、外の世界（例えば Google の 8.8.8.8 など）に向かって「生きてますか〜？」と Ping（ICMPエコーリクエスト） を投げたとき、何が起きるでしょうか？

ここで、HTTP通信（Webブラウザで見るとき）であれば「ポート番号」という目印があるのですが、ICMPパケットには、Webのようなポート番号がありません。その代わり、ICMPには 「識別子（Identifier）」 という、いわば荷物に押された「整理券番号」のようなものが入っています。

NATゲートウェイでの魔法の処理

1. プライベートインスタンスの出発
インスタンス君が、整理券番号 1234 を持ったPingをNATゲートウェイに投げます。
2. NATゲートウェイでの書き換え
NATゲートウェイは、「おっ、外に行くんだな！」と自分のパブリックIPアドレスに送信元を書き換えます。このとき、ICMPの整理券番号（識別子）も、他の通信と被らないように必要に応じて番号を付け替えることがあります。
3. 外の世界への到着
宛先のサーバーには、「NATゲートウェイのIPアドレス」から「整理券番号 5678（書き換え後）」のPingが届きます。
4. 返事の帰還
宛先サーバーは「お、返事を返すぞ！」と、NATゲートウェイのIPアドレス宛てに「ポン！」とPingの返事（ICMPエコーリプライ）を投げ返します。

管理人さん（NATゲートウェイ）は、メモ帳を見ながら「これはさっきのインスタンス君の整理券だ！」と紐付け、無事にプライベートインスタンスへPingの返事を届けてあげるのです。めでたし、めでたし……と言いたいところですが、話はそう単純ではありません。

—

3. トラブル発生！「TTL超過メッセージ」はどうやって戻ってくるの？

皆さんは、宛先までの道順を調べるために traceroute（Windowsなら tracert）コマンドを使ったことはありませんか？

あれは、パケットに「寿命（TTL: Time To Live）」という歩数制限をだんだん厳しく設定しながら、「今の私の位置はどこですか？」と途中のルーターに聞き込みをしながら進む仕組みです。

もし歩数が切れてしまうと、途中のルーターはパケットを捨てて、元の送信元に対して「あーあ、歩数が切れちゃいましたよ（TTL Exceeded）」という エラー通知（ICMPエラーパケット） を送り返します。

ここで、インフラエンジニアの頭を悩ませるポイントがあります。

エラー通知の中身を覗いてみよう！

途中のルーターが送ってくるエラー通知の中には、「どのパケットが原因でエラーになったか」という元のパケットのヘッダー情報（IPヘッダーやICMPの最初の部分）がすっぽり包まれて含まれています。

しかし、プライベートインスタンスが最初に投げたときのパケットの送信元IPアドレスは、まだ自分の「プライベートIPアドレス」でしたよね。途中のルーターから見ると、そのエラー通知の宛先は「NATゲートウェイのパブリックIPアドレス」になっています。

ここでNATゲートウェイの腕の見せ所です！

1. 途中のルーターから、NATゲートウェイ宛てに「TTLが切れました」というエラー通知が届きます。
2. NATゲートウェイは、そのエラー通知の中身（お行儀よく包まれている元のパケットの断片）をチラッと見て、「おや、これに含まれている整理券番号は、さっきあのプライベートインスタンス君が使っていたものじゃないか！」と気づきます。
3. NATゲートウェイは、エラー通知全体の宛先（IPアドレス）を、NATテーブルの記憶を頼りにプライベートインスタンスのIPアドレスに書き換えて、部屋まで届けてあげます。

これによって、プライベートインスタンス上で動いている traceroute コマンドは、「おっ、今のルーターはあそこだな」と正しく道順を把握できるというわけです。パケットの裏側で、管理人さんがこんな緻密なパズルを解いているなんて、ちょっと健気だと思いませんか？

—

4. 実務で役立つ！AWSのVPCにおけるNATゲートウェイとICMPの注意点

さて、ここまで綺麗にお話してきましたが、実際のクラウド（AWSのVPCなど）を触るときには、いくつか現実的な壁や注意点があります。実務でハマりがちなポイントをコードや設定例を交えて見ていきましょう。

実務での設定例：ルートテーブルの確認

プライベートサブネットからインターネット（または他のVPC）へ通信を抜けるようにするには、ルートテーブルのルーティング設定が不可欠です。以下は、AWSのTerraformコードでプライベートサブネットからNATゲートウェイへトラフィックを向ける典型的な設定例です。

# プライベートサブネット用のルートテーブル
resource "aws_route_table" "private_rt" {
  vpc_id = aws_vpc.main.id

  # 0.0.0.0/0（すべての宛先）へのトラフィックをNATゲートウェイに向ける
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat.gateway.id
  }

  tags = {
    Name = "prod-private-route-table"
  }
}

# プライベートサブネットとルートテーブルの関連付け
resource "aws_route_table_association" "private_assoc" {
  subnet_id      = aws_subnet.private.id
  route_table_id = aws_route_table.private_rt.id
}

よくあるトラブル：なぜかPingが通らない？

「あれ？ルートテーブルも設定したし、NATゲートウェイもあるのに、外に向かって ping を打っても返事が返ってこないぞ？」という現場のトラブルによく遭遇します。

これにはいくつかの原因がありますが、代表的なものは以下の通りです。

1. セキュリティグループ（Security Group）やネットワークACLのブロック
AWSのセキュリティグループはステートフルですが、ICMPの扱いはプロトコルやタイプ（エコーリクエストとエコーリプライ）によって意図せずブロックされることがあります。
2. 宛先サーバー側のファイアウォール（セキュリティポリシー）
世の中の多くのパブリックなサーバー（GoogleやAWSのサービスなど）は、セキュリティ上の理由（DDoS攻撃対策など）から、ICMP（Ping）の応答をあえて無視（ドロップ）するように設定されています。そのため、「NATやネットワークが壊れている」のではなく、「相手が返事を返すなと言われているだけ」というケースが非常に多いのです。

トラブルシューティングの確認コマンド

もしパケットがどこで途切れているかを調査したい場合は、OSの標準コマンドだけでなく、クラウド上のネットワーク監視ツールや、インスタンス内からの tcpdump などを組み合わせて確認します。

# プライベートインスタンス内から、ICMPのやり取りをライブでキャプチャする例
# （eth0インターフェースを通過するicmpパケットを監視）
sudo tcpdump -nn -i eth0 icmp

# 宛先へのルートや応答性を確認するため、tracerouteを実行する例
traceroute -n 8.8.8.8

もし traceroute の途中で星印（* * *）ばかりになり、一向に宛先にたどり着かない場合、途中のルーターやファイアウォールがICMPエラーメッセージやUDP/TCPパケットを遮断している可能性を疑います。

—

5. まとめ

いかがでしたでしょうか？今回は、少し取っつきにくい「NATゲートウェイを通るICMPパケットの挙動」について、マンションの管理人さんや荷物の整理券に例えて解説してみました。

NATゲートウェイは、プライベートなIPアドレスとパブリックなIPアドレスの住所を綺麗に書き換えてくれる優秀な管理人さん。
ICMP（PingやTraceroute）のパケットも、整理券番号（識別子）を元にしっかり管理されている。
途中のルーターからのTTL超過エラー通知も、NATゲートウェイがちゃんと元の宛先に翻訳して連れ戻してくれる。
ただし、実務では宛先サーバー側のファイアウォール設定（Pingを無視する設定）などによる「仕様の壁」に阻まれることもあるので、多角的な視点でトラブルシューティングすることが大切。

ネットワークの仕組みは、一見すると複雑な魔法のようですが、一つひとつのパケットの気持ちになって追いかけてみると、とてもロジカルで面白いドラマが見えてきます。

日々のインフラ運用や設計で迷ったときは、ぜひ今回の「パケットの旅」を思い出してみてくださいね。それでは、また次回の技術解説でお会いしましょう！一歩ずつ、確実にスキルアップしていきましょう！