AWSで「マルチホーム」に挑むあなたへ：複数ENIのルーティングを「郵便配達」で理解する
こんにちは！現場のSREとして日々クラウドの裏側を覗いていると、たまに「なぜかパケットが戻ってこない！」という悲鳴のような相談を受けることがあります。
特に、1台のEC2インスタンスに複数のネットワークインターフェース（ENI）を突き刺す、いわゆる「マルチホーム構成」を組んだとき、この沼にハマる人は後を絶ちません。
「パケットは届いているのに、なぜかレスポンスが返らない」。そんな時、カーネルの中で何が起きているのか。今日は、郵便配達の仕組みに例えながら、一緒に紐解いていきましょう！
—
1. なぜ「2つ目の入り口」から帰れないのか？
想像してみてください。あなたは巨大なマンションの管理人です。このマンションには「表通りに面した正面玄関（ENI 0）」と「裏路地にある通用口（ENI 1）」の2つの入り口があります。
普段は正面玄関から手紙（パケット）が届き、正面玄関から返事を出すのが当たり前。これがOSの「デフォルトゲートウェイ」です。
ところが、ある日突然、裏路地の通用口から「お荷物です！」と手紙が届きました。あなたは律儀にその手紙を受け取ります。しかし、返事を出すとき、あなたはこう考えます。
「よし、宛先に返事を出そう！……おっと、私のルールブック（ルーティングテーブル）には『すべての郵便は正面玄関から出せ』と書いてあるな。じゃあ、正面玄関に持っていこう！」
ここが問題です。裏路地で受け取った手紙の返事を、わざわざ正面玄関まで運んで出そうとする。これでは、受け取り側（送信元）は「えっ、裏路地から出したはずなのに、なんで正面玄関から返事が来るの？ 偽物じゃない？」と怪しんでパケットを捨ててしまうのです（これを「非対称ルーティング」といいます）。
2. Linuxの「賢いルール」を作ろう（ip rule / ip route）
OSはデフォルトで「一番メインのルート」しか知りません。そこで私たちは、Linuxの ip rule を使って、「裏路地（ENI 1）から来た手紙には、必ず裏路地から返事をする」という特例ルールを書き加えてあげる必要があります。
これを実現するために、以下の3ステップで設定を行います。
ステップ1：専用のルーティングテーブルを作る
まず、デフォルトとは別に「通用口専用の地図」を用意します。
# 「custom_table」という名前のテーブルを定義します
echo "200 custom_table" | sudo tee -a /etc/iproute2/rt_tablesステップ2：ルールを定義する
次に、「通用口（ENI 1）のIPアドレス宛の通信は、この専用地図を使え」というルールを命令します。
# 10.0.2.100はENI 1のIPアドレスと仮定します
# このIP宛の通信は、さっき作った「custom_table」を参照させます
sudo ip rule add from 10.0.2.100 table custom_tableステップ3：通用口への帰り道を教える
最後に、その地図に「通用口を通って帰るための道順」を書き込みます。
# 通用口（ENI 1）のサブネットゲートウェイを10.0.2.1と仮定します
# eth1は設定対象のインターフェース名です
sudo ip route add default via 10.0.2.1 dev eth1 table custom_tableこれで、裏路地から来たパケットは、ちゃんと裏路地から返事を出せるようになります。郵便配達員も迷子になりませんね！
—
3. 現場で忘れてはいけない「落とし穴」
この設定、実は再起動すると消えてしまう「儚い設定」なんです。現場で使う際は、OSの起動スクリプトやネットワークマネージャー（Netplanやnetwork-scripts）の設定ファイルに永続化させるのが鉄則です。
また、AWS特有の注意点として「ソース/宛先チェック（Source/Destination Check）」があります。
EC2インスタンスは、デフォルトで「自分宛てじゃないパケット」を流すことを拒否します。もし、このENIを使ってNATルーターやファイアウォールを構築しようとしているなら、AWSマネジメントコンソールで、そのENIの「ソース/宛先チェック」を無効化するのを忘れないでください。これを忘れると、いくらLinuxの設定を完璧にしても、AWS側のネットワーク層でパケットが「お前は通行禁止だ！」と弾かれてしまいます。
—
最後に：一歩ずつ、着実に
「複数のインターフェースを持つ」ということは、ネットワークの視点で見れば「複数の道路を管理する」のと同じです。最初は難しく感じるかもしれませんが、「どこから来たパケットを、どこへ返すのか」というパケットの旅路を一つひとつ追いかければ、必ず見えてくる景色があります。
インフラの世界は、こうした小さな「ルール書き込み」の積み重ねです。もしトラブルが起きても、慌てずに ip route get <送信元IP> コマンドなどで、「今、OSはどのルートを使おうとしているのか？」を覗いてみてください。
あなたのAWSライフが、より安定したものになりますように。応援しています！
コメント