【入門編】ローカルルート(Local Route)のオーバーライド不可能性と例外処理 – クラウド＆コンテナネットワーク実践ガイド

クラウドの「絶対ルール」を知る：VPCの「ローカルルート」をハックする技術

こんにちは！クラウドのインフラを触っていると、「どうしてもこのパケットを特定の場所へ曲げたい！」というシーンに直面することがありますよね。

特に、VPC（Virtual Private Cloud）というクラウド上の自分専用ネットワークを設計するとき、一番最初に突き当たる「鉄の掟」があります。それが「ローカルルート（Local Route）のオーバーライド不可能性」です。

今回は、この少し難しそうなテーマを、郵便配達に例えて紐解いていきましょう。ネットワーク初心者の方も、ぜひ最後までお付き合いくださいね。

—

そもそも「ローカルルート」って何者？

VPCを作るとき、皆さんは最初に「このネットワークは 10.0.0.0/16 を使うよ」といったCIDRブロックを決めますよね。これがVPCの「住所の管轄範囲」です。

AWSやGCPなどのクラウド環境では、このCIDRブロックに対して、「VPC内の住所宛てなら、勝手に直接届けておくよ！」という「ローカルルート」が自動的に設定されます。

郵便配達で例えると…

同じ社屋（VPC）の中で書類を届けるとき、わざわざ外の郵便局（ルーター）を通す必要はありませんよね。社内のメール便ボックスに入れれば、直接隣のデスクに届くはずです。

この「社内便のルール」がローカルルートです。クラウドの仕様として、このルールは「どんなルート設定よりも優先される（オーバーライドできない）」と決まっています。つまり、後から「この宛先への通信は、一度ファイアウォールを通してから届けて！」と命令しようとしても、クラウドは「いや、同じ社内だから直接届けるよ！」と無視してしまうのです。

—

なぜこれが「困った問題」になるのか

例えば、セキュリティ要件で「VPC内のインスタンス同士の通信であっても、必ず途中の検証用アプライアンス（IDS/IPSなど）を経由させたい」というケースがあるとします。

普通にルートテーブルに「10.0.0.0/16宛てはアプライアンスへ送れ」と設定しても、クラウドは「10.0.0.0/16への通信はローカルが最優先！」と判断して、アプライアンスを華麗にスルーして直接相手に届けてしまいます。

これが、「ローカルルートのオーバーライド不可能性」が引き起こす、現場泣かせの挙動です。

—

例外的に通信をインターセプトする「魔法」

では、私たちは泣き寝入りするしかないのでしょうか？実は、実務の世界ではいくつかの「回避策」を組み合わせて解決します。

1. サブネットを細かく切り分ける（基本戦術）

ローカルルートは「VPCのCIDRブロック全体」に対して適用されます。逆に言えば、「VPC全体」ではなく「もっと小さなサブネット単位」で考えれば、別のルールを適用できることがあります。

例えば、VPC全体が 10.0.0.0/16 だとしても、サブネットを 10.0.1.0/24 と 10.0.2.0/24 に分けてみましょう。もし、このサブネット間を必ず特定の場所経由にしたいなら、以下のような工夫をします。

Transit Gateway（TGW）を活用する

TGWなどの高度なネットワークコンポーネントを使うと、サブネット間のトラフィックを強制的に「ハブ」を経由させることが可能になります。

2. 仮想アプライアンスを挟む（実用テクニック）

もしあなたがAWSを使っているなら、Gateway Load Balancer を検討するのが現代の正攻法です。

# 例えば、ルートテーブルの設定をCLIで行う際のイメージ
# 実際にはサブネット単位でルートを適用し、特定のIP範囲を
# アプライアンスのネットワークインターフェース（ENI）へ向ける
aws ec2 create-route \
    --route-table-id rtb-12345678 \
    --destination-cidr-block 10.0.2.0/24 \
    --network-interface-id eni-abcdefgh # ここでアプライアンスを通す！

rtb-12345678: 対象のサブネット用ルートテーブル
10.0.2.0/24: 宛先（相手のサブネット）
eni-abcdefgh: 検査用アプライアンスのID

こうすることで、VPCのデフォルトのローカルルートではなく、「明示的に設定したルート」がサブネット間通信において優先されるようになります。

—

まとめ：ネットワーク設計は「地図」を描くこと

ローカルルートが優先されるのは、クラウドが「最短距離で届けるのが一番効率的で安全」と判断しているからです。しかし、セキュリティや監査の都合上、あえて「遠回り」をさせたい場合、私たちは以下のステップで設計を考えます。

1. 「VPC全体のローカル通信」という大原則を受け入れる
2. どうしても制御したい通信は「サブネット間」または「TGW越え」の構成にする
3. 特定のルートテーブルで、より詳細な宛先（サブネット単位）を定義して上書きする

ネットワークのトラブルシューティングは、時にパケットがどこへ消えたのかを追う泥臭い作業になります。ですが、こうして「なぜクラウドがそのパケットをそう動かしたのか」を理解すると、不思議とトラブル解決が楽しくなってくるはずです。

最初は難しく感じるかもしれませんが、まずは「VPCは広いオフィス、サブネットは部署」とイメージして、パケットの旅路を想像してみてください。きっと、明日からのインフラ構築が少しだけ楽しくなるはずですよ！

それでは、良いクラウドライフを！