なぜNATインスタンスは「わがまま」を許される必要があるのか？ 〜ソース/宛先チェック無効化の正体〜
こんにちは！クラウドの深淵を覗き込み、時にその深淵から睨み返されているSREの私です。
AWSのVPC（Virtual Private Cloud）を触り始めると、必ずと言っていいほど「パブリックサブネット」と「プライベートサブネット」の境界線で頭を悩ませますよね。「インターネットに出たいけど、直接は外から見られたくない」というワガママな要望を叶えるために、多くのエンジニアがNATゲートウェイを配置します。
しかし、コストや特殊なルーティングの都合で「自分自身でEC2インスタンスを立ててNATルーターを作りたい！」という場面もあるはず。その時、必ずぶち当たるのが「ソース/宛先チェック（Source/Destination Check）の無効化」という設定です。
今日は、この一見地味な設定が、ネットワークの世界でどんなに重要な役割を果たしているのか、郵便配達の物語を交えて紐解いていきましょう。
—
郵便局のルール：送り主の詐称は許されない
まず、AWSのEC2インスタンスは、デフォルトで非常に「誠実」に作られています。
想像してみてください。あなたは今、郵便局の配達員です。あなたの仕事のルールはこうです。
「自分以外の名前が差出人として書かれている荷物を、決して配達してはいけない」
もしあなたが「佐藤さん」として荷物を預かったのに、差出人の欄に「田中さん」と書いてあったらどうしますか？ 郵便局としては「これは偽造かもしれないから、一旦破棄しよう」となりますよね。これが、AWSがデフォルトで行っている「ソース/宛先チェック」の正体です。
なぜこれがNATで問題になるのか？
NAT（Network Address Translation）の役割は、プライベートな住所（プライベートIP）から来た荷物を、自分の名前（NATインスタンスのIP）に書き換えて、インターネットという広い世界へ送り出すことです。
つまり、NATインスタンスは「他人の荷物を預かり、差出人を自分に書き換えて再発送する」という仕事をしています。これをデフォルトのEC2にやらせると、AWSのネットワークフィルターがこう言います。
「おいおい、お前は『EC2-A』のはずだろ？ なんで『EC2-B』の荷物を送ろうとしているんだ？ 偽造だな！ 破棄するぞ！」
これが、NATインスタンスでこのチェックを無効化しなければならない理由です。「君はルーターという特別な役割だから、差出人が誰であってもスルーしていいよ」という許可証を与える作業、それが「ソース/宛先チェックの無効化」なのです。
—
設定は驚くほど簡単。でも、意味は深く。
この設定を忘れると、プライベートサブネットのインスタンスからインターネットへの通信が、まるでブラックホールに吸い込まれるかのように消えてしまいます。現場で「パケットが飛んでいるはずなのに返ってこない！」と焦る原因のトップ3に入るトラブルです。
AWS CLIを使って、この「許可証」を出すコマンドを見てみましょう。
# 特定のインスタンスに対して「ソース/宛先チェック」を無効化するコマンド
# これでインスタンスは「他人の荷物を運ぶ配送業者」になれます
aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--source-dest-check "{\"Value\": false}"
# 設定が正しく適用されたか確認するコマンド
aws ec2 describe-instances \
--instance-id i-1234567890abcdef0 \
--query "Reservations[*].Instances[*].SourceDestCheck"このコマンドを実行した瞬間、そのインスタンスは「自分以外の荷物」を堂々と転送できるようになります。
—
SREからのアドバイス：運用上の注意点
この設定、便利ですが「諸刃の剣」でもあります。
本来、EC2インスタンスが自分宛てではないパケットを処理するのはセキュリティリスクです。もしNAT目的ではない普通のサーバーでこのチェックを無効化してしまうと、万が一乗っ取られた際に、そのサーバーが踏み台となって別の場所へ不正なパケットを送り出す「なりすまし攻撃」が容易になってしまいます。
現場の運用では、以下のルールを徹底しましょう。
1. NAT用途以外では絶対に無効化しない：不要な権限は最小限に。
2. セキュリティグループと組み合わせる：インスタンスレベルのチェックを外す分、セキュリティグループで「どのIPからの、どのポートへの通信なら許すか」を厳格に定義しましょう。
3. NATゲートウェイを再考する：運用負荷とコストを比較して、可能ならマネージドな「NATゲートウェイ」を使いましょう。AWSが全力で守ってくれるサービスを使えるなら、それに越したことはありません。
—
最後に：ネットワークは「流れ」を想像しよう
ネットワークエンジニアリングの面白いところは、目に見えないパケットの流れを、現実世界の物理的なルールに例えて想像できる点にあります。
「ソース/宛先チェック」という名前を聞くと難しく感じますが、「郵便配達員が、差出人欄を書き換える許可をもらうこと」だと思えば、少し親しみやすくなりませんか？
もし皆さんがこれからNATインスタンスを構築する機会があれば、この「許可証」を渡す瞬間に、パケットが元気に外の世界へ飛び出していく姿を想像してみてください。その時、きっとトラブルシューティングも少しだけ楽しくなるはずです。
それでは、良いクラウドライフを！次の現場でお会いしましょう。
コメント