2026年9月8日

Policy Routing を確認する方法｜Linux の ip rule・ルーティングテーブル・fwmark と Cisco の PBR を読み解く

IPアドレス・ルーティング

Policy Routing（ポリシールーティング）を確認するには、「どのルールが、どの条件で、どのルーティングテーブルを選んでいるか」を順に見て、最後に「この送信元・この印のパケットは実際にどこへ出るか」をコマンドで問い合わせます。Linux なら ip rule show、ip route show table <番号>、ip route get ... from ... の3つで大半を確かめられます。この記事では、Linux での読み方と確かめ方、fwmark を使ったルールの追い方、設定が意図どおりに動かない典型的な原因、Cisco の PBR（Policy Based Routing）の確認コマンドを説明します。

通常のルーティングとの違い

通常のルーティングは宛先 IP だけを見て、1つのルーティングテーブルから経路を選びます。Policy Routing では、宛先より先に「送信元 IP」「受信したインターフェース」「パケットに付けた印（fwmark）」などの条件でルールを評価し、条件に合ったパケットに別のルーティングテーブルを使わせます。

よく使われる場面は次のようなものです。

回線を2本持つサーバーで、各回線のアドレス宛てに来た通信の応答を、来た回線から返す
VPN の通信だけ、または特定のアプリの通信だけを別の出口へ出す
社内の特定のセグメントだけを別のプロキシやファイアウォールへ通す

確認作業では、この「ルール → テーブル → 経路」の3段を分けて見ることが大切です。

手順1：ルールの一覧を見る（ip rule）

ip rule show
ip -6 rule show

何も設定していない Linux では、おおよそ次の3行が表示されます。

0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

左端の数字は優先度で、小さいものから順に評価されます。条件に一致したルールの指すテーブルで経路が見つかれば、そこで決まります。見つからなければ次のルールへ進みます。

local：自分自身のアドレスやブロードキャスト用の経路が入った特別なテーブル。通常は触らない
main：ip route show で見える普段のテーブル
default：通常は空

Policy Routing を設定している環境では、この間に次のような行が加わります。

100:    from 192.0.2.10 lookup 100
110:    fwmark 0x1 lookup vpn

1行目は「送信元が 192.0.2.10 ならテーブル 100 を使う」、2行目は「印 0x1 が付いたパケットは vpn という名前のテーブルを使う」という意味です。テーブルの名前と番号の対応は rt_tables ファイルに書かれています。ディストリビューションによって /etc/iproute2/rt_tables にあることも、/usr/share/iproute2/ 側に既定のファイルがあり /etc/iproute2/rt_tables.d/ などで追加する形のこともあるので、両方を見てください。

手順2：ルールが指すテーブルの中身を見る

ルールが正しくても、指す先のテーブルが空なら意味がありません。

# 番号や名前を指定して中身を見る
ip route show table 100
ip route show table vpn

# すべてのテーブルをまとめて見る（local も含むので量が多い）
ip route show table all

ip route show table 100 に default の経路が無いと、そのテーブルで経路が決まらず、次のルール（多くは main）に進みます。その結果、「ルールはあるのに普段の回線から出ていく」という状態になります。また、テーブル 100 に内側のネットワーク（例: 192.168.10.0/24）への経路が無いと、その送信元から社内への通信まで外の回線へ出てしまうことがあります。

手順3：実際にどう選ばれるかを問い合わせる（ip route get）

ルールとテーブルを目で追うより確かなのが、カーネルに直接問い合わせる方法です。

# 宛先だけを指定（通常の通信）
ip route get 8.8.8.8

# 送信元を指定して問い合わせる
ip route get 8.8.8.8 from 192.0.2.10

# 受信インターフェースを指定（転送される通信の場合）
ip route get 8.8.8.8 from 192.168.10.50 iif eth1

# fwmark を指定
ip route get 8.8.8.8 mark 0x1

結果には、使われるゲートウェイ（via）、出口のインターフェース（dev）、送信元アドレス（src）、そしてテーブル名（table）が表示されます。期待したテーブルと出口になっているかを確かめてください。from に自分のホストに付いていないアドレスを指定する場合は、iif も一緒に指定しないとエラーになることがあります。

