こんにちは！クラウドインフラの世界へようこそ。SREとして日々さまざまなシステムの裏側を支えていると、「あれ、通信が急に繋がらなくなったぞ？」というミステリアスなトラブルに出くわすことがあります。
AWSのVPC（Virtual Private Cloud）を使っていて、「ルートテーブルの設定も完璧だし、宛先も間違っていないはずなのに、なぜかパケットが届かない……！」と頭を抱えた経験はありませんか？
その原因、もしかするとAWSの強力な門番であるセキュリティグループと非対称ルーティングのすれ違いが引き起こしているかもしれません。
今回は、ネットワークの世界に初めて足を踏み入えた方や、インフラの基礎を固めている方に向けて、この少し厄介で奥深い「非対称ルーティング問題」を、身近な例えを交えながら一緒に優しく解きほぐしていきましょう！
—
1. 郵便配達でイメージしよう！ステートフルなセキュリティグループ
まず、AWSの「セキュリティグループ」が普段どのように働いているのか、おなじみの「郵便配達」に例えて考えてみましょう。
セキュリティグループは、仮想サーバー（EC2インスタンスなど）のすぐ手前に立っている「超優秀な警備員」です。この警備員は「ステートフル（状態を覚えている）」という素晴らしい特性を持っています。
ステートフルってどういうこと？
例えば、あなた（EC2）が外のカフェにいる友人に手紙を出したとします。
1. 往きの通信： あなたが手紙を投函しました。警備員は「お、〇〇さん宛てに手紙を出すんだね」と、そのやり取りの「メモ（状態）」を手帳に書き留めます。
2. 帰りの通信： 後日、友人から返事が届きました。警備員は手帳を確認し、「あぁ、さっき〇〇さんに出した手紙の返事だな！」と納得し、中身をチェックすることなくスッとあなたに手紙を渡してくれます。
つまり、「行き（リクエスト）の通信を許可していれば、帰り（レスポンス）の通信は自動的に許可してくれる」というのが、ステートフルなセキュリティグループの優しい仕組みなんですよね。一歩ずつ、こうして理解していけば怖くありません！
—
2. 「行きと帰りで違う道を通る」非対称ルーティングとは？
順調に見える郵便配達ですが、ここにちょっとした「イタズラ」が加わると話が変わってきます。それが今回のテーマである「非対称ルーティング（Asymmetric Routing）」です。
通常の通信（対称ルーティング）は、行きに通った道路をそのまま引き返して帰ってきます。
しかし、複雑なネットワーク構成（複数のVPCを繋いだり、仮想アプライアンスを通したりする環境）では、次のようなことが起き得ます。
- 行き（リクエスト）： ルートAを通ってサーバーへ向かう
- 帰り（レスポンス）： ルートBという別の道を通って手元に帰ってくる
これが「非対称ルーティング」です。行きと帰りで通るルートがバラバラになってしまう状態のことですね。
—
3. なぜドロップされるのか？ 警備員の記憶喪失パニック
では、この非対称ルーティングが起きたとき、先ほどの警備員（セキュリティグループ）の身に何が起こるでしょうか？
舞台は、複数のネットワークインターフェース（ENI）を持つ複雑なEC2サーバーだと想像してください。
1. あなたからのリクエストが、「ルートA」を通ってサーバーの「インターフェース1」に到着しました。警備員Aは「よし、通信OK！」と手帳にメモをします。
2. サーバー側で処理が終わり、返事を出そうとしたとき、なぜかルーティングの設定ミスや経路の都合によって、「インターフェース2」から「ルートB」を通って外へ帰ろうとしました。
3. ここで問題発生です！インターフェース2の担当である「警備員B」からすると、こう言いたくなります。
> *「えっ？ 私、あなたの行きの手紙なんか見た覚えないんだけど！？ 手帳にメモもないのに、いきなり帰りの返事だけ通すわけにはいかないよ！」*
結果として、警備員Bはセキュリティポリシーに従い、容赦なくそのパケットをドロップ（破棄）してしまうのです。これが、非対称ルーティング発生時に通信がプツリと途切れるメカニズムです。
—
4. 実務でよくあるシチュエーションと回避策
こうした問題は、次のような実際のインフラ設計で顔を出しがちです。
- マルチホーム構成（複数のネットワークカードを持つインスタンス）： ファイアウォールやルーターとして動かすEC2に、複数のIPやENIをぶら下げているとき。
- 複雑なVPCピアリングやTransit Gatewayのルーティング： 往復のパケットで異なる経路が選択されてしまうとき。
では、どうやって回避すればいいのでしょうか？
現場のSREがよく使う代表的なアプローチをいくつかご紹介しますね。
① ルーティングテーブルを見直し、対称性を保つ
一番の基本は、「行きと帰りで同じ道を通るようにルートテーブルを美しく整える」ことです。
AWSのコンソールやTerraformなどで、次のようにルートを綺麗に定義してあげましょう。
# Terraformでのルートテーブル設定例（概念）
resource "aws_route" "example_return_route" {
route_table_id = aws_route_table.private_rt.id
destination_cidr_block = "10.0.1.0/24" # 宛先ネットワーク
gateway_id = aws_vpn_gateway.example.id # 行きと同じゲートウェイを通すように調整
}② ソース/宛先チェック（Source/Destination Check）の無効化
ネットワーク仮想アプライアンス（独自ルーターやNATインスタンスなど）をEC2で自作している場合、AWSのデフォルト機能である「自分が宛て先ではないパケットを捨てる機能」が邪魔をすることがあります。
その場合は、ENIの設定でこのチェックをオフにする必要があります。
# AWS CLIを使って、特定のENIのソース/宛先チェックを無効化するコマンド
aws ec2 modify-network-interface-attribute \
--network-interface-id eni-0123456789abcdef0 \
--no-source-dest-check*(※インフラの実務では、これを忘れると「パケットが転送されてこない！」と深夜に頭を抱える定番の罠になります。)*
—
5. おわりに：パケットの流れをイメージする楽しさ
今回は、セキュリティグループのステートフルな仕組みと、非対称ルーティングが引き起こすパケットドロップの悲劇について解説しました。
「パケットが今、どの扉をくぐり、誰にチェックされ、どこを通って帰ろうとしているのか？」
頭の中でこうしたネットワークの旅をありありと想像できるようになると、トラブルシューティングはパズルを解くようなワクワクする作業に変わっていきます。
もし現場で「あれ、通信できない？」という壁にぶつかったときは、ぜひ今回の「警備員の手帳の話」を思い出してみてくださいね。
それでは、また次回のクラウド・ネットワークの旅でお会いしましょう！
コメント