Red Hat ENETUNREACH (101) 対策: “Network is unreachable” エラー発生時のルーティング再設定と接続対策編

　

pingが通らないのにNICは正常…ENETUNREACHが示す“経路不在”という現実

※繰り返しになりますが、本記事はあくまで一般的な情報提供です。具体的な案件・契約・システム構成に関わる判断は、必ず株式会社情報工学研究所、弁護士や専門家に相談してから行ってください。

---

Red Hat 系 Linux で作業していると、アプリケーション側から「ENETUNREACH (101) – Network is unreachable」というエラーが返ってくる場面があります。ping がまったく返ってこない、しかし ip a や nmcli device status を見るとインターフェースは UP、リンクもキャリアあり、という状況です。プログラマー視点では「ソケットを開いて send しただけなのに、なぜ OS からネットワーク不可と言われるのか？」という素朴な疑問が湧きます。

ENETUNREACH は、カーネルが「この宛先ネットワークに到達するための経路（ルート）を決定できない」状態を表すエラーです。物理 NIC のリンクアップ／ダウンとは別レイヤーの話であり、L3 の経路情報が不足しているか、矛盾しているときに返されます。したがって、ケーブルが刺さっていてリンク LED が点灯していても、ルーティングテーブルが適切に構成されていなければ、ENETUNREACH が返ってくることは十分あり得ます。

典型的なパターンとして、次のようなものがあります。

• デフォルトゲートウェイが設定されていない、または誤ったアドレスになっている
• 複数 NIC 構成で、意図しないインターフェース側にデフォルトルートが張られている
• サブネットマスクの誤りにより、同一セグメントとみなすべき宛先を「ルート不在」と誤認している
• NetworkManager / ifcfg 設定と ip route の実際の状態が食い違っており、再起動や reload でルートが消えてしまう

プログラマーはアプリケーション側の例外処理に意識が向きがちですが、ENETUNREACH はアプリケーションコードそのものの問題ではなく、OS が持つルーティング情報の問題です。とはいえ、このエラーがどういう前提で返されるのかを理解しておくと、ログを読んだときに「これはアプリのリトライでは解決しない」「運用チームにルーティングを見直してもらうべきだ」といった切り分けが、コードレベルで自然にできるようになります。

混同しやすいのは、同じく到達不可系のエラーである EHOSTUNREACH や ECONNREFUSED などとの違いです。簡単に整理すると次のようになります。

エラー名	errno	典型的な意味
ENETUNREACH	101	宛先ネットワークへのルートが存在しない（ネットワーク単位の到達不可）
EHOSTUNREACH	113	ネットワークには到達できるが、その中のホストに到達できない
ECONNREFUSED	111	相手ホストには届いたが、目的ポートでサービスがリスンしていない

このように、ENETUNREACH はかなり早い段階（ルート解決の時点）で出てくるエラーです。逆に言うと、ENETUNREACH がレポートされている時点で、ARP や TCP ハンドシェイク以前の問題である可能性が高い、と判断できます。

本記事では、まず ENETUNREACH がどのような内部処理の結果として返されるのかをプログラマー向けに整理し、そのうえで Red Hat 系ディストリビューションでのルーティング再設定と接続対策の実務的な手順に落とし込んでいきます。最終的には、単発のトラブルシュートだけでなく、「設計」「監視」「手順書」のレベルで ENETUNREACH を減らしていくための考え方までを扱います。

なお、ここで説明する内容は一般論に基づいた整理であり、実際のシステム環境では、ファイアウォールポリシー、マルチパス、SD-WAN、クラウド環境固有のルーティングなど、追加の要素が絡みます。こうした複雑な構成では、株式会社情報工学研究所のような専門家による個別検証が不可欠になる点についても、終盤で改めて触れていきます。

　

ソケットエラー101の正体をコードから読み解く――カーネルが何を見ているか

プログラマーが ENETUNREACH を正しく扱うには、「どのタイミングで」「どの条件を満たしたときに」この errno がセットされるのかを押さえておく必要があります。ユーザー空間から見ると、connect() や sendto() を呼んだ結果として -1 が返り、errno == ENETUNREACH になるだけですが、その裏側では、カーネルがルーティングテーブルやネイバキャッシュを参照し、条件分岐を経てエラーを選択しています。