実際の通信で確かめる

問い合わせの結果が正しくても、アプリの通信が本当にその経路を通るかは別に確認します。

# 送信元アドレスを指定して接続
curl --interface 192.0.2.10 -I https://example.com/

# 送信元を指定した traceroute
traceroute -n -s 192.0.2.10 8.8.8.8

# 出口のインターフェースで実際に出ていくかを見る
sudo tcpdump -ni eth1 host 8.8.8.8

手順4：fwmark を使うルールを追う

fwmark のルールは、パケットに印を付ける別の設定（iptables の mangle テーブルや nftables の meta mark set）とセットで動きます。印を付ける側が動いていないと、ルールがあっても何も起こりません。

# iptables で印を付けているルールとカウンター
sudo iptables -t mangle -L -n -v

# nftables で印を付けているルール
sudo nft list ruleset | grep -n mark

カウンターが増えていなければ、印付けの条件（ポート、インターフェース、チェーンの選択）が実際のパケットと合っていません。自分のホストから出る通信には OUTPUT、転送する通信には PREROUTING で印を付けるのが基本で、チェーンを間違えると印が付きません。

意図どおりに動かないときの主な原因

1. ルールの優先度の順番

優先度の小さいルールが先に一致すると、後ろのルールは評価されません。ip rule show の順番を見直し、広い条件のルールが前に来ていないかを確認します。

2. 逆経路フィルタ（rp_filter）で落ちている

回線を2本使う構成では、パケットが届いたインターフェースと、その送信元へ返す経路が食い違うと、カーネルの逆経路フィルタが厳格モードのときにパケットが捨てられます。

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

値が 1 なら厳格、2 なら緩やかなモードです。インターフェースごとの値と all の値のうち大きいほうが使われる点に注意してください。設定を緩める場合は、影響範囲を理解したうえで、対象のインターフェースに限って変えるのが無難です。

3. 再起動やネットワークの再起動でルールが消えた

ip rule add や ip route add ... table 100 で入れた設定は、再起動すると消えます。永続化は使っているネットワーク管理の仕組みで行います。

netplan（Ubuntu など）：インターフェースの設定に routing-policy（from、table、priority など）と、table を指定した routes を書く
NetworkManager（RHEL 系など）：接続ごとの ipv4.routing-rules と、テーブルを指定した ipv4.routes を設定する

設定の書式はバージョンで変わることがあるため、使っている版のドキュメントで確認してください（2026年10月現在）。リモートからネットワークの設定を変える場合は、変更前に ip rule show と ip route show table all の出力を保存し、コンソール接続など戻す手段を用意してから進めます。netplan なら sudo netplan try を使うと、確認しなかった場合に自動で元に戻ります。

4. VPN や管理ツールがルールを追加している

WireGuard の wg-quick などの VPN ツールや、コンテナの管理ツールは、自分で fwmark とルールを追加することがあります。覚えの無いルールがある場合は、どのツールが入れたものかを先に確かめ、手で消さないようにしてください。

Cisco の PBR を確認する

Cisco IOS の PBR は、インターフェースに適用した route-map で動きます。確認には次のコマンドを使います。

show ip policy
show route-map
show access-lists

show ip policy でどのインターフェースにどの route-map が適用されているか、show route-map で一致件数と set の内容、show access-lists で条件の ACL の一致件数を確かめます。PBR は受信側のインターフェースに適用するため、出口側に適用していないかも見てください。debug ip policy は詳しい情報が出ますが、負荷が高くなることがあるので、本番機では条件を絞って短時間だけ使うのが安全です。

まとめ

Policy Routing は「ルール → テーブル → 経路」の3段で確認する
Linux は ip rule show で優先度と条件、ip route show table で中身を見る
最終確認は ip route get に from・iif・mark を付けて問い合わせ、実際の通信も curl --interface や tcpdump で確かめる
動かないときは、優先度の順番、テーブルの経路不足、rp_filter、fwmark の付け忘れ、永続化漏れを疑う
Cisco は show ip policy、show route-map、show access-lists で適用先と一致件数を見る