【実務・中級編】 ルーティングテーブルの静的経路(Static Route)と動的経路(Dynamic Route) – ネットワーク基礎とWebセキュリティ実践ガイド

ルーティングの迷宮を制す:静的経路と動的経路の「優先順位」をエンジニアの視点で読み解く

ネットワークエンジニアの端くれとして、これまで数々の「繋がらない」という絶望と向き合ってきました。Web APIのレイテンシに悩み、パケットがどこで捨てられているのかを追いかける日々。そんなとき、最も基本的なはずの「ルーティング」が、実は一番の落とし穴であることに気づかされます。

今日は、インフラ運用やAPI設計に携わる皆さんのために、ルーティングの核心である「静的経路(Static Route)」と「動的経路(Dynamic Route)」、そしてそれらを決定づける「AD値(Administrative Distance)」について、現場の知見を交えて深掘りします。

ルーティングの「意思決定」:なぜパケットは迷わないのか

ルーティングとは、要するに「宛先IPアドレスを見て、次のルータのどこにパケットを投げればいいか」を決める、ネットワーク上の交通整理です。

  • 静的経路(Static Route): 管理者が手動で「このネットワークに行くなら、ここを通れ」と地図を描く方法。シンプルで確実ですが、障害時の自動切り替えは効きません。
  • 動的経路(Dynamic Route): OSPFやBGPといったプロトコルを使い、隣接ルータと「今、どっちの道が空いてる?」「ここが落ちたから別のルートを教えるよ」と会話して地図を自動更新する方法。

ここで重要なのが、「もし同じ宛先に対して、静的経路と動的経路の両方が存在したら、ルータはどうやって道を選ぶのか?」という問いです。

AD値(Administrative Distance):信頼性の重み付け

ルータは、複数の経路情報を受け取ったとき、その情報をどれくらい「信じていいか」を判断するために AD値 という指標を使います。この数字が「小さいほど信頼できる」というルールです。

| 経路の出所 | AD値 (デフォルト) |
| :— | :— |
| 直接接続 (Directly Connected) | 0 |
| 静的経路 (Static Route) | 1 |
| eBGP (External BGP) | 20 |
| OSPF | 110 |
| RIP | 120 |

例えば、OSPFで学習した経路と、手動で設定した ip route が競合した場合、AD値が 1 の静的経路の方が 110 のOSPFよりも「信頼できる」と判断され、ルーティングテーブルに優先的に載ることになります。これを理解していないと、冗長化構成で「なぜかバックアップ回線に切り替わらない」といった悪夢を見ることになります。

実践:ルーティングの現場的設定とデバッグ

まずはCiscoルータを想定した設定を見てみましょう。

# 静的経路の設定(宛先ネットワーク 10.2.0.0/24 へは 192.168.1.2 経由で送る)
# 管理距離(AD値)を明示的に指定することも可能
router(config)# ip route 10.2.0.0 255.255.255.0 192.168.1.2 1

次に、Pythonを使って、自身のルーティングテーブルがどのようにパケットを投げようとしているかを確認するスクリプトのイメージです。

import scapy.all as scapy

# 特定の宛先への経路をシミュレートする概念コード
def check_route(target_ip):
    # 実際にはOSのルーティングテーブルを参照するコマンド(ip route等)を叩く
    # Linux系であれば 'ip route get' コマンドの出力が最も信頼できる
    import subprocess
    result = subprocess.run(['ip', 'route', 'get', target_ip], capture_output=True, text=True)
    print(f"宛先 {target_ip} への経路情報:\n{result.stdout}")

# APIリクエストを投げる前に経路を確認するデバッグ手法
check_route("10.2.0.5")

APIエンジニアが知っておくべき「経路の落とし穴」

Web APIを開発・運用する際、curl でテストしてタイムアウトする場合、アプリの不具合を疑う前に、以下のコマンドで「どのゲートウェイを通ろうとしているか」を必ず確認してください。

# 経路の可視化。どのノードでパケットが迷走しているか(またはドロップしているか)がわかる
traceroute -T -p 443 api.example.com

特にクラウド環境(AWSのVPCルーティングテーブルやAzureのルートテーブル)では、静的経路が非常に強力に機能します。0.0.0.0/0 を IGW(インターネットゲートウェイ)に向けるか、NAT GW に向けるか。このルーティング設定一つで、APIのセキュリティ境界(境界防御)がガラリと変わります。

現場からのアドバイス:運用を楽にするために

1. 静的経路の「放置」は禁物: ネットワーク構成が変わったのに残っている静的経路は、後にトラブルの温床になります。設定には必ず「誰が、いつ、何のために」書いたか、コメントを残してください。
2. AD値のカスタマイズ: 冗長化構成で「普段はOSPFを使いたいが、特定のテストの時だけは手動経路を優先したい」といった場合、AD値を調整するテクニックがあります。ただし、これは劇薬なので運用チーム全員で共有すること。
3. パケットの気持ちになる: 迷ったら tcpdump です。「パケットは正しいインターフェースから出て行っているか?」「戻りのパケットは正しい経路を通ってきているか(非対称ルーティングの確認)?」を常に意識してください。

ルーティングは、ネットワークという広大な海を渡るための羅針盤です。静的か動的か、どちらか一方が優れているわけではありません。適材適所でこれらを使いこなし、堅牢なアーキテクチャを設計することが、真のプロフェッショナルへの第一歩です。

皆さんのネットワークが、今日も淀みなく流れることを祈っています。

コメント

タイトルとURLをコピーしました