NATゲートウェイの深淵：ICMP「Destination Unreachable」とパケット追跡の技術論
こんにちは。クラウドインフラの現場で幾多のパケットロスと格闘してきたSREです。
皆さんは、プライベートサブネットにあるインスタンスから外部APIを叩いていて、突如として Connection timed out や Host unreachable に遭遇したことはないでしょうか。そんな時、皆さんはどうしますか？ 多くのエンジニアが curl で疎通確認し、パケットキャプチャを仕掛け、ログを追いかけます。しかし、NATゲートウェイ（NATGW）という「ブラックボックス」を通過する際、ICMPパケットがどう変換され、どのように戻ってくるのかまでを正確にイメージできている人は意外と少ないものです。
今日は、RFC仕様に基づくNATGWのICMP変換ロジックと、実務で役立つデバッグの勘所について、少し深い話をしましょう。
—
NATGWにおけるICMP変換の裏側
プライベートインスタンス（10.0.x.x）が外部へ通信する際、NATGWは送信元IPをパブリックIPへと書き換えます（SNAT）。しかし、宛先がダウンしている場合や、経路上のルーターがパケットを破棄した場合、ICMP Type 3（Destination Unreachable）が返ってきます。
ここで重要なのは、NATGWがこの「エラーメッセージ」をどうやってプライベートインスタンスへ戻すかという点です。
ICMPの「ペイロード」が運命を握る
ICMPエラーメッセージは、自分を発生させた「元のパケットのヘッダー」を自身のペイロード部分に含めて返信します。NATGWはこれを見逃しません。
1. 受信: NATGWは外部から届いた ICMP Type 3 パケットをインターセプトします。
2. 分析: NATGWはペイロード内に埋め込まれた「元のIPヘッダーとTCP/UDPヘッダー」を精査します。
3. 逆変換: ここで、NATGWの接続追跡テーブル（Conntrack）を参照します。元のパケットの送信元IP/ポートが、どの内部インスタンスと対応していたかを特定します。
4. 書き換え: NATGWは、ICMPペイロード内のヘッダーを「元のプライベートIP」に戻し、ICMPパケット自体の宛先IPも内部インスタンスのものに書き換えて転送します。
この仕組みがあるからこそ、我々のアプリケーションは「誰が、どの通信でエラーを返したか」を正しく認識できるのです。
—
現場で役立つ確認用コードとデバッグTips
では、実際に疎通確認を行う際の視点をコードと共に整理しましょう。単に curl を打つだけでなく、どこで詰まっているかを特定するのがプロの仕事です。
1. Pythonによる詳細な疎通確認
標準の requests ではなく、タイムアウトを細かく制御できる socket を用いると、ICMPエラーをより正確に検知できます。
import socket
# 外部のAPIサーバー（ここでは例としてデッドエンドなIPを使用）
target_host = "192.0.2.1"
target_port = 443
def check_connectivity():
try:
# タイムアウトを短めに設定し、反応を待つ
with socket.create_connection((target_host, target_port), timeout=5) as sock:
print("接続成功！")
except socket.timeout:
print("警告: 接続タイムアウト。NATGWのセキュリティグループか、宛先がパケットをドロップしています。")
except ConnectionRefusedError:
print("エラー: 接続拒否。相手は生きていますがポートが空いていません。")
except OSError as e:
# ここでICMPエラーが返ってくるとOSErrorがキャッチされます
print(f"致命的なエラー: {e}")
check_connectivity()2. トラブルシューティングの定石：VPCフローログの活用
NATGW経由の通信がうまくいかない場合、パケットが「どこまで届いて、どこで消えたか」を確認するために、AWSであれば VPC Flow Logs を確認します。
ACCEPTかREJECTか: NATGWのENIでREJECTされていれば、セキュリティグループ（SG）またはネットワークACLの問題です。BYTESが 0 か: 通信は発生しているが、応答が全く返ってきていない証拠です。この場合、宛先サーバーでのパケットフィルタリングや、NATGWの送信元IPが宛先側でホワイトリスト化されていない可能性を疑います。
—
よくある落とし穴：MTUとパケットサイズ
私がこれまで解決してきた障害の中で、意外と多いのが「MTU（最大転送単位）」の問題です。
NATGWを通るパケットは、カプセル化などのオーバーヘッドにより、通常の通信よりもサイズが大きくなる傾向があります。もし、経路上でMTUが制限されている場合、大きなパケットは「フラグメント（分割）」されるか、あるいは ICMP Fragmentation Needed が返されます。
対策コマンド（Linux）:
# パケットサイズを大きく指定して ping を打つ（-M do はフラグメント禁止フラグ）
# これでパケットが通らなければ、MTU調整が必要です
ping -M do -s 1472 8.8.8.8もしこれが通らなければ、アプリケーション側で TCP MSS Clamping を検討するか、オーバーレイネットワークのMTUを調整する必要があります。
—
最後に：ネットワークを「視覚化」せよ
NATGWやICMPの変換挙動を理解することは、トラブルを「運」ではなく「論理」で解決するための必須スキルです。
- 「パケットは必ず変換される」
- 「ICMPはペイロードの中身を読み解く鍵になる」
- 「フローログとMTU設定は、エンジニアの最後の砦」
これらを押さえておけば、どんなに複雑なマルチクラウド環境でも、パケットの行き先を見失うことはありません。皆さんの現場でのトラブルシューティングが、少しでもスムーズになることを願っています。
何か具体的なネットワーク構成でハマっていることがあれば、いつでも相談してください。現場の知見で回答します。
コメント