Linux カーネルでは、ソケット API の多くは共通のネットワークスタックを経由し、宛先 IP アドレスに対して「どのインターフェースから、どのネクストホップに送るか」を決定するためにルート検索を行います。具体的な実装はカーネルバージョンやプロトコルによって異なりますが、概念的には次のような流れになります。

1. アプリケーションから渡された宛先アドレス・ポートに基づき、プロトコルコントロールブロック（TCP/UDP）を初期化する
2. FIB（Forwarding Information Base）に対してルートルックアップを行い、最長一致する経路を探索する
3. 適切な経路エントリが見つかれば、その経路に紐づく出力インターフェースとネクストホップを決定する
4. 経路が見つからない場合、もしくは「このネットワークは利用不可」であることを示すエントリがある場合に ENETUNREACH が選択される

ここで重要なのは、ENETUNREACH が「ルート検索の結果」として決定されるという点です。つまり、アプリケーションコードがどれだけ正しくソケット API を呼んでいても、FIB に適切な情報がなければ ENETUNREACH は避けられません。逆に言えば、ENETUNREACH が返るということは、「アプリケーション側に問題があるというより、ネットワーク構成情報にギャップがある」と解釈すべきサインになります。

また、宛先が IPv4 か IPv6 かによっても、ルーティングテーブルやデフォルトルートの扱いが変わります。たとえば、IPv4 のデフォルトルート (0.0.0.0/0) は設定済みでも、IPv6 のデフォルトルート (::/0) が存在しない場合、IPv6 宛ての接続だけ ENETUNREACH になる、といった状況が起こり得ます。プログラマー側で AF_INET と AF_INET6 を明示的に使い分けている場合は、どのアドレスファミリでエラーが発生しているかにも注意する必要があります。

アプリケーションから見ると、「同じホスト上で動いている別プロセスは問題なく接続できるのに、このプロセスだけ ENETUNREACH になる」といった挙動を示すことがあります。これは、ソケットごとにバインドされるローカルアドレスやネットワーク名前解決の結果が異なることが原因の一つです。たとえば、

• bind() で特定のローカル IP アドレスにバインドしている
• 指定したローカルアドレスに対応するインターフェースには適切なルートがない
• 別プロセスは INADDR_ANY でバインドしており、別のインターフェース経由で接続できている

といったケースでは、アプリケーション側のローカルアドレス指定が、結果として ENETUNREACH を誘発することになります。

プログラマーがログ設計を行う際には、単に「errno=101」とだけ記録するのではなく、少なくとも以下の情報をセットで残しておくと、後続のネットワークエンジニアが原因分析しやすくなります。

• そのときに使用していたローカル IP / ポート（getsockname() の結果）
• 宛先 IP / ポート
• アドレスファミリ（IPv4 / IPv6）
• 名前解決の結果（どの A / AAAA レコードを採用したか）

こうした情報が残っていれば、「このホスト全体でルーティングがおかしいのか」「特定のインターフェースだけが問題なのか」「アプリケーション固有のバインド指定が原因なのか」を切り分けやすくなります。本記事の後半では、これらのログをもとに、実際に ip route get などを併用して原因を追う流れをタイムライン形式で整理します。

　

ip route showで見る“今この瞬間の経路表”とデフォルトゲートウェイの落とし穴

ENETUNREACH を目にしたとき、最初に確認すべき情報のひとつが、ip route show の結果です。Red Hat 系ディストリビューションでは、NetworkManager や ifcfg 設定、あるいは systemd-networkd などがルーティングを管理していても、最終的にカーネルが参照するのは ip route show に反映されている FIB の状態です。つまり、「OS が今この瞬間どのように経路を認識しているか」は、ip コマンドで確認するのが最も確実です。

最低限押さえておきたいのは、次の 3 つです。

• default 行が存在するかどうか（デフォルトルートの有無）
• ローカルセグメント（例：192.168.10.0/24）のネットワークルートが正しいか
• 複数の default 行や重複するネットワークルートがないか

たとえば、次のような出力が得られたとします。

default via 192.168.10.1 dev eth0 proto static metric 100 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20 metric 100 

