特定のサーバだけ外部ネットワークに出られない…Linux デフォルトルート消失の調査と復旧手順

「サーバを再起動したら、その1台だけ外部のサイトに接続できなくなった」という連絡が来た。
同じネットワークの他のサーバは問題なく外部と通信できている。
対象のサーバにログインしてみると、同じセグメント内の機器には ping が通る。
でもインターネット（8.8.8.8）への ping だけが通らない…。

再起動を境に発生した、というのが手がかりです。
原因はデフォルトルートの消失かもしれません。
今回は「特定のサーバだけ外部ネットワークに出られない」症状の仕組みと、ip route を起点とした調査・復旧の手順を実機ログとともに解説します。

1. 症状

まず前提として、登場するサーバは次の2台です。

この障害サーバ（10.0.10.11）から外部ネットワーク（インターネット上の 8.8.8.8）への ping が通りません。
（以降、インターネットや別セグメントなど自分のセグメント外を「外部」と呼びます）

$ ping -c 3 8.8.8.8
connect: ネットワークに届きません

注目したいのは、タイムアウトではなく即座にエラーが返る点です。
「届かない」のではなく「そもそも送り出す経路がない」とカーネルが判断して、送信前に失敗しています。

一方、同じセグメント内の機器への ping は通ります。

$ ping -c 3 10.0.10.12
64 bytes from 10.0.10.12: icmp_seq=1 ttl=64 time=0.893 ms
3 packets transmitted, 3 received, 0% packet loss

さらに、同じネットワークの他のサーバは外部に出られています。

[別の正常なサーバ] $ ping -c 3 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.00 ms
3 packets transmitted, 3 received, 0% packet loss

つまり症状を整理すると次のとおりです。

「このサーバだけ・外部だけ」が落ちている、という切り分けがすでにできています。

2. 原因の仕組み

この症状は、デフォルトルートの消失で説明できます。

Linux は通信相手の IP ごとに「どこへ送るか」をルーティングテーブルで決めます。
ルートには大きく2種類あります。

なお、デフォルトルートは「それ以外は全部ここへ送れ」という経路設定そのもので、その送り先（出口）の IP をデフォルトゲートウェイと呼びます。
ほぼ同義で使われますが、本記事では経路設定を指すときは「デフォルトルート」、送り先の IP を指すときは「ゲートウェイ」と呼び分けます。

同セグメント宛は connected route で直接届くため、デフォルトルートが無くても通信できます。
一方、外部（8.8.8.8 など別ネットワーク）への通信は、デフォルトルート＝ゲートウェイへの出口を通る必要があります。

対象サーバ（10.0.10.11）
   │
   ├─ 宛先 10.0.10.12（同セグメント）→ connected route で直接届く ◯
   │
   └─ 宛先 8.8.8.8（外部）→ デフォルトルートが必要
            │
       default なし → 「送る経路がない」= Network is unreachable ✕

これが「同セグメントは通るのに外部だけ落ちる」症状の正体です。
そして「他のサーバは正常」なので、ゲートウェイや上流ネットワークではなく、このサーバ固有の設定に原因が絞られます。

3. 調査手順

Step 1: ip route show でルーティングテーブルを確認する

まず、ルーティングテーブル全体を確認します。

$ ip route show
10.0.10.0/24 dev ens18 proto kernel scope link src 10.0.10.11 metric 100
192.168.30.0/24 dev ens19 proto kernel scope link src 192.168.30.11 metric 101

確認ポイントは1つ、先頭に default で始まる行があるかどうかです。
今回は default 行がありません。
残っているのは proto kernel scope link が付いた connected route（NIC に直結したセグメント）だけです。
これらは同セグメント宛にしか使えないため、それ以外の宛先（外部）には出られない状態です。

Step 2: ip route get で経路解決を確認する

ip route get <宛先IP> は、OS がその宛先に対して実際にどの経路を選ぶかを1発で表示します。
ip route show を目視で追うより速く確定できます。

$ ip route get 8.8.8.8
RTNETLINK answers: Network is unreachable

「Network is unreachable」= OS が 8.8.8.8 への経路を解決できないことを示しています。
デフォルトルートの消失が、これで確定します。

Step 3: 正常なサーバと設定を比較する

