NAT Gateway経由の通信をVPCフローログから追跡する

はじめに

NAT Gatewayで何が起きている？
PrivateSubnetからNAT Gatewayを利用してインターネット接続を行う構成において
VPCフローログからどのように通信が見えるのかを確認します。

ドキュメントの以下の部分についてVPCフローログで確認します。

プライベート NAT ゲートウェイとパブリック NAT ゲートウェイはどちらも、インスタンスの送信元プライベート IPv4 アドレスを NAT ゲートウェイのプライベート IPv4 アドレスにマッピングしますが、パブリック NAT ゲートウェイの場合、インターネットゲートウェイはパブリック NAT ゲートウェイのプライベート IPv4 アドレスを NAT ゲートウェイに関連付けられた Elastic IP アドレスにマッピングします。

概要

VPCフローログから通信を追跡して、どのように見えるのか確認する

• 確認対象の通信：EC2 → インターネット上のサーバー
• 通信経路：
  • リクエスト：EC2 → NAT Gateway → Internet Gateway → インターネット
  • レスポンス：インターネット → Internet Gateway → NAT Gateway → EC2

結論

パブリック NAT Gatewayで EC2 のプライベートIPアドレスと送信元ポートを
NAT Gateway のプライベートIPアドレスへ送信元NAPTを行っていることが確認できた。

グローバルIPアドレスへの変換はVPCフローログからだけでは不明。
→ドキュメントの解釈を、InternetGatewayでグローバルIPアドレスにNATしているとすれば2段階の送信元NATが行われている。

構成

全体構成図

主要リソース

• PrivateSubnet
  • EC2
  • デフォルトルート：NAT Gateway
• PublicSubnet
  • NAT Gateway
  • デフォルトルート：Internet Gateway
• VPCフローログ
  • VPCに設定
  • 送信先タイプ：cloud-watch-logs
  • ログ形式：標準属性全て

※おまけでOpenSearchと統合して可視化もやってみる
　以下の記事をご覧ください。

VPCフローログはVPC/サブネット/ENI単位で設定可能であるが、いずれにおいても設定した範囲のENIのトラフィックをログとして出力する
今回はVPCに設定しているが、VPCにリソースが多い場合はNAT GatewayとEC2のENIに設定でOK

検証手順

１．リソース作成

EC2 , NAT Gaatewayを構成図の通り構築

２．VPCフローログ設定（今回はVPCへ設定）

フローログレコードに含めるフィールド：標準フィールド全て
※今回はどのように出力されるのか確認のため標準フィールド全て含めています。

３．EC2からインターネット上のWebサイトへの通信を行う

今回はgoogle.com (172.217.26.238) を通信先とする
EC2で接続先のIPアドレスを確認

PS C:\Windows\system32> nslookup google.com
Server:  ip-10-10-10-2.ap-northeast-1.compute.internal
Address:  10.10.10.2

Non-authoritative answer:
Name:    google.com
Addresses:  2404:6800:4004:808::200e
          172.217.26.238

curlで上記のIPアドレス172.217.26.238宛に通信を発生させる

PS C:\Windows\system32> curl.exe -I -L http://172.217.26.238/

---一部抜粋---
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8

X-Frame-Options: SAMEORIGIN
HTTP/1.1 200 OK
Expires: Sun, 11 May 2025 05:00:21 GMT

PS C:\Windows\system32>

通信の成功HTTP/1.1 200 OKを確認！

フローログ出力確認

今回はログのインサイトを利用して対象ログを抽出します。

通信ログを抽出

今回は CloudWatch のログのインサイトを利用して抽出し、表計算ソフトで整理しました。
※生データを一括DLして外部ツールや表計算ソフトを使って抽出でも可

CloudWatch > ログのインサイト

クエリ

fields 
  start,
  end,
  srcAddr,
  srcPort,
  pktSrcAddr,
  dstAddr,
  dstPort,
  pktDstAddr,
  flowDirection,
  interfaceId,
  logStatus
| filter srcAddr   = "172.217.26.238"
        or dstAddr   = "172.217.26.238"
        or pktSrcAddr= "172.217.26.238"
        or pktDstAddr= "172.217.26.238"
| sort start asc

結果（今回検証中にcurlを2回実行したため、12レコード出力されています）

検証結果（通信ログを整理して分かったこと）

IPアドレスとポートから通信順にログを整理した結果。
※時系列start順では誤差がある可能性のあるため

start : 集約間隔内にフローの最初のパケットが受信された時間 (UNIX 秒)。これは、パケットがネットワークインターフェイス上で送信または受信されてから最大 60 秒になる場合があります。

EC2プライベートIPアドレス：50114 から NAT Gateway プライベートIPアドレス：54035
↓
パブリック NAT Gatewayで EC2 のプライベートIPアドレスと送信元ポートを
NAT Gateway のプライベートIPアドレスへ送信元NAPTを行っていることが確認できた。
※グローバルIPアドレスへの変換はVPCフローログからだけでは不明。

curl.exe -I -L http://172.217.26.238/ 実行時の通信ログ

通信イメージ

グローバルIPアドレスへの変換部分は今回のログからだけでは不明のため、
公式ドキュメントの記載に則りInternet Gatewayでマッピングと記載しています。

パブリック NAT ゲートウェイの場合、インターネットゲートウェイはパブリック NAT ゲートウェイのプライベート IPv4 アドレスを NAT ゲートウェイに関連付けられた Elastic IP アドレスにマッピングします。

おわりに

（EC2でWiresharkやtcpdumpなどでパケット確認してVPCフローログと突き合わせるのも楽しそう）
VPCフローログをCloudWatchからOpenSearchと統合を利用してダッシュボード作成も実施したの以下をご覧ください。