この場合、192.168.10.0/24 宛てのトラフィックは直接 eth0 から出ていき、それ以外のネットワーク（インターネットなど）宛てのトラフィックは、192.168.10.1 をネクストホップとするデフォルトルート経由で転送されます。もし ENETUNREACH が発生しているのがインターネット宛ての通信であれば、デフォルトルートが消えていないか、あるいは誤ったインターフェース側に設定されていないかを疑うべきです。

一方、マルチホーム（複数 NIC）環境では、状況がもう少し複雑になります。

default via 10.0.0.1 dev eth1 proto static metric 100 default via 192.168.10.1 dev eth0 proto static metric 200 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.20 metric 100 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20 metric 100 

このように複数のデフォルトルートが存在する場合、カーネルはメトリックや優先度に基づいて使用する経路を選択します。意図していない側の回線（例：バックアップ回線）に低メトリックが設定されていると、障害時に期待しない経路で通信しようとして ENETUNREACH を引き起こすことがあります。

デフォルトルートの消失もよくある落とし穴です。たとえば、次のような操作の組み合わせで問題が起こることがあります。

• NetworkManager で一時的に接続プロファイルを変更し、別セグメントに切り替える
• 作業後に元の接続に戻したが、デフォルトルートだけが復元されていない
• 再起動・再接続のタイミングで、ifcfg ファイルと実際の状態が不整合を起こす

このような場合、ip route show を確認すると default 行そのものが存在せず、インターネット宛てのトラフィックについて FIB から「ルートが見つからない」と判断され ENETUNREACH が返されます。

より詳細な切り分けには、特定の宛先に対してカーネルがどのルートを選択するかを確認できる ip route get が有効です。

ip route get 8.8.8.8 

これにより、宛先 8.8.8.8 に対して、どのインターフェース・どのネクストホップを経由するつもりなのか、あるいは「RTNETLINK answers: Network is unreachable」というメッセージが表示されるのかを確認できます。アプリケーションログに残っている宛先 IP をもとに ip route get を実行することで、ENETUNREACH の再現性が高まります。

第 3 章では、こうした ip コマンドによる状態確認を土台に、次章以降で取り上げる「複数 NIC・複数セグメント環境」「NetworkManager 設定」「firewalld」「systemd-networkd」のそれぞれが、最終的にどのようにルーティングテーブルへ影響するのかを整理するための基盤を作りました。次の章では、特にトラブルが起こりやすい複数 NIC 構成に焦点を当て、メトリックと優先経路の考え方をプログラマーにもわかりやすい形で解説します。

　

複数NIC・複数セグメント環境での優先経路とメトリック設計を整理する

Red Hat 系 Linux の運用現場では、物理・仮想を問わず複数 NIC・複数セグメント構成は珍しくありません。社内 LAN とバックアップ回線、監視専用ネットワークとアプリケーション用ネットワークなど、役割ごとにセグメントを分離するのは一般的な設計です。しかし、このような構成では、どのインターフェースを「優先経路」として扱うか、どの回線を「障害時のバックアップ」にするかを明示的に設計しないと、思わぬタイミングで ENETUNREACH を含む到達不可エラーが発生します。

Linux カーネルは、ルーティングテーブル内のエントリをメトリック（metric）やプレフィックス長で評価し、最も「好ましい」経路を選択します。プレフィックス長が同じ場合、メトリックの小さい方が優先されます。例えば、次のような状態を考えます。

default via 10.0.0.1 dev eth1 proto static metric 50 default via 192.168.10.1 dev eth0 proto static metric 100 

この場合、インターネット宛ての通信は、原則として eth1 側の 10.0.0.1 経由で送信されます。意図としては「eth1=主回線、eth0=予備回線」であれば問題ありませんが、設定者がメトリックの意味を意識しておらず、デフォルト値のまま複数のデフォルトルートを追加した結果、優先経路が想定と逆になっていることがあります。

マルチホーム構成では、次の観点で整理しておくと混乱が減ります。

• 用途ごとに「このセグメントは何のためのネットワークか」を明文化する
• 用途ごとに「通常時の優先度」と「障害時の切り替え条件」を決める
• その方針に合わせてメトリックやポリシールーティングのルールを設計する