「他のサーバは正常」という情報があるときは、正常なサーバと設定を比べるのが原因特定の近道です。

[正常なサーバ] $ ip route show
default via 10.0.10.101 dev ens18
10.0.10.0/24 dev ens18 proto kernel scope link src 10.0.10.12 metric 100
192.168.30.0/24 dev ens19 proto kernel scope link src 192.168.30.12 metric 101

[正常なサーバ] $ ip route get 8.8.8.8
8.8.8.8 via 10.0.10.101 dev ens18 src 10.0.10.12

正常なサーバには default via 10.0.10.101（ゲートウェイへの出口）があり、8.8.8.8 が via 10.0.10.101 で解決されています。
障害サーバとの差が一目瞭然です。

Step 4: 消去法で「ルーティング設定」に絞り込む

念のため、物理層（L1/L2）とゲートウェイが正常であることを確認し、原因をルーティング設定に確定させます。

$ ip a
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> ... state UP
    inet 10.0.10.11/24 brd 10.0.10.255 scope global noprefixroute ens18

$ ip neigh
10.0.10.101 dev ens18 lladdr bc:24:11:44:aa:18 STALE
10.0.10.12 dev ens18 lladdr bc:24:11:87:56:2e STALE

$ ping -c 3 10.0.10.101
64 bytes from 10.0.10.101: icmp_seq=1 ttl=64 time=0.333 ms
3 packets transmitted, 3 received, 0% packet loss

確認できることは次のとおりです。

ip neigh は lladdr に MAC アドレスが表示されていれば OK です（ARP 解決できている＝L2 で相手を見つけられている）。
状態が STALE でも問題ありません。「しばらく通信していないので情報がやや古い」という意味で、MAC は分かっているため到達性に支障はありません。
逆に FAILED や MAC が表示されない場合は、L2 で相手に届いていない疑いがあります。

物理層からゲートウェイまですべて正常です。
残る原因は「このサーバのルーティング設定（デフォルトルートの消失）」だけ、と消去法で確定します。

4. 復旧手順

デフォルトルートを追加する

調査の結果、原因はデフォルトルートが永続設定に登録されていなかったことでした。
手動で ip route add したまま永続化されておらず、再起動でルーティングテーブルが初期化されてデフォルトルートが消えた——これが「再起動を境に外部へ出られなくなった」症状の正体です。
（※この「なぜ消えたか」は後述の永続設定の確認で裏付けます）

まずは応急処置として、デフォルトルートを手動で追加します。
ip route add default via <ゲートウェイIP> dev <デバイス名> で追加できます。
ゲートウェイの IP は、Step 3 で確認した正常サーバの default 行（または自分の環境のゲートウェイ）を使います。

$ ip route add default via 10.0.10.101 dev ens18

追加後、ルーティングテーブルと外部疎通を確認します。

$ ip route show
default via 10.0.10.101 dev ens18
10.0.10.0/24 dev ens18 proto kernel scope link src 10.0.10.11 metric 100
192.168.30.0/24 dev ens19 proto kernel scope link src 192.168.30.11 metric 101

$ ping -c 3 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.05 ms
3 packets transmitted, 3 received, 0% packet loss

default 行が戻り、外部疎通が回復しました。

ただし、これはランタイムの応急処置

ここで重要な注意点があります。
ip route add で追加したルートは、OS を再起動すると消えます（ランタイム＝一時的な変更のため）。
恒久対応には、NetworkManager の永続設定にゲートウェイを登録する必要があります。

永続設定の状態は nmcli で確認できます。

$ nmcli connection show ens18 | grep -i gateway
ipv4.gateway:                           --
IP4.GATEWAY:                            10.0.10.101

ここで見るべきは、小文字 ipv4.gateway と大文字 IP4.GATEWAY の差です。

設定ファイル（小文字）が空なのに、現在の実態（大文字）にはゲートウェイがある——これがまさに「ip route add で一時的に入れただけ」の状態です。
このまま再起動すると、空の設定ファイルが適用されて再びデフォルトルートが消えます。

恒久的に直すには、永続設定にゲートウェイを登録します。
nmcli connection modify で設定ファイルに書き込み、nmcli connection up で反映します。

