迷宮のパケットを読み解く：NATゲートウェイと境界防御の深淵
クラウドインフラの設計において、プライベートサブネットからインターネットへ向かうトラフィックの制御は、単なる「繋がる・繋がらない」の話ではありません。特にAWSにおけるNATゲートウェイ（NAT GW）を介した通信は、ブラックボックス化されがちですが、その裏側ではネットワークインターフェース（ENI）とステートフルなフィルタリングが密接に絡み合っています。
本稿では、セキュリティグループ（SG）とネットワークACL（NACL）が、パケットの往来においてどのような順序で、どのような物理的制約を受けながら評価されるのか、その「現場のリアル」を紐解いていきます。
1. パケットがNATの門を叩くとき：評価順序の決定論
まず前提として、パケットは「送信元から宛先へ」と流れる単なるデータではありません。TCPであれば3ウェイハンドシェイクを経て確立される「コネクション」の一部です。
セキュリティグループは「境界の番人」、NACLは「サブネットの壁」
- セキュリティグループ (SG): ステートフルです。戻りのパケットは、往きのフローが許可されていれば自動的に許可されます。インスタンス単位のENIにアタッチされます。
- ネットワークACL (NACL): ステートレスです。インバウンドとアウトバウンドを個別に定義する必要があります。サブネット単位で適用されます。
NAT GWを通過するパケットのライフサイクルにおける評価順序は以下の通りです。
1. 送信側インスタンス (アウトバウンド):
- インスタンスのSG（許可）→ サブネットのNACL（許可）
2. NATゲートウェイ (変換):
- ここでパケットの送信元IPがNAT GWのパケットIPにSNAT（Source NAT）されます。
3. IGW経由のインターネット側 (アウトバウンド):
- NAT GWのSG（許可）→ NAT GWサブネットのNACL（許可）
ここでの落とし穴： NAT GW自体にSGを適用することはできません。NAT GWが配置されたサブネットのNACLが、戻りのパケット（エフェメラルポート範囲）を許可していない場合、いくらインスタンス側でSGを調整しても通信は遮断されます。エフェメラルポート（1024-65535）の許可を忘れる事故は、今なお現場で頻発する初歩的かつ致命的なミスです。
2. パフォーマンスの極致：TCPバッファとRTTの最適化
パケットがNAT GWを通過する際、暗黙的に発生するオーバーヘッドを無視してはなりません。特に、高スループットが求められるマイクロサービス間通信では、カーネルレベルのチューニングが必須となります。
TCPバッファの最適化
クラウド環境でのBDP（帯域遅延積）を考慮し、デフォルトのTCPウィンドウサイズを拡張します。
# sysctlによるカーネルパラメータの調整
# 読み取り/書き込みバッファの最大値を拡張し、RTTが大きい通信でのスループットを向上させる
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"TLSハンドシェイクの「泥」を払う
TLS 1.3の採用は必須ですが、NAT GW通過時のレイテンシを最小化するには、TCP Fast Openの検討が必要です。接続確立とデータ送信を同時に行うことで、RTTを1回分削減できます。
# TCP Fast Openを有効化（クライアント側）
sysctl -w net.ipv4.tcp_fastopen=33. 現場で遭遇する「パケットロス」の真犯人
NAT GWの最大の問題は、そのスケーラビリティ制限とSNATポート枯渇です。1つのNAT GWが処理できる最大同時接続数は約55,000ポートまでです。
SNATポート枯渇の兆候
監視メトリクス ErrorPortAllocation が跳ね上がったとき、パケットはNAT GWの入り口でドロップされます。ログに現れないこの損失は、アプリケーションのタイムアウトとして観測されます。
回避策:
1. コネクションプーリング: アプリケーション側で接続を使い回す（HTTP/2やgRPCの活用）。
2. NATゲートウェイの分散: サブネットごとにNAT GWを分離するアーキテクチャへの移行。
3. VPCエンドポイントの活用: S3やDynamoDBへの通信をNAT GW経由からVPCエンドポイント経由に切り替えることで、NAT GWの負荷を劇的に削減できます。
結び：ネットワークは「生き物」である
クラウドネットワークは、クラウドプロバイダーが提供する抽象化レイヤーの集合体ですが、その裏側にあるカーネルやプロトコルの挙動は、Linuxのそれと何ら変わりません。NACLとSGをパズルのように組み合わせ、パケットが最短距離で効率的に転送される経路を設計することこそ、我々SREが果たすべき究極の責務です。
「なぜ繋がらないのか」と悩んだ時、まずはパケットのステートがどこで断絶しているのか、その論理的な境界線をトレースしてください。物理は見えなくとも、プロトコルは常に真実を語りかけています。
コメント