特に、アプリケーションサーバーが監視サーバーやバックアップサーバーと異なるネットワーク設計ポリシーを持っている場合、「監視は専用 NIC 経由、業務トラフィックは別 NIC 経由」といった粒度で経路を分ける必要があります。これを曖昧にしたまま複数のデフォルトルートを設定すると、特定の宛先に対してだけ ENETUNREACH が発生したり、障害時に期待と異なる経路を通ってトラフィックが外に出ていったりします。

---

また、複数 NIC 環境では、送信元 IP アドレス（src）も重要です。同じホストでも、eth0 から出る場合と eth1 から出る場合で送信元 IP が異なり、相手側のファイアウォールやセキュリティグループによって許可される・されないが分かれることがあります。Linux のルーティングでは、ルートエントリに src が明示されていない場合でも、インターフェースに割り当てられたアドレスや逆引きルールをもとに送信元 IP を決定します。この決定過程が設計者の想定とずれていると、「あるセグメントからは疎通するが、別セグメント経由では ENETUNREACH になる」といった状態が発生します。

こうした問題を防ぐためには、単に「IP を振る」「デフォルトゲートウェイを設定する」だけでなく、「このホストがどの宛先に対して、どの NIC・どの送信元 IP を使うべきか」を図示し、それに沿ってメトリックや静的ルート、場合によってはポリシールーティング（ip rule）を設計することが重要です。次章では、それらの設計を OS の設定ファイルにどのように落とし込むか、特に NetworkManager を利用した場合の一時的なテストルートと恒久設定の違いに焦点を当てます。

　

一時的なテストルートと恒久設定――nmcliとNetworkManagerでの正しい書き方

ENETUNREACH を解消するために現場でよく行われる操作が、「とりあえず ip route add でテストルートを追加する」ことです。問題の切り分けのために一時的なルートを追加すること自体は有効ですが、そのまま恒久設定を行わずに運用を続けると、再起動や NetworkManager の再読み込みでルートが失われ、再び ENETUNREACH が発生します。

Red Hat 系ディストリビューションでは、NetworkManager が標準のネットワーク管理デーモンとして利用されていることが多く、systemd 起動時には NetworkManager が接続プロファイルに基づいてインターフェースとルートを再構成します。このとき、手動で追加したルート（ip route add のみで登録したもの）は、NetworkManager の管理外であるため、再起動後に再現されません。

一時的なテストと恒久設定をきちんと分けるためには、次のような運用が有効です。

• 原因切り分けのためのテストでは ip route add を使ってもよいが、問題解決の段階では必ず設定ファイルか nmcli で恒久設定を残す
• NetworkManager 管理下のインターフェースでは、基本的に nmcli connection modify を通じてルートを追加する
• 手作業で ifcfg ファイルを書き換える場合は、設定反映手順（connection down/up など）を標準化する

---

例えば、特定の宛先 10.20.30.0/24 を eth1 経由のルートで追加したい場合、nmcli では次のような操作が典型例です（実際のコマンドは環境に合わせて調整が必要です）。

nmcli connection modify <connection-name> \ +ipv4.routes "10.20.30.0/24 10.0.0.1" nmcli connection up <connection-name> 

これにより、当該接続プロファイルの設定として静的ルートが保存され、NetworkManager の再起動やホスト再起動後も同じルートが再現されます。ifcfg スタイルの設定ファイル（例：/etc/sysconfig/network-scripts/ifcfg-eth0）を使用している環境では、IPV4_ROUTE_* などの形式でルートを記述しますが、現在の Red Hat 系では NetworkManager のキーファイル形式や nmcli での管理が推奨されています。

テスト目的で ip route add を使った場合は、必ず作業記録に「一時ルート」と明記し、恒久対応として「NetworkManager 設定への反映」「設定反映の確認」「再起動後の疎通確認」までを一連の作業とするべきです。これを怠ると、数週間後や OS アップデート後に ENETUNREACH が再発し、「以前はつながっていたのに、いつからかつながらなくなった」という曖昧な障害として再燃します。

次章では、ルーティングとよく混同される firewalld の設定について、「どこまでが経路の問題で、どこからがフィルタの問題か」を整理し、ENETUNREACH とその他の到達不可エラーを切り分ける観点をまとめます。

　