ここからは設定値（小文字）と実態（大文字）がどう変化するかを順に見ていきます。
（分かりやすくするため、先ほど ip route add で入れた一時ルートは削除した状態から実演します。そのため IP4.GATEWAY も -- から始まります）

$ nmcli connection modify ens18 ipv4.gateway 10.0.10.101

登録すると、設定ファイル側（小文字 ipv4.gateway）に値が入ります。

$ nmcli connection show ens18 | grep -i 4.gateway
ipv4.gateway:                           10.0.10.101
IP4.GATEWAY:                            --

この時点では小文字（設定ファイル）にだけ値が入り、大文字 IP4.GATEWAY（実態）はまだ空です。
設定を実際の通信に反映するには up を実行します。

$ nmcli connection up ens18
接続が正常にアクティベートされました
$ nmcli connection show ens18 | grep -i 4.gateway
ipv4.gateway:                           10.0.10.101
IP4.GATEWAY:                            10.0.10.101

小文字（設定）と大文字（実態）が揃いました。
これで再起動してもデフォルトルートが維持され、再発を防げます。

5. Q&A

Q: ping のエラーにはいくつか種類がありますが、どう読み分ければいいですか？

A: 応答の速さとエラー表示で、原因の層が切り分けられます。

今回は「Network is unreachable」が即座に返ったため、送信前の段階＝ルーティングの問題と最初の一手で判断できました。

Q: なぜ同じセグメントへの通信は影響を受けないのですか？

A: 同一セグメント宛は connected route（直結ルート）で直接届くため、デフォルトルートを使わないからです。
デフォルトルートが必要なのは「自分のセグメント以外（外部）」への通信だけです。
これが「同セグメントは通るのに外部だけ落ちる」という症状になります。
管理用の別セグメントから SSH していれば、デフォルトルートが消えても接続が切れないのも同じ理由です。

Q: ip route add で直したのに、再起動したらまた繋がらなくなりました。なぜですか？

A: ip route add はランタイム（一時的）な変更なので、OS を再起動すると消えるためです。
恒久対応は NetworkManager の永続設定（nmcli connection modify ... ipv4.gateway）にゲートウェイを登録することです。
nmcli connection show の小文字 ipv4.gateway が空なら、永続設定にゲートウェイが入っていない＝再起動で再発する状態です。

Q: そもそもなぜデフォルトルートが消えるのですか？

A: 日常で圧倒的に多いのは、次の2つです。

• 永続設定にゲートウェイが入っていなかった … ip route add で手動投入したまま永続化を忘れ、再起動で消えて発覚する。今回のケースもこれ。
• 誰かが手動で消した … ip route del default の操作ミス、検証作業の後始末忘れなど。

この2つは「再起動を境に発生した」「直前に誰かが作業していた」といった手がかりで切り分けられます。

頻度は下がりますが、次のように永続設定があっても外的要因で書き換わるケースもあります。

• NIC 追加や VPN 接続時に経路が再構成された
• DHCP のリース更新に失敗し、IP・経路情報を取得できなかった

この場合は nmcli connection show の ipv4.gateway（永続設定）に値が残っているはずなので、Step 4 の永続設定確認で「設定はあるのに実態に反映されていない」という形で切り分けられます。

6. まとめ

「特定のサーバだけ外部に出られない」症状を見たら、まず ip route show と ip route get <外部IP> を確認する。
default 行が無い・「Network is unreachable」が返るなら、デフォルトルートの消失が原因です。
ip route add で応急復旧したあと、nmcli の永続設定まで直すのが再発防止の決め手です。

対応フロー

特定のサーバだけ外部に出られない
        │
        ▼
ip route show でルーティングテーブルを確認
  → default 行があるか？
        │
   無い ▼
ip route get <外部IP> で経路解決を確認
  → Network is unreachable なら消失確定
        │
        ▼
（任意）正常サーバと比較・L1/L2/GW を消去法で確認
        │
        ▼
ip route add default via <GW> dev <NIC> で応急復旧
        │
        ▼
nmcli connection show で永続設定（ipv4.gateway）を確認
        │
   ipv4.gateway が空？
        │
   YES  ▼
nmcli connection modify ... ipv4.gateway <GW> で恒久対応 → 再発防止