【テクニカル・上級編】パケットキャプチャとVPCフローログを用いたNATゲートウェイ通信のデバッグ手法 – クラウド＆コンテナネットワーク実践ガイド

境界線のパケット・レクイエム：NATゲートウェイのブラックボックスを解剖する

クラウドアーキテクトとして、我々は日々「パケットの旅路」を設計している。しかし、その旅がNATゲートウェイ（NATGW）という名の関所で止まったとき、多くのエンジニアは「何が起きているのか」を解明できずに途方に暮れる。

VPCフローログのREJECTログや、理解不能なコネクションタイムアウト。これらは単なるエラーではない。ネットワークスタックが発する「助けを求める叫び」だ。本稿では、NATGWというブラックボックスを剥ぎ取り、その深部で何が起きているのかを、SREの視点から紐解いていく。

—

1. NATGWの裏側：SNATの「不可逆性」を追跡する

NATGWは、プライベートサブネットのインスタンスが持つローカルIPを、自身のEIP（Elastic IP）へと変換する。このSNAT（Source NAT）処理が行われる際、ヘッダーの情報は書き換えられる。

ここで重要なのは、「VPCフローログをどこで取得するか」だ。

インスタンスのENI: NATGWへ向かう通信の「素のパケット」が見える。
NATGWのENI: SNAT後の「パブリックIPに変換されたパケット」が見える。

もし特定の通信がREJECTされているなら、まずはNATGWのENIでフローログをフィルタリングするべきだ。特に注意すべきは、packetsとbytesのフィールドである。これらが0のままREJECTされているなら、セキュリティグループ（SG）やネットワークACLではなく、ルーティングテーブルの不整合や、IGW（Internet Gateway）への経路欠損を疑う必要がある。

2. パケットキャプチャで見る「見えないハンドシェイク」

フローログはあくまで統計データだ。真のトラブルシューティングには、tcpdumpによるパケットキャプチャが不可欠である。NATGW経由の通信において、特に深刻なのが「TCPハンドシェイクのスタック」だ。

例えば、クライアントがSYNを送信し、SYN-ACKが戻ってこない場合、以下の要因を切り分ける必要がある。

1. TCPバッファ枯渇: sysctlで設定されたnet.ipv4.tcp_rmemやnet.ipv4.tcp_wmemが小さすぎて、輻輳制御アルゴリズムがパケットをドロップしている。
2. MSS（Maximum Segment Size）の不一致: Path MTU Discovery（PMTUD）がICMPをブロックすることで失敗し、巨大なパケットがブラックホールに消えている。

以下のコマンドは、NATGW経由の通信においてMSSサイズを強制的に制限し、パケット損失を回避するための診断用コマンドだ。

# 特定のインターフェースでTCPフラグを監視し、SYNパケットのMSSを確認する
sudo tcpdump -ni eth0 tcp[tcpflags] & tcp-syn != 0 -vv
# MSSが1460を超える場合、VPNやトンネル経由でフラグメントが発生している可能性が高い

3. パフォーマンス最適化：輻輳制御とRTTの極意

我々SREにとって、NATGWはボトルネックの温床だ。特に、多数の同時接続を行うマイクロサービスでは、NATGWの「ポート枯渇」が頻発する。

これを回避するための現代的なアプローチは、TCPの輻輳制御アルゴリズムをbbrへ変更することだ。従来のcubicよりも、bbrは高レイテンシ・高パケットロス環境で圧倒的なパフォーマンスを発揮する。

# カーネルパラメーターでBBRを有効化する
cat <<EOF | sudo tee /etc/sysctl.d/99-network-perf.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# 接続切断後のTIME_WAIT状態を再利用し、ポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1
EOF

# 反映
sudo sysctl -p /etc/sysctl.d/99-network-perf.conf

4. セキュリティ：TLSハンドシェイクとヘッダー圧縮

アプリケーション層に目を向ければ、TLS 1.3の導入は必須だ。TLS 1.2と比較して、ハンドシェイクのRTTが1往復削減される。NATGWを通る通信において、この1往復の短縮は、ユーザー体験におけるミリ秒単位のレスポンス向上に直結する。

また、HTTP/2やgRPCを使用している場合、ヘッダー圧縮（HPACK/QPACK）が重要になる。NATGWを通過するパケット数が減ることで、NICの割り込み処理負荷が軽減され、結果としてスループットの安定性が向上する。

トラブルシューティングのチェックリスト

REJECT判定: セキュリティグループの戻り通信（Ephemeral Port）が許可されているか？
パケット損失: netstat -s で TCPRetransSegs が急増していないか？
NATGWメトリクス: ErrorPortAllocation メトリクスがスパイクしていないか？

最後に：ネットワークは「生き物」である

パケットはただ転送されるデータではない。それはインフラの健康状態を映す鏡だ。VPCフローログという「ログ」と、パケットキャプチャという「実測」を組み合わせることで、初めて隠れた問題が見えてくる。

教科書通りの構築はあくまでスタートラインに過ぎない。あなたが直面しているそのREJECTは、ネットワーク設計を一段階上のレベルへ引き上げるための、システムからの貴重なフィードバックなのだ。

さあ、次はどのパケットを追いかけようか？