firewalldとルーティングの境界――フィルタなのか経路なのかを切り分ける

ネットワーク障害の現場では、「ファイアウォールが原因か、ルーティングが原因か」がしばしば混同されます。Red Hat 系では、ホストファイアウォールとして firewalld（iptables/nftables のラッパ）が利用されることが多く、さらにその外側に物理ファイアウォールやクラウドのセキュリティグループが存在することもあります。このとき、ENETUNREACH のようなルーティング由来のエラーと、フィルタリング由来のパケットドロップを区別して考えることが重要です。

一般的に、ENETUNREACH はルートルックアップの結果として返されるエラーであり、firewalld のルールが原因で直接 ENETUNREACH になることは通常ありません。firewalld によるパケットドロップは、トラフィックがルーティングを通過した後、フィルタチェイン上で DROP/REJECT されるものです。その結果としては、通信タイムアウトや ICMP エラーメッセージ（host unreachable など）として観測されることがありますが、アプリケーション側の errno として ENETUNREACH が返るかどうかは別の問題です。

障害切り分けの際には、次のようなステップで「経路かフィルタか」を判定すると整理しやすくなります。

• ip route get 宛先IP が「Network is unreachable」と返るかどうかを確認する（返るなら経路問題が濃厚）
• ローカルホストからの ping ではなく、同一セグメント上の別ホストからの ping の結果を比較する
• firewalld を一時的に緩めた状態（ゾーンを trusted にするなど）でも ENETUNREACH が続くかを検証する

---

firewalld 側の設定ミスで起こりやすいのは、次のようなパターンです。

• ゾーンへのインターフェース割り当てが誤っており、期待するセグメントが public として扱われている
• サービスやポートは許可されているが、フォワード設定（masquerade / forward ポリシー）が不足している
• デフォルトのポリシーが DROP で、例外ルールの書き忘れがある

これらは ENETUNREACH ではなく、タイムアウトや別種の到達不可として現れるケースが多いものの、現場の体感としては「つながらない」という一点で混同されがちです。そのため、ログやエラーコードを確認しないまま「まず firewalld を疑う」運用が定着すると、ルーティングの設計不備が後回しになり、結果として ENETUNREACH を繰り返すことになります。

本記事のテーマである ENETUNREACH を扱う際には、「firewalld はあくまで L3/L4 のフィルタであり、ルートが存在しない問題は解決できない」という前提を明確にしておく必要があります。そのうえで、「ルートが正しいことを確認したうえで、フィルタ設定を見直す」という順番を徹底することで、トラブルシューティングの効率を大きく高められます。

次章では、NetworkManager 以外のネットワーク管理として利用されることがある systemd-networkd にも触れ、静的ルートやポリシールーティングを設定ファイルベースで再現性高く維持する方法を概観します。

　

systemd-networkdと静的ルート・ポリシールーティングで再現性のある構成にする

Red Hat 系ディストリビューションでは、標準的には NetworkManager が利用されますが、特定の用途やコンテナホスト、アプライアンス用途などで systemd-networkd を採用するケースもあります。どのデーモンを利用するにしても重要なのは、「再起動やアップデート後もルーティング構成が再現可能であること」です。手作業で追加したルートや ip rule が、時間の経過とともに失われる構成は、ENETUNREACH を誘発しやすい不安定な状態と言えます。

systemd-networkd を用いる場合、ネットワークインターフェースごとに .network ファイルを用意し、その中で [Route] セクションや [RoutingPolicyRule] セクションを使ってルートやポリシールーティングを定義します。概念的には、次のような形になります。

[Route] Destination=10.20.30.0/24 Gateway=10.0.0.1

[RoutingPolicyRule]
From=10.0.0.0/24
Table=100

このように設定ファイルとして残しておけば、systemd-networkd が起動するたびに同じルート・ルールが再生成され、手作業による設定漏れやコマンド typo による不整合を減らせます。NetworkManager 環境でも同様で、「設定ファイル or 接続プロファイル」をルーティング構成の唯一のソース・オブ・トゥルースとし、それ以外の一時的なルート追加はあくまで障害対応のテストに留める運用が望ましいと言えます。

