ルーティングテーブルを確認・編集する方法｜Linux と Windows の一時設定と永続化

ルーティングテーブルは「どの宛先へのパケットを、どの出口（ゲートウェイとインターフェース）から送るか」を決める表です。社内ネットワークや VPN の向こうに届かない、2枚目の NIC を使わせたい、といった場面では、この表を確認して経路を追加・変更します。この記事では、Linux の ip route と Windows の route / PowerShell で表を読む方法、一時的な追加と削除、再起動後も残る設定（netplan、NetworkManager、Windows の永続ルート）、そしてリモート作業で自分を締め出さないための注意点を説明します。

ルーティングテーブルの読み方

最長一致とメトリック

OS はパケットを送るたびに、宛先 IP に一致するエントリを表から探します。複数が一致した場合は、プレフィックスが長い（範囲が狭い）エントリが優先されます。例えば 10.20.5.8 宛てなら、10.0.0.0/8 より 10.20.0.0/16 が、それより 10.20.5.0/24 が優先です。

default（0.0.0.0/0）はどの宛先にも一致する最も短いエントリで、ほかに一致するものがないときに使われる最後の受け皿です。これがデフォルトゲートウェイです。

同じ長さのエントリが複数ある場合は、メトリック（値が小さいほど優先）で決まります。有線と無線を同時につないだ PC で、有線が優先されるのはこのメトリックの差によるものです。

Linux で確認する

現在の Linux では iproute2 の ip コマンドを使います。古い route -n や netstat -rn は net-tools パッケージのもので、入っていない環境が増えています。

# IPv4 のルーティングテーブル
ip route show

# IPv6
ip -6 route show

# 特定の宛先に実際にどの経路が使われるか
ip route get 10.20.5.8

出力例は次のとおりです。

default via 192.168.1.1 dev eth0 proto dhcp metric 100
10.20.0.0/16 via 192.168.1.254 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 metric 100

via が次に渡すルーター、dev が出口のインターフェースです。3行目のように via がない行は、そのネットワークに直接つながっていることを示します。

いちばん役に立つのは ip route get です。表を目で追うより、OS が実際に選ぶ経路をそのまま教えてくれるので、「想定した経路が使われていない」という問題をすぐ見つけられます。

Windows で確認する

rem IPv4 の表だけを表示
route print -4

# PowerShell
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

# 特定の宛先に使われる経路
Find-NetRoute -RemoteIPAddress 10.20.5.8

route print の「アクティブ ルート」が現在使われている表で、「固定ルート」（英語版では Persistent Routes）が再起動後も残るように登録された経路です。

経路を一時的に追加・変更・削除する

まずは再起動で消える一時的な設定で動作を確かめ、問題がなければ永続化する、という順番が安全です。

Linux

# 10.20.0.0/16 宛ては 192.168.1.254 経由にする
sudo ip route add 10.20.0.0/16 via 192.168.1.254 dev eth0

# 既存の経路を置き換える（なければ追加）
sudo ip route replace 10.20.0.0/16 via 192.168.1.253 dev eth0

# 削除
sudo ip route del 10.20.0.0/16

add は同じ宛先の経路がすでにあると「File exists」で失敗します。変更したいときは replace を使います。via に指定するゲートウェイは、自分と同じネットワーク上にある必要があります。直接届かないアドレスを指定するとエラーになるか、経路が有効になりません。

Windows

管理者として実行したコマンドプロンプトか PowerShell で操作します。

rem 一時的に追加（再起動で消える）
route add 10.20.0.0 mask 255.255.0.0 192.168.1.254

rem 削除
route delete 10.20.0.0

# PowerShell での追加（InterfaceIndex は Get-NetAdapter で確認）
New-NetRoute -DestinationPrefix "10.20.0.0/16" -InterfaceIndex 12 -NextHop 192.168.1.254

# 削除
Remove-NetRoute -DestinationPrefix "10.20.0.0/16" -Confirm:$false

PowerShell の New-NetRoute は既定で永続的な経路として登録されます。一時的にしたい場合は -PolicyStore ActiveStore を付けます。挙動は Windows のバージョンで細部が異なることがあるため、追加後は route print で「固定ルート」に載ったかどうかを確かめてください。

再起動後も残す（永続化）

Ubuntu（netplan）

