Linux VRF によるマルチテナント L3 ルーティング分離｜設定と疎通検証・障害切り分けフロー

Linux VRF とは何か ― L3 仮想化の位置づけ

Linux VRF（Virtual Routing and Forwarding）は、カーネル 4.3 以降に標準組み込まれた L3 仮想化機能です。単一の Linux ホスト上に複数の独立したルーティングテーブルを持てるようにする仕組みで、テナントごとに経路情報を完全に切り離せます。

VLAN が L2（データリンク層）を分離するのに対し、VRF は L3（ネットワーク層）の分離を担います。複数テナントが重複する IP アドレス空間を持つマルチテナント構成、管理ネットワークとデータネットワークの明確な隔離、VPN 終端ルータのように「複数の独立した転送ドメイン」が求められる場面で特に有効です。

カーネル内部では、VRF は L3 マスターデバイスとして実装されています。スレーブとして紐付けられたインターフェースから受信したパケットは、そのマスターデバイスに対応するルーティングテーブル（rt_table）で処理されます。デフォルトのルーティングテーブル（table main）とは完全に独立しているため、VRF に属さないプロセスへの経路漏洩が起きません。

なお、VRF はあくまで L3 分離であり、L2 フレームレベルの分離には VLAN や VXLAN との組み合わせが必要です。また、ファイアウォールポリシーは VRF ごとに nftables / iptables で別途設定しなければ、アプリケーション層の分離は保証されません。

VRF デバイスの作成とインターフェース割り当て

以下の手順は iproute2 の ip コマンドを使います。Ubuntu 22.04 LTS / 24.04 LTS、あるいは RHEL 9 系（AlmaLinux 9 / Rocky Linux 9）を想定しており、カーネルは 5.15 以降を前提とします。

VRF デバイスの作成

各 VRF には固有のルーティングテーブル ID を割り当てます。table 番号は /etc/iproute2/rt_tables に存在しない値を選びます。1〜252 の範囲が実用的で、253〜255 はシステム予約です。

# テナント A 用 VRF（テーブル ID 10）
ip link add vrf-tenantA type vrf table 10
ip link set dev vrf-tenantA up

# テナント B 用 VRF（テーブル ID 20）
ip link add vrf-tenantB type vrf table 20
ip link set dev vrf-tenantB up

インターフェースの割り当てと IP アドレス設定

物理インターフェース、VLAN サブインターフェース、または VXLAN デバイスを VRF のスレーブとして紐付けます。インターフェースを VRF に割り当てると、それまでに設定されていた IP アドレスは削除されます。割り当てと IP アドレス設定は必ず以下の順序で行います。

# eth1 をテナント A の VRF に割り当て
ip link set dev eth1 master vrf-tenantA
ip addr add 192.168.10.1/24 dev eth1
ip link set dev eth1 up

# eth2 をテナント B の VRF に割り当て
ip link set dev eth2 master vrf-tenantB
ip addr add 192.168.20.1/24 dev eth2
ip link set dev eth2 up

TCP/UDP ソケットの l3mdev 対応

VRF を経由したソケット通信を正しく機能させるには、以下の sysctl パラメータを有効にします。このパラメータを設定しないと、VRF インターフェース経由で接続してきたクライアントへの応答が正しい VRF コンテキストで処理されず、非対称ルーティングが発生します。

sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1

恒久化するには /etc/sysctl.d/99-vrf.conf に記述して sysctl --system を実行します。

VRF 内のルーティング設定と疎通検証

スタティックルートの追加

VRF スコープでルートを追加するには vrf NAME オプションを付けます。

# テナント A の上流ルートを追加
ip route add 10.0.1.0/24 via 192.168.10.254 vrf vrf-tenantA
ip route add default via 192.168.10.254 vrf vrf-tenantA

# テナント B の上流ルートを追加
ip route add 10.0.2.0/24 via 192.168.20.254 vrf vrf-tenantB

VRF に割り当てられたインターフェースのリンクローカルルート（例: 192.168.10.0/24 dev eth1）は、割り当て時に自動的にその VRF のテーブルへ移動します。table main には残りません。ルーティングテーブルを確認するには次のコマンドを使います。

ip route show vrf vrf-tenantA
ip route show vrf vrf-tenantB

# テーブル ID で直接参照する場合
ip route show table 10
ip route show table 20

ip vrf exec による疎通確認

ip vrf exec コマンドを使うと、特定の VRF コンテキストでプロセスを実行できます。これにより、VRF に閉じた ping・traceroute・curl が可能です。

# テナント A のコンテキストで ping
ip vrf exec vrf-tenantA ping -c 3 10.0.1.1

# テナント B のコンテキストで traceroute
ip vrf exec vrf-tenantB traceroute 10.0.2.100

分離の確認（クロステナント疎通が起きないことを検証）

テナント A のコンテキストからテナント B のアドレス空間へ到達できないことを確認します。これらが応答を返す場合は、意図せずルートが漏洩している可能性があります。

# 到達不可であることを確認（ICMP unreachable または timeout になるはず）
ip vrf exec vrf-tenantA ping -c 2 -W 2 192.168.20.1
ip vrf exec vrf-tenantA ping -c 2 -W 2 10.0.2.1