---

複雑なマルチホーム構成や、用途別にテーブルを分けるポリシールーティングを利用する場合は、systemd-networkd や NetworkManager の機能だけで完結しないケースもあります。その場合でも、最低限次のルールを守ると、ENETUNREACH を含む到達不可問題の再発リスクを抑えられます。

• 手作業で実行した ip route / ip rule コマンドは、必ず設定ファイルに反映し、適用手順をドキュメント化する
• 本番反映前にテスト環境で同じ設定ファイルを適用し、再起動後も構成が維持されることを確認する
• 設定の変更履歴をバージョン管理（Git 等）で記録し、過去の状態に戻せるようにする

ここまでで、ENETUNREACH を避けるためのルーティング設計・設定の基礎を概観しました。次章からは、実際の障害の流れを「タイムライン」として整理し、どの時点で何を確認・記録しておくと、再発防止に役立つのかを具体的に見ていきます。

　

障害発生ログから復旧までをタイムライン化して“再発防止チェックリスト”を作る

ENETUNREACH をはじめとするネットワーク到達不可エラーは、一度解消してしまうと「原因が曖昧なまま忘れられてしまう」ことが少なくありません。その結果、数カ月後に同様の構成変更や再起動が行われ、同じ ENETUNREACH が再発する、というパターンが繰り返されます。これを防ぐには、障害の流れをタイムラインとして記録し、「再発防止チェックリスト」に落とし込むことが有効です。

タイムラインは、少なくとも次のような項目で整理すると、後から読み返しやすくなります。

時刻	出来事	ログ・コマンド	所見
10:05	監視でアプリ疎通エラー検知	監視ツールのアラートログ	HTTP のタイムアウト増加
10:10	アプリログで ENETUNREACH を確認	アプリケーションログ	特定の外部 API 宛てのみエラー
10:15	ip route get 実行	ip route get 宛先IP	「Network is unreachable」と表示

このように、時刻・事象・実行したコマンド・そこから得られた所見を 1 つの表にまとめることで、「どの段階で ENETUNREACH が判明したのか」「どの段階でルーティングテーブルの欠落が確認できたのか」が明確になります。

---

タイムラインから再発防止チェックリストを作る際には、次のような項目がよく盛り込まれます。

• 構成変更の手順書に「ip route show の事前・事後比較」を含める
• NetworkManager / systemd-networkd の設定変更では、「設定ファイルのバックアップ」「変更内容のレビュー」「再起動後の疎通確認」を必須ステップにする
• アプリケーションログに、宛先 IP と errno を常に記録するよう修正する
• ルーティングテーブルの監視（想定されるデフォルトルートが消えたらアラート）を導入する

このようなチェックリストを運用手順書に組み込み、レビューや訓練の際に繰り返し確認することで、「ルートの消失から ENETUNREACH 発生まで」のパターンを組織として学習していくことができます。次章では、さらに一歩進めて、DR（災害復旧）やフェイルオーバー構成の中で ENETUNREACH をどう位置づけるかを整理します。

　

DRとフェイルオーバー構成でENETUNREACHを“想定内イベント”に変える

本番環境では、単一ホスト・単一回線の構成は少なく、DR サイトやフェイルオーバー構成が組まれていることが一般的です。このような環境では、「ある経路が利用不能になること自体」は完全には避けられません。重要なのは、「利用不能になった経路に依存している通信が、どれくらいの時間 ENETUNREACH のようなエラーを返し続けるか」を制御することです。

例えば、プライマリ回線とセカンダリ回線を持つ構成で、プライマリ側のルータ障害が発生すると、一時的にプライマリ回線宛てのルートが失われ、ENETUNREACH が発生することがあります。このとき、動的ルーティングプロトコルや VRRP 相当の仕組みで経路が書き換えられるまでの間、アプリケーションはエラーを受け取ります。設計の観点では、この時間をできるだけ短くし、かつ「切り替え中のエラーは許容される」という前提を運用設計に組み込むことが重要です。

DR・フェイルオーバー構成においては、次の観点で ENETUNREACH を扱います。

