Ubuntu 26.04 Policy Based Routing の基本設定 – 複数インターフェイスの出口を分ける

Ubuntu 26.04 で複数 NIC、複数 VLAN、管理系とサービス系のネットワークを分ける場合、単純に default route を複数置くだけでは戻り経路が崩れることがあります。管理用 IP で受けた通信の応答が別の NIC から出たり、外部公開用 IP の通信が内部向けの経路に吸われたりすると、Firewall や対向機器からは不自然な通信に見えます。

そのような時に使う考え方が Policy Based Routing です。PBR は、宛先だけでなく送信元アドレスなどの条件に応じて routing table を選ぶ仕組みです。この記事では、Ubuntu 26.04 Server と Netplan を前提に、複数 NIC の出口を分ける基本を整理します。

default route を複数置くだけでは足りない

複数 NIC のサーバーでありがちな失敗は、それぞれの NIC に default route を置いてしまうことです。Linux は routing table と rule の優先度に従って経路を選ぶため、受信した interface と送信する interface が一致しないことがあります。

Policy Based Routing は、複数 default route を雑に並べるための機能ではありません。どの送信元アドレスの通信を、どの routing table で処理するかを明示するための仕組みです。

route と rule を分けて考える

通常の routing は、基本的に宛先アドレスを見て経路を選びます。一方、Policy Based Routing では、ip rule によって「この送信元ならこの table を見る」という条件を追加できます。

• routing table は経路の一覧を持ちます。
• ip rule はどの table を見るかを決めます。
• 送信元 IP ごとに異なる default route を選べます。
• Netplan では routes と routing-policy で表現します。

PBR を使う時は、table 番号と役割を管理しておくことが重要です。番号だけを散らばらせると、後から見た時に何の経路なのか分からなくなります。VLAN ID やネットワークの役割に合わせて table 番号を決めると、構成を読み返しやすくなります。

現在の経路と rule を確認する

まず現在の IP アドレス、routing table、policy rule を確認します。PBR を入れる前に、通常の default route と static route だけで済む構成なのかを見極めます。

ip address
ip route
ip -6 route
ip rule
ip route show table main

ip route get を使うと、特定の宛先へどの経路で出ようとしているかを確認できます。送信元を指定すると、PBR の確認にも使えます。

ip route get 8.8.8.8
ip route get 10.20.0.10 from 10.10.0.20

ここで期待しない interface が選ばれる場合は、単純な route では通信の主語を表現できていない可能性があります。送信元ごとに出口を分けたい場合は、PBR の出番です。

Netplan で routing table を分ける

次の例では、管理系の enp1s0 とサービス系の enp2s0 を分け、サービス系の送信元アドレスから出る通信は table 200 を使うようにします。

network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
        - 10.0.10.20/24
      routes:
        - to: default
          via: 10.0.10.1
      nameservers:
        addresses:
          - 10.0.10.53
    enp2s0:
      addresses:
        - 10.0.20.20/24
      routes:
        - to: default
          via: 10.0.20.1
          table: 200
      routing-policy:
        - from: 10.0.20.20/32
          table: 200

この例では、main table の default route は enp1s0 側に置き、enp2s0 の default route は table 200 に分けています。そして routing-policy で、送信元 10.0.20.20 の通信は table 200 を見るようにしています。

sudo tee /etc/netplan/00-main.yaml >/dev/null <<'EOF'
network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
        - 10.0.10.20/24
      routes:
        - to: default
          via: 10.0.10.1
      nameservers:
        addresses:
          - 10.0.10.53
    enp2s0:
      addresses:
        - 10.0.20.20/24
      routes:
        - to: default
          via: 10.0.20.1
          table: 200
      routing-policy:
        - from: 10.0.20.20/32
          table: 200
EOF
sudo chmod 600 /etc/netplan/00-main.yaml
sudo netplan generate
sudo netplan try

リモート作業では、管理用 SSH の戻り経路を壊さないことが重要です。netplan try を使い、切断時に戻せる状態を用意してから反映します。

VLAN interface で経路を分ける