Ubuntu Server などで使われる netplan では、/etc/netplan/ 配下の YAML に routes を書きます。ファイル名は環境ごとに異なるので、既存のファイルを確認してから編集してください。編集前にはコピーを取っておきます。

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1
        - to: 10.20.0.0/16
          via: 192.168.1.254
      nameservers:
        addresses: [192.168.1.1]

デフォルトゲートウェイを指定する gateway4 は古い書き方で、現在の netplan では非推奨とされ、上のように to: default で書く形が案内されています（2026年10月現在）。古い netplan では to: default を解釈できない場合があるので、エラーが出たらバージョンを確認してください。

反映には netplan try を使うのが安全です。設定を適用したあと、一定時間内に確認の Enter を押さないと元の設定に戻してくれるため、設定ミスで SSH が切れても自動で復旧します。

sudo cp /etc/netplan/50-cloud-init.yaml ~/50-cloud-init.yaml.bak  # ファイル名は環境に合わせる
sudo netplan try
# 問題なければ Enter。その後、必要なら
sudo netplan apply

クラウドのイメージでは、netplan の設定を cloud-init が生成・上書きすることがあります。その場合は cloud-init 側の設定を変えるか、別名の YAML ファイルを追加する方法を、利用しているイメージのドキュメントで確認してください。

RHEL 系・Fedora など（NetworkManager）

NetworkManager を使う環境では nmcli で接続プロファイルに経路を追加します。

# 接続名を確認
nmcli connection show

# 経路を追加（"宛先 ゲートウェイ" の形で書く）
sudo nmcli connection modify "eth0" +ipv4.routes "10.20.0.0/16 192.168.1.254"

# 反映（この接続が一瞬切れる点に注意）
sudo nmcli connection up "eth0"

# 削除するときは - を付ける
sudo nmcli connection modify "eth0" -ipv4.routes "10.20.0.0/16 192.168.1.254"

nmcli connection up はその接続を張り直すため、リモートから作業している接続そのものに対して実行すると、一時的に通信が途切れます。

Windows

route add に -p を付けると永続的な経路になります。

route -p add 10.20.0.0 mask 255.255.0.0 192.168.1.254

リモート作業で自分を締め出さないために

経路の変更でいちばん多い事故は、SSH やリモートデスクトップでつないでいる自分の通信経路を消してしまうことです。

• default や、自分の接続元を含む経路は特に慎重に扱う。変更前に ip route get 接続元のIP で、自分の通信がどの経路を通っているかを確かめます。
• 元に戻す手段を先に用意する。netplan なら netplan try を使います。それ以外では、VPS のシリアルコンソールやクラウドのコンソール接続など、ネットワークを通らずにログインできる手段を事前に確認しておきます。
• 本番の前に検証環境で試す。同じ OS・同じ構成の検証機で手順を通しておくと、設定ファイルの書式ミスを本番で踏まずに済みます。
• 変更前の表を保存する。ip route show > ~/route-before.txt のように残しておけば、何を変えたかを後から比べられます。

なお、AWS や GCP などのクラウドでは、OS のルーティングテーブルとは別に、VPC やサブネットにもルートテーブルがあります。OS 側の設定が正しくても、クラウド側のルートテーブルやセキュリティグループで止まっていれば通信できません。両方を確かめてください。

送信元によって経路を変えたい場合

ここまでの設定は「宛先」だけで経路を決めるものです。「この送信元 IP からの通信だけは別の回線へ出したい」といった要件には、Linux のポリシールーティング（ip rule と複数のルーティングテーブル）を使います。仕組みが一段複雑になるため、通常の経路追加で足りるかどうかを先に検討してください。

まとめ

• ルーティングテーブルは最長一致で経路を選び、同じ長さならメトリックの小さいほうが優先される
• Linux は ip route show と ip route get、Windows は route print -4 と Get-NetRoute / Find-NetRoute で確認する
• 一時的な追加・削除で動作を確かめてから、netplan、nmcli、route -p などで永続化する
• リモート作業では netplan try やコンソール接続など戻せる手段を先に用意し、変更前の表を保存しておく
• クラウドでは OS の外にある VPC のルートテーブルも確認する

• 静的IPアドレスを設定する方法
• サブネットとCIDRの計算方法