こんにちは！SREとして日夜クラウドとコンテナの海を泳いでいる、あなたの技術の伴走者です。
インフラやネットワークの世界へ一歩を踏み出したとき、最初に立ちはだかる「見えない壁」ってありますよね。その代表格が、「NAT（Network Address Translation）」と「フローログ」ではないでしょうか。
「サーバーから外のネットに繋がらない！でもエラーログには何も出てこない……」
そんな絶望的な夜、パケットたちがクラウドの裏側でどう変身させられているのかを知っていると、まるで名探偵のようにスルスルと原因にたどり着くことができます。
今回は、郵便配達の仕組みを例にしながら、NATゲートウェイの前後でパケットがどう変化するのか、そしてそれを「フローログ」を使ってどうやって追いかけるのかを、一緒に優しく紐解いていきましょう！一歩ずつ理解していけば、決して怖くありませんよ。
—
1. 例え話でスッキリ理解！NATゲートウェイとIPアドレスの秘密
まずは、パケットの旅を私たちの身近な世界に置き換えてみましょう。
会社の中と外をつなぐ「総務部（NATゲートウェイ）」
想像してみてください。あなたはとある大きな会社の、外のネットからは直接見えない安全な部屋（プライベートサブネット）で働いています。
この部屋にいるあなたのパソコンには、社内専用のIPアドレス（例：10.0.1.10）が割り当てられています。
さて、あなたが会社の外にあるネットショップ（外部APIやサーバー）に注文の品を頼みたくなりました。
ここで問題が発生します。社内専用のIPアドレスは、会社の外の世界では通用しない「秘密の番号」なのです。外の世界から返事をもらおうにも、郵便配達員はあなたの部屋の場所を知りません。
そこで登場するのが、会社の出入り口にいる「総務部（NATゲートウェイ）」です。
1. あなたが荷物（パケット）を外に送るとき、総務部の人はいったんあなたの荷物を受け取ります。
2. 総務部の人は、荷物の送り主ラベルを、会社の代表である外向きの住所（NATのグローバルIPアドレス：203.0.113.5）に書き換えます。
3. さらに、社内でのあなたの番号だけでなく、総務部が管理する「受付番号（一時的なポート番号：50001）」を新しく割り振って記録帳にメモします。
4. 相手のネットショップから荷物が届くと、総務部はメモ帳をペラペラとめくり、「あ、これはさっきの10.0.1.10の彼宛てだな」と気づき、再び宛先をあなたの部屋番号に戻して届けます。
これが、NAT（Network Address Translation）の魔法です。パケットは、この出入り口を通過するときに「身分証（IPアドレスとポート番号）」を書き換えられているんですね。
—
2. フローログとは？ ネットワークの「監視カメラ映像」
「通信がうまくいかない！」というとき、私たちは何を手がかりにすればよいのでしょうか。
そこで頼りになるのが、AWSの VPC Flow Logs や Azure/GCP の NSG Flow Logs といった「フローログ」です。
これはネットワークの「防犯カメラの記録映像」のようなものです。いつ、どのIPアドレスの、どのポートから、どの宛先へ向かって、どれくらいのデータが流れたのかが、文字のログとしてすべて記録されています。
フローログの代表的な項目（フィールド）を見てみましょう。
srcaddr（ソースアドレス）：送信元のIPアドレスdstaddr（デスティネーションアドレス）：宛先のIPアドレスsrcport（ソースポート）：送信元のポート番号dstport（デスティネーションポート）：宛先のポート番号action：通信が許可されたか（ACCEPT）、拒否されたか（REJECT）
通信トラブルが起きたとき、このログを追うことで「パケットがどこで迷子になっているのか」を突き止めることができます。
—
3. 実践！NAT変換の前後をフローログで追跡するデバッグ手順
それでは、実際の現場でよくあるトラブルを想定して、フローログを使ったデバッグのステップを体験してみましょう。
シナリオ：プライベートサブネットのコンテナから外部APIに繋がらない！
Kubernetesのポッド（またはEC2などの仮想マシン）から、外部の決済APIサーバー（198.51.100.50）へデータを送ろうとしたところ、タイムアウトエラーが発生してしまいました。
「ファイアウォール（セキュリティグループやルートテーブル）の設定ミスなのかな？」と疑う前に、フローログを調査してみましょう。
ステップ1：プライベートサブネット側のログを確認する
まずは、問題が発生しているコンテナ（プライベートIP: 10.0.1.100）が所属するネットワークインターフェイスのフローログを探します。
# 【ログ例 1】プライベートサブネットから外へ出ていく通信
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-0abcd12345ef 10.0.1.100 198.51.100.50 45678 443 6 1 60 1680000000 1680000060 ACCEPT OKこのログから、以下のことが分かります。
- 送信元 (
srcaddr):10.0.1.100（コンテナのIP） - 宛先 (
dstaddr):198.51.100.50（外部API） - 送信元ポート (
srcport):4568 - 判定 (
action):ACCEPT（AWSの内部ネットワークとしては通そうとした）
「おっ、プライベート側からはきちんとパケットが出発しているぞ」ということが確認できました。次は、いよいよNATゲートウェイを通過した後の世界を覗き見します。
ステップ2：NATゲートウェイのパブリック側（外向き）のログを確認する
NATゲートウェイ自体のENI（ネットワークインターフェイス）で取得したフローログを確認します。ここが一番のポイントです！NATを通過したパケットは、IPアドレスが「会社の代表住所」に書き換わっているはずです。
# 【ログ例 2】NATゲートウェイを通過して外の世界へ向かう通信
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-9876543210fed 203.0.113.5 198.51.100.50 50001 443 6 1 60 1680000000 1680000060 ACCEPT OKおや、注目してください！
- 送信元 (
srcaddr):10.0.1.100だったものが、NATのパブリックIPである203.0.113.5に綺麗に変換（NAT）されています。 - 送信元ポート (
srcport):45678だったものが、NATゲートウェイによって割り振られた50001に変わっています。
ここまで来て action が ACCEPT であれば、あなたのクラウド環境からは「正常にパケットが外の世界へ旅立った」ということが証明されます。
ステップ3：それでも繋がらないときの切り分け
「クラウド側からは出ていっているのに、相手から返事が来ない」という場合、原因はもはやあなたのクラウド環境の中にはありません。
1. 相手先サーバー（198.51.100.50）側のファイアウォール問題:
相手が「203.0.113.5からのアクセスをブロックしている」可能性があります。相手側のシステム管理者に、このIPアドレスからのアクセス許可（ホワイトリスト登録）を依頼する必要があります。
2. ルーティング（経路）の不備:
往きはよいよい、帰りはこわい。NATゲートウェイを通ったあとのルートテーブル（インターネットGWへの経路など）が正しく設定されているかを確認します。
—
4. トラブルシューティングを加速させるための実用テクニック
現場のSREたちは、数百万行もある巨大なフローログのテキストファイルを目視で探したりはしません。効率的にデバッグするための小技をいくつかご紹介します。
AWS Athenaを使ったログのSQL検索
VPC Flow LogsをAmazon S3に保存し、AWS Athena（SQLでS3のデータを検索できるサービス）を使ってパケットの足取りを追うのがモダンなSREのやり方です。
例えば、特定のプライベートIPから出ていった通信が、どのNATのIPに変換されたのかを突き止めるには、以下のような簡単なSQLクエリを投げます。
-- プライベートIPを指定して、NAT変換の前後をすばやく特定するクエリ
SELECT
start,
interface_id,
srcaddr,
dstaddr,
srcport,
dstport,
action
FROM
vpc_flow_logs
WHERE
srcaddr = '10.0.1.100' -- 調査したいコンテナやVMのIP
AND start > cast(to_unixtime(current_timestamp - interval '1' hour) as bigint)
ORDER BY
start DESC
LIMIT 10;このように、時間を絞ってパケットの足跡を検索できるようにしておくと、障害発生時の復旧スピードが劇的に上がります。
—
まとめ：パケットの気持ちになってログを読もう
いかがでしたでしょうか？
「NATゲートウェイ」と聞くと難しそうに聞こえますが、要するに「社内専用の身分証を、外用の身分証に書き換える受付窓口」です。
そして「フローログ」は、その窓口の前後にある「監視カメラの記録」にすぎません。
通信断のトラブルに直面したときは、あせらずに以下の順番でパケットの足跡を追ってみてください。
1. プライベートサブネットからパケットが出発しているか？ (srcaddr がコンテナのIPか)
2. NATゲートウェイで正しくアドレスが書き換わっているか？ (srcaddr がNATのパブリックIPに変わっているか)
3. 宛先へちゃんと届く設定になっているか？ (action が REJECT になっていないか)
この一連の流れが頭のなかにイメージできるようになると、ネットワークのトラブルシューティングが楽しくなってきますよ。
それでは、また次回の技術の海でお会いしましょう！あなたのインフラライフが快適なものでありますように。
コメント