• フェイルオーバー時に、どの経路が一時的に失われるかを事前に洗い出す
• その経路に依存するアプリケーションが、どれくらいの時間 ENETUNREACH を許容できるかを合意しておく
• 切り替え試験時に、実際の ENETUNREACH 発生時間とアプリケーションのリトライ挙動を確認する

---

実際の設計では、Red Hat 系 Linux 自体よりも、周辺のロードバランサーやルータ、クラウドのネットワークコンポーネントの挙動が支配的になることも多くあります。そのため、個別案件では、「Linux 側のルーティングと、周辺機器・クラウドサービスのルーティング／ヘルスチェック設定」を一体として検証する必要があります。これは、一般的なドキュメントだけではカバーしきれない領域であり、実環境の構成情報とログをもとにした個別検証が不可欠です。

株式会社情報工学研究所のような専門家に依頼することで、単に ENETUNREACH を解消するだけでなく、「フェイルオーバー時にどのようなエラーがどの程度発生するか」「その間にアプリケーション側でどのような挙動を取るべきか」を含めた全体設計の支援を受けることができます。次章では、ここまでの内容を踏まえ、「つながらない」を限りなくゼロに近づけるために、設計・監視・手順書をどのように見直すべきかをまとめます。

　

「つながらない」を限りなくゼロに近づけるために――設計・監視・手順書をどう見直すか

ここまで、ENETUNREACH が示す意味から、ルーティング設計・NetworkManager や systemd-networkd の設定、firewalld との境界、DR／フェイルオーバー構成における位置づけまで、段階的に整理してきました。最終章では、それらをまとめて「設計」「監視」「手順書」という 3 つの観点から、具体的にどのような改善を行うと「Network is unreachable」エラーを減らせるのかを整理します。

設計の観点では、次のようなポイントが重要です。

• ホスト単位ではなく、システム全体としてどのセグメントがどの用途かを明確にする
• 用途ごとに「通常時の優先経路」と「障害時の代替経路」を決め、メトリックやポリシールーティングに反映する
• ルーティング構成のソース・オブ・トゥルースを設定ファイル／接続プロファイルに一元化する

監視の観点では、単にポート監視や ping 監視だけでなく、ルーティングテーブルの異常を検知する仕組みが有効です。例えば、「デフォルトルートが消えたらアラートを出す」「特定の宛先への ip route get の結果が変化したら検知する」といった監視を組み合わせることで、アプリケーションから ENETUNREACH が多発する前に兆候を捉えやすくなります。

---

手順書の観点では、構成変更や障害対応のたびに次のようなステップを踏むことを標準化するのが望ましいでしょう。

• 事前に現状の ip route show を採取し、作業後の結果と比較する
• NetworkManager / systemd-networkd の設定変更は、必ず設定ファイルとして残し、再起動試験を含めて確認する
• 障害時には、アプリケーションログの errno と宛先 IP を確認し、ENETUNREACH の有無を切り分けの起点とする
• 対応後はタイムラインと再発防止チェックリストを更新し、レビューの場で共有する

ここで扱った内容は、あくまで一般的な設計・運用の指針です。実際の案件では、オンプレとクラウドのハイブリッド構成、ゼロトラストネットワーク、マルチリージョン DR、コンテナ基盤やサービスメッシュなど、多数の要素が絡みます。そのような環境では、単純な「デフォルトルートの有無」だけでは説明できない ENETUNREACH も発生し得ます。

そのため、「一般論としてのベストプラクティス」を押さえたうえで、具体的なシステム構成・契約条件・運用体制に応じた個別検証を行うことが重要です。特に、ミッションクリティカルなシステムや、障害時の影響範囲が大きいシステムでは、設計段階からルーティング・フェイルオーバー・ログ設計・監視設計を一体として検討することが求められます。

株式会社情報工学研究所では、こうしたネットワークとサーバー、アプリケーションをまたいだ設計・検証・障害対応支援を行っています。もし、現在運用中の Red Hat 系 Linux 環境で ENETUNREACH を含む到達不可エラーが繰り返し発生している、あるいは今後の DR・フェイルオーバー設計に不安があるといった場合には、一般論だけで判断せず、一度専門家に相談することを検討してみてください。

　

主要プログラム言語ごとに見落としがちなENETUNREACHハンドリングの注意点

