【実務・中級編】 ICMPトラフィック（Echo Request/Reply）におけるNATマッピングの例外処理 – クラウド＆コンテナネットワーク実践ガイド

その「ping」がNATゲートウェイを通り抜ける仕組み：ICMP識別子の知られざる舞台裏

エンジニアの皆さん、お疲れ様です。インフラ現場でトラブルシューティングをしていると、「インターネットへの疎通確認は ping（ICMP）でいいや」と安易に考えてしまいがちですよね。

しかし、AWSの NAT Gateway や GCPの Cloud NAT が、プライベートサブネットからの ICMP をどうやって「正しく」外の世界に送り出し、そして「誰宛て」に戻せばいいのかを判断しているか、深く考えたことはありますか？

TCPやUDPなら ポート番号 があるからマッピングは簡単です。でも、ICMP にはポート番号がありません。そこで主役として登場するのが、ICMPヘッダーに含まれる 「識別子（Identifier）」 です。今回は、ネットワークの深淵を覗く、この「ICMP NATマッピング」の裏側を紐解いていきましょう。

—

ICMPの識別子（Identifier）が果たす「ポート代用」の役割

TCP/UDPが 送信元ポート と 送信先ポート でコネクションを追跡するのに対し、ICMP（Echo Request）には 識別子 と シーケンス番号 というフィールドが存在します。

NATゲートウェイはこの 識別子 を、いわば「疑似的なソースポート」として扱います。

通信シーケンスのリアル

1. Request: プライベートIPから送信された ICMP Echo Request がNATゲートウェイに到達。
2. 変換: NATゲートウェイは、送信元のプライベートIP＋識別子を、NATゲートウェイ自身のパブリックIP＋（書き換えた）識別子へとマッピングし、接続追跡テーブル（Conntrack）に記録します。
3. Reply: インターネット側からの ICMP Echo Reply が戻ってきた際、NATゲートウェイはパケット内の 識別子 を見て、どの内部ホストが投げたリクエストに対する応答かを照合し、元のプライベートIPに変換して戻します。

もしこの 識別子 が重複したり、NATゲートウェイの管理テーブルから溢れたりすれば、ネットワークは「誰への応答かわからないパケット」として破棄せざるを得ません。これが「pingは通るのにパケットロスが激しい」という現場でよくある悲劇の正体です。

—

エラーメッセージ（Destination Unreachable）の逆変換プロセス

さらに複雑なのが Destination Unreachable のような ICMP エラーメッセージです。これらのパケットは、本来の送信先から「お前のパケットは届かなかったぞ」という警告です。

ここでNATゲートウェイは、エラーメッセージのペイロード（データ領域）に含まれる元のIPヘッダーを読み解く という離れ業を行います。

解析: NATゲートウェイはエラーパケット内の「オリジナルパケット情報」を確認。
逆引き: その情報から「どのセッションに対するエラーか」を特定し、NAT変換を巻き戻して内部ホストへ転送。

この複雑な処理を行っているからこそ、私たちはクラウド内からでも「ネットワークがどこで詰まっているか」を traceroute などで可視化できるのです。

—

実践：デバッグのためのTipsとコード例

開発現場で疎通確認を行う際、単に ping を打つだけでなく、環境に応じた適切なツール使いが必要です。

1. PythonでICMPの挙動をシミュレートする（生のソケット操作）

scapy を使うと、NAT越えの挙動を理解するためのパケット構築が可能です。

from scapy.all import IP, ICMP, sr1

# 内部IPから外部への疎通確認
# 識別子(id)を明示的に指定してパケットを構築
packet = IP(dst="8.8.8.8")/ICMP(id=0x1234, seq=1)/"Hello, NAT!"

# パケットを送信し、応答を待つ
reply = sr1(packet, timeout=2)

if reply:
    # 応答パケットからIDを確認
    print(f"Reply ID: {reply[ICMP].id}")
else:
    print("NATゲートウェイにより破棄されたか、タイムアウトしました")

2. curlでの疎通確認（TCP/HTTP層の確認）

ICMPがブロックされている環境（セキュリティグループやNACLで制限されている場合）では、curl で対象のポートを確認する方が実務的です。

# -v: 詳細表示
# --connect-timeout: タイムアウトを短く設定して素早くチェック
curl -v -k --connect-timeout 3 https://api.example.com/health

—

運用上の教訓：NATゲートウェイの限界

最後に、SREとしてこれだけは覚えておいてください。

ポート枯渇問題: ICMPの識別子は65535個しかありません。NATゲートウェイ1台あたりの同時接続数には上限があります。大量の監視スクリプトが同一のNATゲートウェイを通ってpingを打ち続けると、ICMPの識別子が枯渇し、他の通信（TCP等）にも影響を及ぼす可能性があります。
デバッグの鉄則: ネットワークが繋がらない時、ping だけを信じないでください。traceroute や mtr を使い、どのホップでパケットが落ちているかを特定しましょう。

NATゲートウェイは「魔法の箱」ではありません。パケットを書き換え、記憶し、変換するという過酷な肉体労働を黙々とこなす、精緻なステートフル・ファイアウォールであることを忘れないでください。

皆さんのインフラ構築が、より堅牢で、トラブルの少ないものになることを祈っています！