応答がある場合は ip route show vrf vrf-tenantA でテナント B のアドレス帯が含まれていないかを確認します。また、ARP テーブルの状態は ip neigh show vrf vrf-tenantA で確認できます。ネクストホップのエントリが FAILED や INCOMPLETE であれば、パケットキャプチャに進みます。

障害切り分けフロー

ステップ 1 ― VRF デバイスとインターフェースの状態確認

# VRF デバイス一覧と状態確認
ip link show type vrf

# 特定 VRF のスレーブインターフェース確認
ip link show master vrf-tenantA

VRF デバイスが DOWN になっている場合は ip link set dev vrf-tenantA up で起動します。インターフェースが master に紐付いていない場合は、再度 ip link set dev eth1 master vrf-tenantA を実行します。

ステップ 2 ― ルーティングテーブルとポリシールールの確認

ip route show vrf vrf-tenantA

# ポリシールーティングルールの確認
ip rule show

ip rule show で VRF に対応する l3mdev ルールが存在するかを確認します。VRF を作成するとカーネルはこのルールを自動追加しますが、誤って削除されていると VRF ルーティングが機能しません。

ステップ 3 ― パケットキャプチャによる実通信の確認

# 送受信の両インターフェースで同時にキャプチャ
tcpdump -i eth1 -n icmp &
tcpdump -i eth2 -n icmp &

ip vrf exec vrf-tenantA ping -c 3 10.0.1.1

送信側で ICMP echo request がキャプチャされるのに応答がない場合は、対向機器側の問題か戻り経路のルーティング設定を見直します。送信側でそもそもパケットが出ていない場合は、ルーティングテーブルにそのプレフィックスが存在しないか、インターフェースが正しく UP していない可能性があります。

よくあるつまずき

• tcp_l3mdev_accept を設定し忘れる：VRF 経由の SSH や HTTP が接続を受け付けない原因として一般的に見られます。sysctl の確認から始めます。
• iptables / nftables のルールが VRF を考慮していない：デフォルトの FORWARD DROP ポリシーがある場合、VRF 経由のトラフィックも DROP されます。-i vrf-tenantA を指定したルールを追加するか、nftables で VRF ごとにチェーンを分けます。
• インターフェース割り当て前に IP アドレスを設定している：割り当て時に IP アドレスが削除されます。割り当て → IP 設定 → UP の順を守ります。
• 再起動後に設定が消える：ランタイムで設定した VRF は再起動後に消えます。永続化には次節の手順が必要です。

2026年時点の現行環境差分と永続化・切り戻し

systemd-networkd による永続化

2026年時点では、systemd-networkd が VRF を正式にサポートしており、.netdev と .network ファイルで永続設定できます。Ubuntu 24.04 LTS および RHEL 9 系での標準的な手順は以下のとおりです。

# /etc/systemd/network/10-vrf-tenantA.netdev
[NetDev]
Name=vrf-tenantA
Kind=vrf

[VRF]
Table=10

# /etc/systemd/network/20-eth1.network
[Match]
Name=eth1

[Network]
VRF=vrf-tenantA
Address=192.168.10.1/24

設定後は systemctl restart systemd-networkd を実行します。ファイル名の数字プレフィックスは読み込み順を制御するため、VRF の .netdev をインターフェースの .network より小さい番号にします。

NetworkManager による設定

RHEL 9 および Ubuntu 24.04 では NetworkManager も VRF をサポートしています。nmcli での設定例は以下のとおりです。

nmcli connection add type vrf ifname vrf-tenantA con-name vrf-tenantA table 10
nmcli connection add type ethernet ifname eth1 master vrf-tenantA con-name eth1-vrf \
  ipv4.method manual ipv4.addresses 192.168.10.1/24
nmcli connection up vrf-tenantA
nmcli connection up eth1-vrf

nftables との連携（カーネル 6.x 系）

カーネル 6.x 系では、nftables の meta iifname マッチで VRF デバイス名を指定することで、VRF スコープのフィルタリングが可能です。iptables（legacy）を使用している環境では、-i vrf-tenantA がスレーブインターフェースに対して正しく機能しない場合があるため、nftables への移行が推奨されています。

table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    meta iifname "vrf-tenantA" meta oifname "vrf-tenantA" accept
    meta iifname "vrf-tenantB" meta oifname "vrf-tenantB" accept
  }
}

切り戻し手順

設定を元に戻す場合は、スレーブの解除 → VRF デバイスの削除の順に行います。

# スレーブ解除（インターフェース自体は残る）
ip link set dev eth1 nomaster

# VRF デバイスの削除
ip link del vrf-tenantA

VRF デバイスを削除すると、そのテーブル（table 10）のルートエントリはすべて消去されます。スレーブから解除されたインターフェースはデフォルトの table main に戻ります。永続化設定（systemd-networkd または NetworkManager）を使用している場合は、設定ファイルの削除または無効化も合わせて行います。切り戻し後に ip rule show で不要な l3mdev ルールが残っていないかを確認しておくと安全です。