最後に、現在広く利用されている代表的なプログラム言語ごとに、ENETUNREACH を含むネットワークエラーの扱いで注意しておきたいポイントを簡潔に整理します。ここでは、言語仕様や標準ライブラリがどのような形でエラーを表現するかに着目し、「ログの残し方」と「リトライ戦略」の観点からまとめます。

まず C / C++ では、ソケット API を直接利用する場面が多く、connect() / send() / recv() の戻り値と errno を自前で判定することになります。ENETUNREACH が返っているにもかかわらず、アプリケーション側で「一時的エラー」として無制限にリトライしてしまうと、ルーティング構成が直らない限り永遠にエラーを繰り返すことになります。そのため、errno の値に応じて「再試行すべきエラー」（一時的なネットワーク障害や混雑など）と「構成問題が疑われるエラー」（ENETUNREACH や EINVAL など）を分けて扱う設計が重要です。

Java では、ソケットや HTTP クライアントのエラーは IOException のサブクラスとして表現されることが多く、NoRouteToHostException や ConnectException といった例外名として現れます。スタックトレースだけをログに残し、例外種別やメッセージ（「Network is unreachable」など）を集約・分析していないと、ENETUNREACH と他のエラーを統計的に区別することが難しくなります。Spring などのフレームワークを利用している場合は、例外ハンドリング層で例外種別を分類し、監視との連携（特定の例外が一定回数以上発生した場合にアラートを上げるなど）を検討するとよいでしょう。

Python では、socket モジュールや requests ライブラリを通じてネットワーク通信を行うことが多く、エラーは OSError や requests.exceptions.* の形で現れます。Linux 上で ENETUNREACH が発生した場合、OSError の errno 属性に 101 がセットされることがありますが、アプリケーション側のコードでそれを明示的に確認していないと、「タイムアウト」や「接続拒否」と同列に扱われてしまいます。リトライ処理を実装する際には、「OS レベルの errno に基づく分岐」「HTTP ステータスコードに基づく分岐」などを整理し、ENETUNREACH を無制限なリトライの対象から外す設計が望ましいと言えます。

Go 言語では、ネットワークエラーは net.Error インターフェースを実装したエラーとして返されることが多く、Timeout() や Temporary() メソッドの結果で「再試行すべきかどうか」を判断するパターンが一般的です。ただし、ENETUNREACH のように構成問題を示唆するエラーを「Temporary」と誤って扱うと、goroutine が無制限にリトライを繰り返し、システム全体の負荷増大につながる可能性があります。エラー文字列の中に「no route to host」や「network is unreachable」といった文言が含まれていないかを確認し、ログに明示的に残す実装を検討すると、運用側での分析が容易になります。

Node.js / JavaScript では、HTTP クライアントや TCP ソケットのエラーが ECONNREFUSED や ENETUNREACH といったコードを持つ Error オブジェクトとして渡されることがあります。非同期処理のチェーンの中でエラーを握りつぶしてしまうと、最終的にどの種類のエラーがどれだけ起こっているのかを把握できなくなります。Promise や async/await を利用する場合でも、エラーコードに応じた分類ログ（メトリクス）を残し、「どのサービス間通信で ENETUNREACH が多発しているか」を可視化することが、構成問題の早期発見につながります。

いずれの言語でも共通するのは、ENETUNREACH を「通常の一時的エラー」と同列に扱って無条件にリトライするのではなく、「構成・ルーティング・運用手順を見直すべきシグナル」として扱うことです。そのためには、アプリケーションコード側で errno や例外種別をきちんとログに残し、監視やアラート設計と連携させることが欠かせません。個別の言語・フレームワークごとのベストプラクティスは、本記事の範囲を超える部分も多く含まれますが、実際のシステム構成と組み合わせて検討することで、より堅牢なネットワークエラー処理が実現できます。

もし、特定の言語やフレームワークで ENETUNREACH を含むネットワークエラー処理の設計に悩んでいる場合は、インフラ構成とアプリケーションコードの両面から評価・提案ができる専門家に相談することが有効です。株式会社情報工学研究所では、Linux ネットワークとアプリケーション実装の両方を踏まえた観点から、ログ設計やエラーハンドリング方針の見直しを含む支援も行っています。