VLAN を使う場合も考え方は同じです。送信元アドレスや VLAN interface の役割に応じて table を分けます。複数 VLAN で出口が異なる場合は、VLAN ごとに routing table を分けると意図が明確になります。

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
  vlans:
    enp1s0.100:
      id: 100
      link: enp1s0
      addresses:
        - 10.0.100.20/24
      routes:
        - to: default
          via: 10.0.100.1
          table: 100
      routing-policy:
        - from: 10.0.100.20/32
          table: 100
    enp1s0.200:
      id: 200
      link: enp1s0
      addresses:
        - 10.0.200.20/24
      routes:
        - to: default
          via: 10.0.200.1
          table: 200
      routing-policy:
        - from: 10.0.200.20/32
          table: 200

table 番号を VLAN ID と合わせると読みやすくなることがあります。ただし、番号の意味は環境内で一貫させます。設定ファイルを見た時に、table 100 が何を意味するのか分かる状態にしておくことが大切です。

反映後に確認する

反映後は、main table だけでなく、追加した table と rule を確認します。ip route get で送信元ごとの経路を確認すると、意図した table が使われているかを見やすくなります。

sudo netplan apply
ip address
ip rule
ip route show table main
ip route show table 100
ip route show table 200
ip route get 8.8.8.8 from 10.0.20.20
networkctl status enp2s0
journalctl -u systemd-networkd.service -n 100 --no-pager

ip rule に想定した from 条件が出ているか、追加 table に default route が入っているか、ip route get の結果が想定した interface になっているかを確認します。

Firewall / NAT / サービス待ち受けとの関係

PBR は routing の話ですが、実運用では Firewall、NAT、サービスの待ち受けアドレスと合わせて確認します。経路だけ正しくても、Firewall が拒否していたり、サービスが別の IP でしか待ち受けていなければ通信できません。

• サービスがどの IP アドレスで待ち受けているか
• Firewall が対象 interface / source / destination を許可しているか
• NAT を使う場合、出入口と変換後アドレスが一致しているか
• 戻り経路が想定した interface へ向いているか
• 外部監視や health check の送信元がどの経路を使うか

複数 NIC の障害切り分けでは、「IP で到達できるか」「名前で到達できるか」「戻り経路が同じか」「Firewall で落ちていないか」を分けて確認します。PBR はその中の routing 部分を明示するための設定です。

PBR を使う境界を決める

PBR は便利ですが、構成を複雑にします。単一の default route と static route で十分な場合は、PBR を入れない方が運用しやすいこともあります。

• 単一 NIC で十分な構成では PBR は不要です。
• 片方の NIC が閉域向けで default route を持たない構成では static route で済むことがあります。
• 宛先ごとの static route だけで整理できるなら、まずそちらを検討します。
• 運用者が table と rule の意味を追えない構成は避けます。

経路制御は、できるだけ単純な構成から考えるべきです。PBR は、通常の routing では戻り経路や送信元ごとの制御が表現しにくい時に使う選択肢です。

まとめ

Ubuntu 26.04 の Policy Based Routing は、複数 NIC や複数 VLAN の戻り経路を明示するための仕組みです。単純に default route を複数置くのではなく、送信元アドレスごとに routing table を分けることで、どの通信がどの経路を使うのかを制御できます。

ただし、PBR は構成を複雑にします。まず通常の route で済むかを確認し、それでも送信元ごとの経路制御が必要な場合に、routes と routing-policy を使って明示します。重要なのは、経路の主語を曖昧にしないことです。

関連記事

Ubuntu 26.04 FRR routing の基本設定 – OSPF / BGP を使う前に決めること Ubuntu 26.04 Reverse Path Filtering の基本設定 – 複数インターフェイスと PBR で rp_filter を確認する Ubuntu 26.04 VLAN の基本設定 – Netplan で tagged VLAN を扱う Ubuntu 26.04 Bonding の基本設定 – active-backup と 802.3ad を使い分ける Ubuntu 26.04 Netplan の基本設定 – IP アドレス / DNS / ルーティングを管理する Ubuntu 26.04 nftables の基本設定 – OS firewall の責務と通信制御 Ubuntu 26.04 Bridge の基本設定 – KVM 向け br0 を Netplan で作る Ubuntu 26.04 複数インターフェイスの基本設定 – 役割と経路を分ける