「あれ…？Linuxサーバーから、特定のネットワークにある別のサーバーに接続できない…」
「自社の別拠点にあるはずのプリンターやファイルサーバーに、ping が通らないんだけど！？」
「新しくネットワークセグメントを追加したら、そこだけ通信がおかしい…」
Linuxシステムを管理していて、ある日突然そんなネットワークトラブルに直面したことはありませんか？
IPアドレスやサブネットマスク、DNSの設定はちゃんと確認したはずなのに、なぜか特定の宛先にだけパケット（通信データ）が届かない…。 スマホで慌てて「linux ルーティング 確認」なんて検索して、このページにたどり着いてくれたんじゃないでしょうか。
わかります、わかります！私も全く同じ経験があります。 サービスが停止しちゃったり、原因がわからなくて「もしかして、ハードウェアが壊れた…？」「もう、ぜんぜん分からない…」って、もうパニックになっちゃいますよね😥
でも、大丈夫です！
その焦る気持ち、よーくわかります。でも、お手上げだと諦めるのは、絶対に待ってください！
これらの問題の多くは、Linuxカーネルが持っている「ルーティングテーブル（ネットワークの地図）」の設定ミスや、設定漏れが原因なんです。ハードウェアの故障であるケースは、意外と稀なんですよ。
この「地図」が正しく書かれていないと、パケットは宛先にたどり着くことができなくて、ネットワークのどこかで迷子になっちゃうんです…。
だから、ネットワークのトラブルシューティングにおいて、「linux ルーティング 確認」っていう作業は、ping とか ip addr でのIPアドレス確認の次にやるべき、すっごく重要なステップの一つなんですね。
でも、このルーティングテーブルって、どうやって確認して、どうやって設定すればいいんでしょう…？
古くから使われている route コマンドと、現代の標準である ip route コマンド。
どっちを使えばいいのか、どう違うのか、ちょっと混乱しちゃいますよね。
この記事は、そんなネットワークの「交通整理」に挑むことになったあなたを救うための、以下の内容をぜーんぶ網羅して、深く掘り下げて解説する「完全ガイド」です🗺️✨
- ルーティングテーブルの基本的な概念（デフォルトゲートウェイって何？）
- 従来（古い）の
routeコマンドを使った「linux ルーティング 確認」方法 - 現在（新しい）の
ip routeコマンドを使った詳細な「linux ルーティング 確認」方法 - 静的な経路情報を追加する
linux route add(およびip route add) の具体的な使い方 - 設定したルート情報を永続化する（再起動後も保持させる）ための、ディストリビューション別設定
ネットワーク管理の中でも、ちょっと高度な領域って言われるルーティングですけど、この記事を読めば、その仕組みと操作方法をバッチリ理解して、自信を持ってトラブルシューティングできるようになるはずですよ！
ルーティングテーブルとは何か？ネットワークの「地図」を理解する
まず、Linuxがどうやってパケット（通信データ）を「宛先」に届けているのか、その中心的な仕組みである「ルーティングテーブル」について、しっかり理解を深めていきましょう。
この概念をちゃんと理解することが、「linux ルーティング 確認」をやる上での、すべての基礎になるんです！
ルーティングの基本概念：パケットは「バケツリレー」
あなたが東京から大阪の友人に「手紙（＝パケット）」を送る場面を、ちょっと想像してみてください。
あなたは手紙を、自分で直接大阪まで届けるんじゃなくて、一番近くの郵便ポスト（または郵便局）に投函しますよね。
郵便局は、その手紙の宛先（大阪の住所）を見て、「あ、これは大阪方面だから、次は名古屋の中継局に送ろう」って判断します。
名古屋の中継局は、「大阪のこの住所なら、次は大阪中央郵便局だな」って判断して、最終的に友人の家の最寄りの配達局を経由して、手紙が届きます。
ネットワークにおけるルーティングも、これと全く同じ仕組みなんです。
Linuxサーバー（あなた）が、遠くのネットワーク（例えば：8.8.8.8 のGoogle DNSサーバー）にパケット（手紙）を送りたい時、サーバーは「んー、8.8.8.8 は自分のローカルネットワーク（自分の家）にはないな…」って判断します。
そこで、サーバーは「デフォルトゲートウェイ」（＝最寄りの郵便局、つまりルーターです）と呼ばれる機器に、そのパケットを「あとはよろしく！」って転送（フォワード）するんです。
受け取ったルーターは、パケットの宛先IPを見て、自分の持ってる「経路表」を参照して、「8.8.8.8 宛なら、次はプロバイダのルーターAに送ろう」って判断して、さらに転送します。
この「バケツリレー」がインターネット上で高速に繰り返されて、パケットは無事に宛先に到達するんですね。
ルーティングテーブルの役割：カーネルが持つ「経路表」
この「バケツリレー」を実現するために、Linuxカーネル（OSの中核部分）やルーターが内部に持っている「経路表」こそが、ルーティングテーブルなんです。
ルーティングテーブルは、すっごくシンプルなルールで構成された「対応表」だと思ってください。
「この宛先ネットワーク（Destination）に行くには、 この出口（Interface）から出て、 次はこの中継点（Gateway）にパケットを渡せば良い」
この情報が、リスト形式でずらっと保存されているんです。
私たちがこれからやろうとしている「linux ルーティング 確認」っていうのは、まさにこの「経路表」を人間が読める形で表示させて、内容が合ってるか細かくチェックする行為なんですよ。
デフォルトゲートウェイの重要性
ルーティングテーブルの中でも、いっちばん重要なエントリ（項目）が、「デフォルトゲートウェイ（Default Gateway）」です。
これは、ルーティングテーブルの「経路表」に、宛先への具体的な行き方が書かれていない（未知の宛先）場合に、「とりあえず、ここに送っておけば何とかしてくれるはず！」っていう、最後の砦となる中継点（ルーター）のアドレスを指します。
通常、インターネット（外部ネットワーク）への出口となる、お家のブロードバンドルーターとか、会社のメインルーターのアドレスが、このデフォルトゲートウェイとして設定されます。
「ping google.com は通る（インターネットには出られる）のに、ping 192.168.100.1 （別の社内ネットワーク）が通らない！」みたいな問題が起きた時…。
その原因は、ルーティングテーブルに「192.168.100.0/24 への経路」がちゃんと書かれてなくて、パケットが意図せずデフォルトゲートウェイ（インターネット側）に送られちゃって、捨てられている…っていうケースが、すっごく多いんですよ😫
静的ルーティング vs 動的ルーティング
ルーティングテーブルの情報をどうやって作るかには、大きく分けて2種類の方法があります。
1. 静的ルーティング (Static Routing)
これは、管理者が手動で、一つ一つの経路情報をぜんぶ設定する方法です。
この記事でこれから解説する linux route add や ip route add っていうのは、まさにこの静的ルーティングを設定するためのコマンドなんですね。
小規模なネットワークや、経路がガッチリ固定されている場合には向いてますけど、ネットワーク構成が変わるたびに、管理者が手動で修正しなきゃいけないのがちょっと大変です。
2. 動的ルーティング (Dynamic Routing) こっちは、ルーター同士が「OSPF」とか「BGP」みたいな専用のプロトコル（おしゃべりのルール）を使って、お互いに「私はここへの行き方知ってるよー」「そっちは？」みたいに、経路情報を自動で交換・学習しあって、ルーティングテーブルを自動的に構築・更新する方法です。 大規模なネットワークや、どこかで障害が起きた時に自動で迂回経路を見つけてほしい！っていう場合に、なくてはならない仕組みです。 Linuxでも「Quagga」や「FRR」といったソフトウェアを導入すれば、高機能なルーターとして（動的ルーティングで）動作させることが可能なんですよ。（これは、この記事の最後の応用編でちょっとだけ触れますね！）
【従来の方法】route コマンドによるルーティング確認と操作
まずは、古くからLinux（や多くのUNIX系OS）でずーっと使われてきた route コマンドを使った、「linux ルーティング 確認」の方法から見ていきましょう。
route コマンドとは？ (net-tools)
route コマンドっていうのは、ifconfig とか netstat みたいなコマンドたちと一緒に、「net-tools」っていうパッケージに含まれている、伝統的なネットワーク管理ツールの一つです。
RHEL/CentOS 7以降やUbuntu 18.04以降みたいな、現代のディストリビューションだと、実はもうデフォルトではインストールされていなくて、後で説明する iproute2 パッケージ（ip コマンド）の使用が推奨されてるんです。
でもでも、古いシステムとか、組み込み機器を触る時、あるいは昔からあるシェルスクリプトをメンテナンスする時なんかには、まだまだ route コマンドに遭遇する機会はゼロじゃありません。
それに、出力が後で出てくる ip route よりも一覧性が高くて、シンプルで見やすいので、ネットワークの概要をパッと素早く掴むために、あえてこっちを使うベテラン管理者さんもいたりするんですよ。
（もしターミナルで打ってみて command not found って言われちゃったら、sudo apt install net-tools や sudo dnf install net-tools でインストールが必要ですよ。）
route -n で「linux ルーティング 確認」を実行する
route コマンドでルーティングテーブルを確認する時の、もう絶対の「おまじない」は、-n オプションを付けることです。
-n オプションっていうのは、IPアドレスとかホスト名を「名前解決（DNS逆引き）」しようとしないで、ぜんぶ数値（IPアドレス）のまま表示してね、っていう意味のオプションなんです。
これを付けないと、名前解決が走っちゃって表示までにすっごく時間がかかったり、DNSが引けない環境だと余計なエラーが出たりするので、常に -n を付ける癖をつけちゃうことを、強く強くオススメします！
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
この出力結果の読み方が、ルーティング確認の第一歩です！ それぞれの列の意味は、こんな感じです。
- Destination (宛先): このネットワーク（またはホスト）宛のパケットですよ。
- Gateway (ゲートウェイ): 宛先に行くために、次にパケットを渡す中継点（ルーター）のアドレスです。
0.0.0.0になってる場合は、中継点が不要（＝同じネットワーク内に直接接続できる）ってことを意味します。 - Genmask (ネットマスク): 宛先ネットワークのサブネットマスクですね。
- Flags (フラグ): その経路がどんな「属性」を持ってるかを示します。これはすっごく重要ですよ！
- Metric (メトリック): 経路の優先度です。数値が小さいほど優先されます。（だいたい
0とか100とかが使われます） - Iface (インターフェース): パケットを送り出すための「出口」になるネットワークデバイス名（例:
eth0,ens33）です。
表1: route -n の主要なフラグ (Flags) の意味
route -n の出力で、いっちばん重要な「Flags」列の意味をまとめたものが、この表です。
表1: route -n の主要なフラグ (Flags) の意味
| フラグ | 意味 | 解説 |
|---|---|---|
| U | Up | この経路は有効（Up）ですよ、っていう意味です。必ず付く必須のフラグですね。 |
| G | Gateway | この経路は、特定のゲートウェイ（ルーター）を経由しますよ、っていう意味です。 |
| H | Host | 宛先（Destination）が、ネットワーク全体じゃなくて、特定のホスト（単一のIPアドレス）ですよ、ってことを示します。この時 Genmask は 255.255.255.255 になります。 |
| ! | Reject | この経路は拒否（Reject）ルールです。パケットは破棄されちゃいます。 |
| D | Dynamic | 動的ルーティング（ICMPリダイレクトとか）によって自動的に作られました。 |
| M | Modified | ルーティングデーモンとかによって変更されました。 |
さっきの出力例を、このフラグ表をもとにもう一度、よーく見てみましょう。
▼0.0.0.0 192.168.1.1 0.0.0.0 UG ... eth0
- →
Destinationが0.0.0.0（どのネットワークにも一致しない＝デフォルト）で、 - →
FlagsがUG（有効 かつ Gateway経由） - → これは、まさに「デフォルトゲートウェイ」の設定ですね！
宛先不明のパケットは、ぜんぶ
eth0から192.168.1.1に送られるんだな、ってことがわかります。
▼192.168.1.0 0.0.0.0 255.255.255.0 U ... eth0
- →
Destinationが192.168.1.0/24のネットワークで、 - →
FlagsがU（有効だけど、G が付いてない） - →
Gatewayが0.0.0.0 - → これは、「ローカルネットワーク」への経路です！
192.168.1.0/24宛のパケットは、ゲートウェイ（ルーター）なんかを経由しなくても、eth0から直接相手に届けられるんだな、ってことがわかります。
linux route add: 静的ルートを追加する方法
route コマンドを使って、手動で静的ルートを追加する（linux route add）場合の、基本的な構文はこんな感じです（もちろん root 権限が必要ですよ！）。
▼特定のネットワークへのルート追加:
route add -net [宛先ネットワーク] netmask [ネットマスク] gw [ゲートウェイIP] dev [インターフェース]
例: 10.0.0.0/8 ネットワーク宛のパケットを、192.168.1.254 (ルーター) 経由で eth0 から送る $ sudo route add -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.1.254 dev eth0
▼特定のホストへのルート追加:
route add -host [宛先IP] gw [ゲートウェイIP] dev [インターフェース]
例: 172.16.100.100 というホスト宛のパケットだけ、192.168.1.253 経由にする $ sudo route add -host 172.16.100.100 gw 192.168.1.253
▼デフォルトゲートウェイの追加:
route add default gw [ゲートウェイIP] dev [インターフェース]
例: デフォルトゲートウェイを 192.168.1.1 に設定する $ sudo route add default gw 192.168.1.1 dev eth0
route del: 静的ルートを削除する方法
追加したルートを削除したい時は route del です。
追加した時と、ほとんど同じ構文を使いますよ。
例: さっき追加した 10.0.0.0/8 へのルートを削除する $ sudo route del -net 10.0.0.0 netmask 255.0.0.0
【現在の標準】ip route コマンドによるルーティング確認と操作（最重要）
route コマンドはシンプルで分かりやすかったんですけど、機能的な限界もありました。
現代の複雑なネットワーク（例えば、複数のルーティングテーブルを持ったり、送信元のIPアドレスによって経路を変えたり）に対応するために、iproute2 パッケージに含まれる ip コマンド群っていうのが開発されたんです。
現在のLinuxネットワーク管理においては、この ip route コマンドを使うことが、もう強く強く推奨されています！
ip route コマンドとは？ (iproute2)
ip コマンドっていうのは、IPアドレス（ip addr）や、リンク状態（ip link）、そしてルーティング（ip route）みたいに、ネットワーク関連のあらゆる設定を、ぜーんぶ統合的に扱うための、すっごく強力なコマンドラインツールなんです。
net-tools (ifconfig とか route) が非推奨になっちゃった最大の理由は、この iproute2 が、それらの全機能をカバーした上で、さらにはるかに高機能だからなんですよ。
表2: route コマンド vs ip route コマンド比較
なんで ip route を使うべきなのか、従来の route コマンドと何が違うのかを、以下の表にまとめてみました。
表2: route コマンド vs ip route コマンド比較
| 項目 | route (net-tools) | ip route (iproute2) |
|---|---|---|
| 主な目的 | ルーティングテーブルの表示・操作 | ルーティング全般（ポリシー、ルール、テーブル）の表示・操作 |
| 開発状況 | 非推奨（メンテナンスのみ） | 標準・推奨（活発に開発中） |
| CIDR表記 | 非対応（netmask 255.255.255.0 のみ） | 対応（192.168.1.0/24） |
| 複数テーブル | 非対応（main テーブルのみ） | 対応（ip rule と連携し、複数のルーティングテーブルを扱える） |
| ポリシー | 非対応 | 対応（送信元IPやポート番号に基づいたルーティングポリシーを設定可能） |
| 構文 | 比較的シンプルだけど、オプションが煩雑 | 一貫性があり高機能だけど、多機能ゆえにちょっと複雑 |
| 推奨度 | 低（互換性のためにのみ使用） | 高（Linuxネットワーク管理の標準） |
ip route show で「linux ルーティング 確認」を実行する
ip route コマンドでルーティングテーブルを確認するには、show サブコマンドを使います。
（実は show は省略可能で、単に ip route とか、もっと短く ip r って打つだけでも同じ結果が得られちゃいますよ convenience）
$ ip route show default via 192.168.1.1 dev eth0 proto dhcp metric 100 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50 metric 100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
さっきの route -n の出力とは、かなり形式が違いますよね。
でも、こちらの方が、もっともっと詳細な情報を含んでるんです。
▼1行目: default via 192.168.1.1 dev eth0 proto dhcp metric 100
- →
default: 宛先が「デフォルト」（routeでの0.0.0.0）ですよ。 - →
via 192.168.1.1:192.168.1.1というゲートウェイ（via）を経由しますよ。 - →
dev eth0:eth0というインターフェースから送出されますよ。 - →
proto dhcp: この経路情報が「DHCP」プロトコルによって自動設定されたものですよ。（手動じゃないってことですね） - →
metric 100: メトリック値は100ですよ。
▼2行目: 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50 metric 100
- →
192.168.1.0/24: 宛先が192.168.1.0/24のネットワークです（CIDR表記になってて見やすい！）。 - →
dev eth0:eth0から送出されますよ。 - →
proto kernel: この経路がカーネルによって自動的に（eth0にIPが設定された時に）作成されたものですよ。 - →
scope link: この宛先は「リンクローカル」（＝同じネットワーク）の範囲にありますよ。（routeでのGateway 0.0.0.0と、だいたい同じ意味です） - →
src 192.168.1.50: この経路を使う時、推奨される送信元（Source）IPアドレスは192.168.1.50ですよ。（こんな詳細まで分かる！）
ip route get: 特定の宛先への経路を”計算”させる（超重要）
ip route show がルーティングテーブルの「ぜんぶのリスト」を表示するのに対して、この ip route get は、「特定の宛先IPアドレスに行くためには、どの経路が使われるか」をカーネルに”計算”させて、その結果だけを表示してくれる、もうめちゃくちゃ強力なトラブルシューティングツールなんです！
「linux ルーティング 確認」において、これ以上便利なコマンドは無いって、私は思ってます。
8.8.8.8 (Google DNS) への経路を調べる $ ip route get 8.8.8.8 8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.50 uid 0 cache
出力の意味:
「8.8.8.8 へのパケットは、192.168.1.1（デフォルトゲートウェイ）を経由（via）して、eth0 デバイスから、送信元IP 192.168.1.50 を使って送出されますよ」っていうことが、一発でわかります！
192.168.1.10 (ローカルIP) への経路を調べる $ ip route get 192.168.1.10 192.168.1.10 dev eth0 src 192.168.1.50 uid 0 cache
出力の意味:
「192.168.1.10 へのパケットは、ゲートウェイ（via ...）は不要で、eth0 デバイスから直接送出されますよ」ってことですね。
もし、ここで意図しないゲートウェイが表示されたり、あるいは「Network is unreachable」（＝経路が見つかりません）って表示されたりしたら、その瞬間、ルーティング設定が間違っていることが即座に確定するんです！
【実践】ip route add による静的ルートの追加と管理 (linux route add の現代版)
昔の route add コマンドの現代版が、この ip route add です。
もし「linux route add」っていうキーワードで検索して、この記事に来てくれた方も、これからはぜひ、こちらの ip route コマンドの方に慣れていくことを、強く強くオススメしますよ！
ip route add の基本構文
基本的な構文は、route コマンドよりも、むしろ直感的で分かりやすいんです（もちろん root 権限が必要ですよ）。
ip route add [宛先ネットワーク/CIDR] via [ゲートウェイIP] dev [インターフェース]
route add -net ... netmask ...みたいに、長々と書く代わりに、10.0.0.0/8のようにCIDR表記が使えます。これが本当に楽ちん！gwの代わりにvia（～経由で）っていう英単語を使います。こっちの方が意味が分かりやすいですよね。dev [インターフェース]は、カーネルが自動で判断できる場合は省略できちゃうこともありますけど、トラブルを避けるためにも、明示的に指定するのが確実ですよ。
実践的なシナリオ別 ip route add の例
▼シナリオ1: 別のローカルネットワーク (10.0.0.0/8) へのルートを追加する
（要件: 10.0.0.0/8 宛の通信は、192.168.1.254 にあるルーターを経由させたい）
$ sudo ip route add 10.0.0.0/8 via 192.168.1.254 dev eth0
どうです？ sudo route add -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.1.254 dev eth0 って書くよりも、はるかに短くて、スッキリしてますよね！
▼シナリオ2: 特定のホスト (8.8.8.8) へのルートを、別のゲートウェイ経由にする
（要件: サーバーにはデフォルトゲートウェイが2つあって、8.8.8.8 への通信だけは、192.168.1.2 っていう別のゲートウェイを使わせたい）
$ sudo ip route add 8.8.8.8/32 via 192.168.1.2 (ホスト単体の場合は /32 を付けますよ)
この後、ip route get 8.8.8.8 で確認してみると、デフォルトゲートウェイじゃなくて、今設定したこっちの経路が優先されるようになるはずです。
▼シナリオ3: デフォルトゲートウェイの追加・変更
デフォルトゲートウェイを追加 $ sudo ip route add default via 192.168.1.1 既存のデフォルトゲートウェイを変更 (replace を使うのがスマートです) $ sudo ip route replace default via 192.168.1.2
ip route del: 静的ルートを削除する方法
削除は del (delete) を使います。
追加した時と、もう全く同じ構文の add を del に変えるだけなので、カンタンですよね！
例: さっき追加した 10.0.0.0/8 へのルートを削除する $ sudo ip route del 10.0.0.0/8
静的ルートの永続化：再起動後も設定を保持する方法
⚠️警告：ここが一番の落とし穴です！⚠️
ちょっと待ってください！すっごく重要な注意点があります！
これまで解説してきた route add や ip route add コマンドで追加した静的ルートは、ぜんぶ「一時的」なものなんです。
Linuxサーバーを再起動しちゃうと、追加したルート設定は、ぜんぶキレイさっぱり消えてしまいます！
「あれ！？昨日設定したはずなのに、また繋がらない！」ってなっちゃうんです…（私も昔やりました…😭）
設定を「永続化」（再起動した後も、自動で読み込まれるように）するには、使っているディストリビューション（OSの種類）に応じた「設定ファイル」に、ルーティング情報をちゃんと書き込んであげる必要があるんです。
RHEL/CentOS系 (NetworkManager / ifcfg)
RHELやCentOS、Rocky Linuxなんかでは、NetworkManager っていう仕組みで管理するのが主流ですよね。
▼方法1: nmcli (NetworkManager CLI) を使う（推奨）
これが一番、現代的で推奨されてる方法です！
1. まず、対象の接続プロファイル名（設定名）を確認します $ nmcli connection show NAME UUID TYPE DEVICE eth0 a1b2c3d4-.... ethernet eth0 2. nmcli で静的ルートを追加 (例: 10.0.0.0/8 via 192.168.1.254) 「+」を付けることで、既存の設定に「追加」するっていう意味になります $ sudo nmcli connection modify eth0 +ipv4.routes "10.0.0.0/8 192.168.1.254" 3. 最後に、設定を反映させます $ sudo nmcli connection up eth0
nmcli で設定すると、ifcfg-eth0 ファイルに自動的に設定が書き込まれて、ちゃんと永続化までやってくれるんですよ！賢いですよね！
▼方法2: route-ethX ファイル（レガシー）
昔ながらの方法として、/etc/sysconfig/network-scripts/route-eth0 みたいなファイルを作って、そこに直接書き込む方法もあります。
/etc/sysconfig/network-scripts/route-eth0 ファイルを作成・編集 10.0.0.0/8 via 192.168.1.254 8.8.8.8/32 via 192.168.1.2
Debian/Ubuntu系 (/etc/network/interfaces)
DebianやUbuntu Serverで、Netplan や systemd-networkd を使ってなくて、昔ながらの /etc/network/interfaces ファイルでネットワーク管理をしている場合は、こんな風に書きます。
post-up（＝インターフェースが起動した後で）っていう指示を使って、ip route add コマンドを直接実行させちゃうのが、一般的なんですよ。
/etc/network/interfaces ファイルを編集 auto eth0 iface eth0 inet static address 192.168.1.50 netmask 255.255.255.0 gateway 192.168.1.1 # ... # ↓静的ルートをここに追記します post-up ip route add 10.0.0.0/8 via 192.168.1.254 post-up ip route add 8.8.8.8/32 via 192.168.1.2 # ↓削除（down時）も定義しておくと、とっても丁寧です pre-down ip route del 10.0.0.0/8 via 192.168.1.254 pre-down ip route del 8.8.8.8/32 via 192.168.1.2
systemd-networkd を使った方法 (最新)
Ubuntu Server 18.04以降の多くとか、Arch Linuxなんかで標準になってきた systemd-networkd を使っている場合は、/etc/systemd/network/ の下にある .network ファイルに、直接書き込むのが一番モダンな方法です。
/etc/systemd/network/10-eth0.network ファイルを編集 [Match] Name=eth0 [Network] Address=192.168.1.50/24 Gateway=192.168.1.1 [Route] セクションをまるごと追加します [Route] Destination=10.0.0.0/8 Gateway=192.168.1.254 [Route] Destination=8.8.8.8/32 Gateway=192.168.1.2
この方法だと、設定ファイルを見るだけで最終的な状態がわかる（＝宣言的って言います）ので、コマンドをずらずら並べる post-up 方式よりも、管理がしやすいって言われてるんですよ。
Linuxルーティングのトラブルシューティング実践ガイド
「linux ルーティング 確認」をやる時って、だいたいが何かしらのトラブルが起きてる時ですよね…！
ここでは、よくあるシナリオと、その解決ステップを紹介しますね。
ケース1: 「特定のホスト/ネットワークに疎通できない (pingが通らない)」
これが一番よくあるトラブルです。
▼ステップ1: ip route get [宛先IP] を実行する（最重要）
まずは、Linuxカーネルが、その宛先に対して「どの経路」を使おうとしているのかを、直接聞いちゃいましょう！
$ ip route get 10.0.0.50
分析1: “Network is unreachable” (ネットワークに到達できません) と表示された
- 原因: カーネルが
10.0.0.50への行き方を、もう全く知らない状態です…。ルーティングテーブルのどこにも一致しなくて、かつデフォルトゲートウェイも設定されていません！ - 対策:
ip route add default via ...でデフォルトゲートウェイを設定するか、ip route add 10.0.0.0/8 via ...で10.0.0.0/8ネットワークへの静的ルートを追加してあげてください。
分析2: 意図しないゲートウェイが表示された
- 原因:
ip route getの結果が、via 192.168.1.1（デフォルトゲートウェイ）になっちゃった！ でも、本当はvia 192.168.1.254（10.0.0.0/8用のルーター）を経由してほしかったのに…。 - 対策: ルーティングテーブルに、より具体的な経路（
10.0.0.0/8）が登録されてないんですね。ip route add 10.0.0.0/8 via 192.168.1.254を実行してあげましょう。 Linuxは、一番具体的な経路（＝プレフィックス長が一番長いもの）を優先してくれるので、default（0.0.0.0/0）よりも10.0.0.0/8の方が優先されるようになるんです。
▼ステップ2: traceroute [宛先IP] を実行する
ping が通らない時、traceroute (または mtr) を使うと、パケットが「どこまで」は届いていて、どこで捨てられちゃってる（* * * になっちゃう）のかを確認できます。
$ traceroute 10.0.0.50 traceroute to 10.0.0.50 (10.0.0.50), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 0.500 ms 0.450 ms 0.400 ms <-- あ！デフォルトゲートウェイに行っちゃった！ 2 * * * <-- ゲートウェイ 192.168.1.1 が 10.0.0.0/8 を知らなくて、ここで破棄されてる… ...
この結果から、「あぁ、10.0.0.0/8 への静的ルートが無くて、パケットが間違ってデフォルトゲートウェイに送られちゃってるんだな」っていう原因が、はっきり分かりますよね。
ケース2: 「複数のNICがあり、意図しないNICから通信してしまう」
Webサーバー用のネットワークと、管理用のネットワークみたいに、NIC（ネットワークカード）が2枚以上あるサーバーで、よーく発生する問題です。
原因:
eth0 (192.168.1.50) と eth1 (172.16.0.50) の両方にデフォルトゲートウェイが設定されちゃってて、意図しない方（通常はメトリック値が低い方）が使われちゃってるんです。
対策1: ip route show でメトリック値を確認する
default via ... metric 100 と default via ... metric 200 みたいに、複数のデフォルトゲートウェイがある場合、metric の数値が小さい方だけが有効になります。
使ってほしい方のNICのメトリック値が、ちゃんと低くなるように設定（またはDHCPの設定）を修正してあげましょう。
対策2: 送信元IPアドレスを明示する（src オプション）
ip route add する時に src オプションを付けると、その経路を使う時の送信元IPを固定できるんです。
これは、相手側（ファイアウォールとか）が送信元IPでフィルタリング（通信制限）してる場合に、すっごく有効ですよ。
10.0.0.0/8 へは、必ず 172.16.0.50 を送信元IPとして eth1 から出ていってね！ $ sudo ip route add 10.0.0.0/8 via 172.16.0.1 dev eth1 src 172.16.0.50
（応用編）Linuxルーティングのさらに高度な世界
（ここは、戦略的意図（高度な解説）を達成するための、ちょっとディープな応用編セクションです！🔥）
普通の 「linux ルーティング 確認」 や 「linux route add」 の記事では、あんまり踏み込まない、もっともっと高度なルーティングの世界を紹介しちゃいます。
これこそが、iproute2 (ip コマンド) の真価なんですよ！
ポリシーベースルーティング (Policy Based Routing)
普通のルーティングって、パケットの「宛先IPアドレス」だけを見て、どの経路を使うかを決めますよね。
でも、iproute2 を使うと、「送信元IPアドレス」とか「ポート番号」みたいに、もっと複雑な条件（＝ポリシー）に基づいて、使用するルーティングテーブル自体をガラッと切り替えることができるんです！
これを、ポリシーベースルーティング（PBR）って呼びます。
▼なぜこれが必要なの？
例えば、「社内ネットワークからの通信（192.168.1.0/24）はA回線（Gateway A）を使って、ゲストWi-Fi（192.168.100.0/24）からの通信はB回線（Gateway B）を使いたい！」みたいな、ちょっと（いや、かなり）複雑な要件を実現するためなんです。
▼ip rule コマンド：ルーティングポリシーデータベース
Linuxは、main テーブル（ip route show で見える、いつものテーブル）以外にも、複数のルーティングテーブルを持つことができるんです。
ip rule コマンドは、「どのパケットが、どのルーティングテーブルを参照しに行くか」っていう「ルール」を管理するためのコマンドなんですね。
$ ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default
↑これがデフォルト設定で、「全てのパケットは main テーブルを見なさーい」っていう意味になってます。
▼PBRの実践例：
（要件: サーバーのIPが 192.168.1.50 と 192.168.1.51 の2つあって、.51 から送信されたパケットだけ、別のゲートウェイ 192.168.1.254 を使わせたい）
1. 別のルーティングテーブル（名前を "VLAN10" とします）を作成 /etc/iproute2/rt_tables ファイルに追記 $ echo "100 VLAN10" | sudo tee -a /etc/iproute2/rt_tables 2. "VLAN10" テーブルに、専用のデフォルトゲートウェイを設定 $ sudo ip route add default via 192.168.1.254 dev eth0 table VLAN10 3. 「送信元IPが 192.168.1.51 なら、"VLAN10" テーブルを見ろ」というルールを追加 $ sudo ip rule add from 192.168.1.51 lookup VLAN10 4. ルーティングキャッシュをクリア $ sudo ip route flush cache
これで、ping -I 192.168.1.51 google.com みたいに送信元を指定して通信すると、192.168.1.254 が使われるようになるんです！すごいですよね！
動的ルーティングデーモン (FRR: Free Range Routing)
静的ルート（linux route add）を手動でポチポチ管理するのって、ネットワークが数台ならまだしも、数十台、数百台ってなると、もう破綻しちゃいますよね…。
そこで、Linuxサーバー自体を、CiscoとかJuniperみたいな、すっごく高価なルーターみたいに、動的ルーティングプロトコル（OSPF, BGPとか）をしゃべれるようにするソフトウェアがあるんです。
それが FRR (Free Range Routing) です（昔は Quagga っていう名前で有名でした）。
FRRをインストールして設定すると、Linuxサーバーは、お隣のルーターと経路情報を自動で交換しあって、ip route show で見える main テーブルを、ぜんぶ自動で更新してくれるようになるんです。
もし障害でどこかのルーターが止まっちゃっても、FRRがそれを検知して、自動的に迂回経路をルーティングテーブルに書き込んでくれます。
これはもう、linux route add による手動管理とは、全くレベルが違う、高度なネットワーク管理の世界なんですよ。
まとめ
この記事では、「linux ルーティング 確認」っていうキーワードを軸に、ネットワーク管理の心臓部であるルーティングテーブルの概念から、実践的な操作方法、さらにはちょっと高度な応用まで、徹底的に解説してきました！
最後に、すっごく大事なポイントをもう一度おさらいしますね。
✅ ルーティングテーブルは「ネットワークの地図」 パケットを宛先に届けるための「経路表」です。これが間違ってると、ネットワークトラブルの直接的な原因になっちゃいます。
✅ route vs ip route
- ・
route(net-tools) は古くて、非推奨です。CIDR表記とか、高度な機能に対応していません。 - ・
ip route(iproute2) が現在の標準です！ip route showで確認して、ip route get [宛先]で経路を計算させるのが基本中の基本です。
✅ トラブルシューティングの第一歩
- ・疎通できない宛先がいたら、まず
ip route get [宛先IP]を実行しましょう！ - ・「Network is unreachable」って言われるか、それとも「意図しないゲートウェイ（
via ...）」が表示されるかを確認することが、問題解決の9割を占めます。
✅ 静的ルートの追加 (linux route add)
- ・
route add -net ...よりも、ip route add [宛先/CIDR] via [GW]を使いましょうね。 - ・このコマンドで設定した内容は一時的で、再起動すると消えちゃいます！
✅ 設定の永続化が必須！
- ・RHEL/CentOS系なら
nmcli connection modify ... +ipv4.routes ... - ・Debian/Ubuntu系なら
/etc/network/interfacesへのpost-up記述 - ・
systemd-networkd環境なら.networkファイルの[Route]セクション - ・必ず、自分のサーバーの環境に合った方法で、設定をファイルに書き込んで、永続化してください！
✅ 応用の世界
- ・
ip ruleと複数のテーブルを使えば、送信元IPとかに基づいた、もっと賢いポリシーベースルーティングも可能ですよ。
ネットワークって複雑に見えちゃいますけど、その中心にある「ルーティング」っていう交通整理のルールをちゃんと理解すれば、もうトラブルも怖くありません。
「linux ルーティング 確認」をマスターして、安定したネットワーク運用を実現しちゃいましょう！💪✨
コメント