Linux ENONET (64) 対策：Machine is not on the network エラーの原因解析と対処編

【注意】本記事はLinuxのENONET(64)「Machine is not on the network」を“安全に切り分ける”ための一般情報です。現場で焦って設定を乱発すると、原因が隠れたり影響範囲が広がったりします。まずはログと状態を保全し、業務影響や契約要件（SLA/監査/変更手順）を踏まえた判断が必要です。具体的な案件・構成・制約がある場合は、株式会社情報工学研究所のような専門事業者へご相談ください。

　

「ネットは生きてるのにENONET？」—夜間障害で一番つらい“説明できない”瞬間

「疎通はできてる。DNSも引けてるっぽい。なのにアプリだけが ENONET(64) で落ちる」――この手の障害、現場の体感としては“いちばん嫌な部類”です。

心の中ではこうなりがちです。

「またネットワークか…でも監視は緑だし、他の通信は動いてる。何を説明すればいい？」

ここで大事なのは、ENONETを“回線トラブル”として扱わないことです。ENONETは、多くの場合「そのプロセスの見ているネットワーク前提（名前空間・IF状態・経路・名前解決）が崩れている」サインで、アプリ視点の“到達不能”が露出した結果です。

---

症状 → 取るべき行動（まず30秒でやること）

症状（観測）	取るべき行動（安全な初動）
アプリだけENONET、同ホストのcurlは成功	アプリを再起動連打しない。まず strace でどのsyscallで失敗しているか確認し、同時刻のログを保全する。
コンテナ/PodだけENONET、ホストは正常	名前空間差分を疑う。ip netns / Pod内で ip addr, ip route, resolv.conf を採取し、CNI/iptables/nftの変更履歴を確認。
特定宛先だけENONET（社内/閉域/VPN側）	ip route get 宛先で経路を確定。ポリシールーティング（ip rule）やVRF、rp_filterの影響を確認。
断続的にENONET、しばらくすると直る	“状態遷移”が原因のことが多い。リンク状態、DHCP/RA更新、VPN再接続、DNSの切替など、直前のイベント（journalctl）を時系列で追う。

---

やりがちな悪手（状況を悪化させる行動）

• 「とりあえず直せ」で ネットワーク設定を大量に書き換える（原因の痕跡が消える）
• iptables/nftを 全面フラッシュ（セキュリティ境界や別系統の通信が壊れる）
• アプリを 無限リトライ させてログを埋める（必要なログが流れる）

判断基準：今すぐ相談した方が早いケース

次に当てはまる場合、一般論だけで粘るより、早めに第三者視点を入れた方が“収束”が速いです（関係者説明も含めて）。

• 本番で再現が不安定で、変更できる時間帯が限られている
• 閉域/VPN/拠点間など、ネットワーク境界が複数ある
• Kubernetesや複数のnetns/VRFが絡み、責任分界が曖昧
• 監査・SLA・顧客報告が必要で、説明可能な根拠が求められる

「自分で直せるかも」と思っても、現実には“説明責任”がいちばん重いことがあります。そういうときは、株式会社情報工学研究所への無料相談（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983、電話：0120-838-831）を、選択肢として持っておくと安心です。

この章のまとめ

ENONETは「ネットが壊れた」よりも、「そのプロセスが置かれた前提条件が崩れた」ことを疑うのが近道です。次章から、どのsyscallで、どういう条件でENONETが出るのかを“戻り値起点”で整理します。

　

ENONET(64) はどのsyscallで返るか—socket/connect/sendtoの戻り値を起点にする

ENONET(64) を攻略するコツは、抽象的な「ネットワーク障害」という言葉を捨てて、どのsyscallが、どの条件で失敗したかに落とすことです。

現場の“心の会話”はだいたいこうです。

「アプリログにはENONETしか出てない。で、結局どこを見ればいいの？」

見るべきは「アプリが失敗した瞬間のOSとの境界」です。代表的には次の系統でENONETが表に出ます。

ENONETが見えやすいsyscallのパターン

系統	例	着眼点
接続（TCPなど）	connect()	経路（route）や名前空間差分、VRF/ポリシールーティングの影響が出やすい
送信（UDPなど）	sendto(), sendmsg()	宛先に対して「そのホスト/プロセスが属するネットワークから到達できない」状態が露出しやすい
名前解決（間接要因）	getaddrinfo() 等	直接ENONETが出ないことも多いが、DNS遅延/失敗が“ネットにいない”ように見せる（後段の通信失敗を誘発）

---

まずはstraceで「失敗点」を固定する

手元でできる最小の一手は、対象プロセス（または再現できる最小コマンド）に対して strace を当て、errnoが返ったsyscallを特定することです。

strace -f -tt -o /tmp/trace.log -e trace=network,connect,sendto,recvfrom,getaddrinfo curl -v https://example.com

アプリ本体に当てるなら、実行権限や影響（ログ量）に注意しつつ、短時間で切り上げます。ポイントは「いつ・どの宛先に対して・どのsyscallが・何のerrnoで失敗したか」を1つの線にすることです。

“ENONET単体”では原因は決まらない

ここが落とし穴です。ENONETは“症状ラベル”であって、原因そのものではありません。同じENONETでも、次のように打ち手が変わります。

• 経路がない/選べない：ip route / ip rule / VRF / ルーティングテーブル
• IFやアドレスが前提を満たしていない：ip link / ip addr / DHCP / RA
• 名前空間が違う：netns、コンテナ、K8s
• 名前解決やタイムアウトの連鎖：resolv.conf、systemd-resolved、検索ドメイン

---

この章のまとめ

ENONETを“説明できる障害”に変えるには、まず戻り値を固定し、syscall→宛先→ネットワーク前提（経路/IF/netns/DNS）のどこが崩れているかに落とすことです。次章では、現場で再現しにくいENONETを「最小再現」にして、切り分けを前に進めます。

　

“Machine is not on the network” を再現してみる—最小コードと失敗条件の作り方

障害対応が長引く理由の多くは、「本番でしか起きない」「起きたり起きなかったりする」という再現性の低さにあります。ここでの狙いは、原因を断定することではなく、再現条件を“狭く”することです。狭くできれば、検証も説明も一気に楽になります。

現場の独り言はこうです。

「再現できないのに、何を直せばいいんだ…」

その状態から抜けるために、“最小再現”を作るときの原則を押さえます。

原則1：同じ宛先・同じプロトコル・同じ名前空間で試す

たとえば「アプリはENONETだが、ホストでcurlは通る」場合、まず疑うべきは “同じ条件で試せていない” ことです。アプリがコンテナ内なら、ホストではなくコンテナ内で同じ宛先に対して試します。

# コンテナ/Pod内での確認（例） ip addr ip route cat /etc/resolv.conf getent hosts example.com curl -v https://example.com

これだけで、ホスト側の確認が“的外れ”だったと判明することがあります（ホストの経路やDNSは正しくても、アプリ側が見ているものが別なら意味がありません）。

---

原則2：ip route get で「OSが選んだ経路」を確定する

ENONETの切り分けでは、ip route get が非常に効きます。宛先に対して、OSがどのIF/ゲートウェイ/送信元IPを選ぶかを一発で見られるからです。

# 宛先IPまたは名前解決後のIPに対して ip route get 203.0.113.10

ここで“期待と違う経路”が出る場合、ポリシールーティング（ip rule）やVRF、送信元選択、あるいはルーティングテーブルの前提が崩れている可能性が上がります。

原則3：差分を“変更”ではなく“採取”で詰める

焦ると「設定を変えて試す」方向に走りがちですが、再現性が低いときほど変更は危険です。状況が動いてしまい、原因が隠れます。おすすめは“採取で詰める”アプローチです。

• 状態採取：ip link / ip addr / ip route / ip rule / ss -tnp / resolv.conf
• ログ採取：journalctl（ネットワークサービス、VPN、CNI関連）
• パケット：tcpdump（送信が出ているか、ARP/NDは解決しているか）

---

最小コードで“失敗点”だけを見る（例：UDP送信）

アプリがUDP送信で落ちている疑いがあるなら、まずは送信だけの最小コードに落として、同じ環境（同じnetns）で試します。言語は何でもよいですが、重要なのは「どの呼び出しが失敗し、errnoが何か」をログとして残すことです。

# 例：送信確認に使える観測（コードではなく“観測の形”） # - 送信前に宛先IPを確定（名前解決の影響を切り分ける） # - 送信後にtcpdumpで実際に出ているかを見る # - 失敗したらerrnoを必ず記録する

ここで「送信自体が出ていない」なら、経路/IF/名前空間のどこかが先に崩れています。逆に「送信は出ているが返りがない」なら、ENONET以外の観点（FW、対向、MTUなど）も含めた切り分けに移れます。

---

この章のまとめ

“再現できない”は、対応が泥沼化する最大要因です。再現を作るコツは、条件を揃え（同じ宛先・同じプロトコル・同じ名前空間）、変更より採取で差分を詰め、ip route get でOSの判断を固定することです。次章以降は、原因を「名前空間／IF状態／経路／名前解決」の4分類に収束させ、順番に深掘りしていきます。

　

原因は4つに収束する—名前空間／IF状態／経路／名前解決のチェックリスト

ENONET(64) が出たとき、「原因は無限にある」と感じます。でも実務で切り分けるなら、観測ポイントはかなり絞れます。多くのケースで、根は次の4分類のどれか（または組み合わせ）に収束します。

4分類（最短で“当たり”をつける枠組み）

分類	起きがちな状況	まず見るコマンド
名前空間（netns/コンテナ）	ホストは正常だが、コンテナ/特定プロセスだけ失敗	（当該環境内で）ip addr / ip route / cat /etc/resolv.conf
IF状態（リンク/アドレス）	リンクはup表示でも、アドレスや近隣解決が破綻	ip link / ip addr / ip neigh
経路（route/rule/VRF）	宛先によって失敗、拠点/VPN/多段ルートで顕在化	ip route / ip rule / ip route get 宛先
名前解決（DNS/hosts）	一見ネット不調に見えるが、実は名前→IPが崩れる	getent hosts / resolvectl / dig（環境に応じて）

---

“心の会話”を味方につける：切り分けは順番が大事

現場だと、だいたいこう思います。

「どれから見ればいい？全部見ると時間が溶ける…」

おすすめの順番は、差分が出やすい順です。

1. 名前空間（ホストとアプリが同じ世界にいるか）
2. IF状態（アドレスと近隣解決が成立しているか）
3. 経路（OSがどの道を選んだか）
4. 名前解決（名前→IPが期待どおりか）

理由は単純で、名前空間が違えば以後の確認が全部ズレるからです。次にIF状態が崩れていると、経路があっても届きません。その後に経路、最後に名前解決を詰めると、無駄が減ります。

---

チェックリスト（採取用テンプレ）

“変更する前に採取する”ための最小セットです。障害報告や顧客説明にも使えます。

• 時刻：date / timedatectl（NTP同期の有無）
• 名前空間：コンテナ/Pod内で ip addr, ip route（ホストと比較）
• IF状態：ip link / ip addr / ip neigh（ARP/NDの揺れを見る）
• 経路：ip route / ip rule / ip route get 宛先
• ソケット状態：ss -tnp / ss -unp（待ち受け・接続の詰まり）
• 名前解決：getent hosts 対象名 / cat /etc/resolv.conf（環境依存で resolvectl）
• ログ：journalctl（networkd/NetworkManager/VPN/CNI/カーネル）

この章のまとめ

ENONETは“広い障害”に見えても、実務では4分類に畳めます。まずは採取して、どの分類が濃いか当たりをつける。次章からは、その中でも頻出の「IF状態」から具体的な落とし穴を掘ります。

　

IF状態編：link upでも落とし穴—DOWN、NO-CARRIER、アドレス未設定、ARP/NDの不整合

「ip link でUPになってる＝ネットワークは生きてる」と思いがちですが、実際には“UPでも通信前提を満たしていない”ことは普通に起きます。ENONETが出る状況では、IF状態（リンク・アドレス・近隣解決）のどこかが破綻しているケースが多いです。

1) link状態の読み違い：UPとLOWER_UPは別物

ip link の表示で、管理状態（UP/DOWN）と物理的なリンク（LOWER_UP/NO-CARRIER）は別です。仮想IFやブリッジ配下だと、さらに直感が外れます。

ip link show # 例：state DOWN / NO-CARRIER / LOWER_UP などを確認

ここでNO-CARRIERやDOWN相当が出ているのに、上位サービスが「通信できる前提」で動き続けると、アプリ側でENONETや近いエラーが噴きます。

---

2) アドレス未設定：DHCP/RAの取りこぼし

リンクはUPでも、IPアドレスが付いていなければ当然到達できません。とくにDHCPやIPv6 RA（Router Advertisement）に依存している環境だと、再起動直後やネットワーク切替の瞬間に“アドレス空”が起きることがあります。

ip addr show # inet/inet6 が期待どおり付いているか

また、複数アドレスが付く環境では「送信元選択」が想定外になり、結果として経路選択もズレます。これが後段の章（経路）に繋がる伏線です。

---

3) 近隣解決（ARP/ND）の破綻：見落とされがちだが効く

“同一L2内の到達”は、結局ARP（IPv4）やND（IPv6）で隣のMACを引けることが前提です。ここが詰まると、アプリ視点では「ネットワークにいない」ように見えることがあります。

ip neigh show # FAILED/INCOMPLETE/STALE が大量に出ていないか

STALEは必ずしも異常ではありませんが、特定宛先だけFAILEDが続くなら、L2の前提（VLAN、ブリッジ、フィルタ、MAC学習、対向機器）を疑う根拠になります。

---

4) MTU/フラグメンテーションの罠：疎通はするがアプリだけ壊れる

MTU不整合は「小さいパケットは通るが、大きい通信が壊れる」症状を作ります。ENONETそのものの典型原因ではないものの、ENONETと併発したり、現場で“ネットが変”という印象を強めたりします。

この場合、pingのサイズ指定（DF付与）や、tcpdumpでICMP frag needed が出ていないかなど、観測で当たりを付けます。ただし無闇にMTUを変更するのは危険なので、変更は後段（影響評価）に回すのが安全です。

---

章内まとめ：IF状態は「UPならOK」ではない

IF状態の切り分けで重要なのは、(1)リンクの実体、(2)アドレスの成立、(3)近隣解決、(4)サイズ前提（MTU）です。ここが健全だと確信できて初めて、次章の「経路（route/rule/VRF）」を疑う価値が出ます。

　

経路編：default routeがあるのに届かない—ポリシールーティング、VRF、rp_filter、firewalld/nft

「default route はある。なのに届かない」――ここがENONET調査の山場になりがちです。理由は、Linuxの“経路”が1本ではなく、複数の仕組みが重なって最終判断が決まるからです。

心の会話はだいたいこれです。

「route見たけど、あるじゃん…なんで？」

答えは、「見たのは“ある経路”であって、“その通信が実際に選ぶ経路”ではない」可能性です。

まずは ip route get で“OSの最終判断”を見る

経路の切り分けで一番手堅いのは、宛先に対してOSが何を選んだかを見ることです。

ip route get 203.0.113.10 # どの dev / via / src を選ぶかが出る

ここで src（送信元IP）まで含めて確定します。送信元が変われば、ポリシールーティングの条件に引っかかり、別テーブルへ飛ぶことがあります。

---

1) ポリシールーティング（ip rule）：見えていない“別ルート”

ip route だけ見ていると、ip rule（ルール）によるテーブル切替を見落とします。たとえば送信元IPやfwmarkで、テーブルが分岐していることがあります。

ip rule show ip route show table main ip route show table all

特定のアプリだけENONETになる場合、アプリが使う送信元IP、またはマーク付け（ポリシー）が関与していることもあります（環境によっては、特定プロセスやサービスに対してmarkが付く設計があります）。

---

2) VRF：同じホストでも“別の世界”を作る

VRFを使っている環境では、「同一ホスト内でネットワークが分離」されます。ホストの一般コマンドで疎通が取れても、対象プロセスが属するVRFが違えば、到達性は別物です。

VRFは強力ですが、運用設計（所属の明確化、監視の分離、トラブル時の切り戻し）が甘いと、説明が難しい障害になります。ここは終盤の“運用で再発を潰す”伏線です。

---

3) rp_filter（逆方向フィルタ）：帰り道の不整合を弾く

マルチホーム（複数IF/複数経路）環境で、rp_filter設定が厳しいと、非対称経路（行きと帰りが違う）を弾いてしまうことがあります。結果として「経路はあるのに通信が成立しない」状態が起きます。

ただし、この種の設定はセキュリティ・運用ポリシーと直結します。だからこそ、無闇に緩めず、まずは“なぜ非対称になったか”を追うのが安全です。

---

4) firewalld/nft/iptables：経路ではなく“通行止め”

ENONETの主因というより、現場で混線しやすいポイントです。経路は正しくても、フィルタで落ちれば通信は成立しません。ここは「tcpdumpで送信が出ているか」「返りが来ているか」で観測します。

特にコンテナやKubernetesは、CNIがiptables/nftを動的に書き換えることがあります。変更履歴が追えないと説明が難しくなるので、後段で“ログと変更管理”に繋げます。

---

章内まとめ：経路は“1枚の表”では終わらない

経路の切り分けは、ip route（テーブル）だけでは不十分で、ip rule（分岐）、VRF（分離）、rp_filter（逆方向整合）、フィルタ（通行止め）が重なります。まず ip route get でOSの判断を固定し、そこから分岐要因を潰すのが最短です。

次章では、ホストとアプリが違う世界を見る代表格「名前空間・コンテナ」を掘ります。

　

名前空間・コンテナ編：ホストはOKなのにアプリだけNG—netns、K8s/CNIの境界

ENONET(64) が「アプリだけ」「特定サービスだけ」で出るとき、まず疑うべきは “同じホスト上にいても、同じネットワークを見ていない” ことです。Linuxはネットワーク名前空間（netns）で、ルーティング・IF・iptables/nft・ソケット空間を分けられます。コンテナやKubernetesは、まさにこの仕組みを前提に動いています。

現場の本音はこうなりがちです。

「ホストでcurlは通るのに、アプリだけ“ネットにいない”ってどういうこと？」

答えはシンプルで、ホストのcurlと、アプリの通信が“別の世界”から出ている可能性があるからです。

---

1) まず“どの世界で”確認しているかを揃える

コンテナ/Podの中で失敗しているなら、確認も必ずその中で行います（ホスト側の確認だけではズレます）。最低限、次の3点を採取します。

• IPアドレス：ip addr
• 経路：ip route（可能なら ip route get 宛先）
• 名前解決：cat /etc/resolv.conf、getent hosts 対象名

ここで「アドレスが無い」「default route が無い」「resolv.conf が想定外」などが出れば、ENONETの説明が一気に具体化します。

---

2) Kubernetesで起きがちな“境界由来”の失敗

Kubernetes環境では、Podの通信はCNI（Container Network Interface）実装が作る仮想IF・経路・フィルタに依存します。典型例は次のとおりです。

• Pod再作成直後の瞬間的な未準備：アプリ起動が早すぎて、netns内のIF/routeがまだ整っていない
• NetworkPolicy/フィルタ変更の影響：許可される宛先が変わり、アプリだけ到達不能に見える
• ノード側の設定変更：nft/iptablesの挙動差、モジュール、カーネル更新などでCNIの前提が崩れる

これらは「コードの問題」ではなく「境界の設計と運用」の問題になりやすいのが特徴です。だからこそ、後半の章で扱う“監視・runbook・変更管理”が効いてきます（ここが伏線です）。

---

3) “採取→比較”で説明可能な形にする

責任分界が絡む現場では、技術的に直すだけでなく「なぜそう言えるのか」を示す必要があります。おすすめは、ホストとPod（または対象プロセス）の差分を表で揃えることです。

観測点	ホスト	Pod/コンテナ
ip addr	期待のアドレス	付与漏れ/別アドレス
ip route	defaultあり	defaultなし/別GW
resolv.conf	社内DNS	別DNS/検索ドメイン差

この章のまとめ

「ホストは正常なのにアプリだけENONET」は、netns/コンテナ/K8sの境界が絡むと“普通に起きる”現象です。確認は必ず同じ世界（同じnetns）で揃え、採取→比較で説明可能な根拠を作ることが、被害最小化と収束の近道です。

　

名前解決編：DNSの遅延が“ネットにいない”を演出する—resolv.conf、systemd-resolved、検索ドメイン

ENONETは「経路やIFの問題」で出ることが多い一方、現場で混線しやすいのが 名前解決 です。DNSが遅い/揺れると、アプリは「接続できない」だけを表に出し、結果として“ネットワークが壊れた”ように見えます。ここを切り分けておくと、ムダなネットワーク変更を避けられます。

心の会話はこうです。

「疎通が悪い…いや、そもそも名前が引けてない？でも時々動くんだよな」

---

1) まず「名前→IP」をOS標準の経路で確認する

アプリが使う解決経路と合わせるには、まず getent hosts が手堅いです（glibc/NSS経由で、/etc/hosts やDNSなどを総合して引きます）。

getent hosts example.com

ここで不安定なら、ENONET以前に「宛先IPが定まっていない」可能性があります。逆にここが安定していれば、以後は経路やIFの問題に集中できます。

---

2) /etc/resolv.conf の中身は“実体”か“生成物”か

Linuxでは /etc/resolv.conf が、NetworkManager や systemd-resolved などによって生成・切替されることがあります。コンテナ/Pod内では、ホストと別のresolv.confが置かれます。確認ポイントは次のとおりです。

• nameserver が想定のDNSか（社内DNS/クラウドDNSなど）
• search（検索ドメイン）が過剰で、問い合わせが膨らんでいないか
• options timeout/attempts の設定で待ち時間が増えていないか

DNS遅延は「ネットワーク不良に見える」典型要因です。とくに検索ドメインが長いと、短い名前を引くたびに複数問い合わせが発生し、アプリ側のタイムアウトやリトライと絡んで“詰まり”を作ります。

---

3) systemd-resolved を使う環境の注意点

systemd-resolved を利用している場合、実際の名前解決はスタブ（127.0.0.53等）経由になり、/etc/resolv.conf の見え方が直感とズレることがあります。こういう環境では、可能なら resolvectl で状況を採取すると説明しやすくなります（使えない環境もあります）。

重要なのは「DNSがどこか」だけでなく、どのIFにどのDNS設定が紐づいているかです。VPN接続で“DNSだけ社内向けに切替”が入る構成だと、接続/切断タイミングの揺れが障害の引き金になります。

---

4) 名前解決が原因のときの“正しい収束”

名前解決が原因なら、ネットワーク経路をいじるより、DNS設定・検索ドメイン・タイムアウト設計・キャッシュ設計の見直しで“収束”します。ここで大切なのは「一般論のDNS高速化」ではなく、そのシステムの制約（社内DNS、拠点、VPN、監査要件）に合わせた落としどころを作ることです。

この章のまとめ

DNSは、障害を“ネットワーク全体の不調”に見せる代表要因です。まず getent で安定性を確認し、resolv.conf（生成元も含む）と検索ドメインの設計を押さえると、無駄な作業が減ります。次章では、ここまでの要素を束ねて「現場で勝つ切り分け手順」を、証拠が残る形で組み立てます。

　

現場で勝つ切り分け手順—ip/ss/ping、tcpdump、strace、ログ相関で「ここが壊れてる」を特定

ここまでで、ENONETの原因が「名前空間／IF状態／経路／名前解決」に収束する話をしました。ここからは実務の型です。ポイントは、短時間で“壊れている場所”を指差せる証拠を集めること。これがあると、関係者調整・保守ベンダ・ネットワーク担当との会話が一気に進みます。

現場の独り言はこうです。

「結局、“どこが悪い”って一言で言えないと終わらないんだよな…」

---

ステップ0：変更せず、採取から始める（タイムラインを作る）

まずは“いつから・何が・どの範囲で”を揃えます。最小でよいので、時刻とログを合わせます。

• date / timedatectl（時刻同期の前提）
• アプリログ（ENONETが出た時刻・宛先・頻度）
• journalctl（networkd/NetworkManager/VPN/CNI/カーネルのイベント）

この段階で「VPN再接続」「IFのdown/up」「DNS切替」などのイベントが見えたら、後の切り分けが速くなります。

---

ステップ1：同じ世界（同じnetns）で “IP/経路/DNS” を固定する

• ip addr
• ip route（可能なら ip route get 宛先）
• getent hosts 対象名 / cat /etc/resolv.conf

ここで崩れていれば、原因分類がほぼ決まります。崩れていないなら次へ進みます。

---

ステップ2：ss でソケットの詰まりを確認する

TCPなら、接続がSYN-SENTで詰まっているのか、ESTABなのに応答がないのかで景色が変わります。UDPでも、プロセスがどのポートを使っているかを把握できます。

ss -tnp ss -unp

---

ステップ3：tcpdumpで「出ているか／返っているか」を見る

経路やフィルタの疑いを固めるには、パケット観測が強いです。送信が出ていないなら、前提（IF/route/netns）が崩れている。送信が出ていて返りがないなら、対向や途中経路、フィルタ、MTUなど別論点が濃くなります。

ただし本番では観測範囲・個人情報・機密要件に注意が必要です。採取は“最小・短時間”で行い、保存と取り扱いルールを守ります。

---

ステップ4：straceで「どのsyscallが、何のerrnoで」落ちたかを確定する

アプリが吐くENONETだけでは、根拠が弱いことがあります。可能なら短時間だけstraceで境界を押さえます。

strace -f -tt -o /tmp/trace.log -e trace=network,connect,sendto,recvfrom,getaddrinfo <対象プロセス/再現コマンド>

これで「connectがENONET」「sendtoがENONET」のように“失敗点”が言語化でき、原因分類（経路/IF/netns）へ綺麗に接続できます。

この章のまとめ

ENONET対応は、勘や経験だけだと長期化しがちです。採取→同一世界で確認→ss→tcpdump→strace、という順で“証拠の線”を作ると、収束が速くなり、説明責任も果たしやすくなります。

　

なるほどと思える帰結：ネットワークは“ケーブル”ではなく“前提条件の集合”—監視・runbook・自動復旧で再発を潰す

ENONET(64) を追いかけていると、最後はだいたい同じ結論にたどり着きます。ネットワークは「線がつながっているか」ではなく、“前提条件が揃っているか”で成立している、ということです。

前提条件とは、ここまで扱ってきたもの――名前空間、IF状態、経路、名前解決――そして、それらを動かす運用（変更・再起動・自動化・権限分界）です。

---

ENONETが“再発”しやすいチームの共通点

これは個社批判ではなく、構造として起きがちな話です。ENONETが長引く現場は、次の条件を抱えやすいです。

• システムがレガシーで、止められない（検証が本番寄りになりがち）
• 境界が多い（VPN、拠点間、閉域、コンテナ、K8s、複数経路）
• 変更が多いのに、変更履歴と観測点が揃っていない（「いつ何が変わったか」が追えない）
• 責任分界が曖昧（アプリ／インフラ／ネットワーク／運用の“間”で詰まる）

こういう条件のとき、障害は“技術”だけでなく“説明”でも詰まります。だからこそ、再発防止は「機能追加」より場を整える方向が効きます。

---

再発防止は「観測できる前提条件」を作ること

ENONET対策で強いのは、次の3点を“毎回取れる形”にすることです。

狙い	具体策（例）	得られる効果
前提条件のスナップショット化	ip addr / ip route / ip rule / resolv.conf / ss の定期採取（差分ログ化）	「いつ崩れたか」が追える（説明が速い）
runbook（切り分け手順）の固定	本記事のsec04〜sec09の手順を、環境固有のコマンドに落として文書化	属人性を下げ、収束が速くなる
変更と復旧の“安全弁”	変更前後の状態採取、段階的ロールバック、影響範囲の限定	被害最小化・軟着陸がしやすい

---

“自動復旧”を入れるなら、先に「誤復旧」を防ぐ

自動復旧（再起動・再接続・再解決）は強力ですが、乱暴に入れるとログが埋まり、原因が隠れます。おすすめは「条件付き・段階的」です。

• まずは観測（採取）を優先し、失敗の瞬間を残す
• リトライは回数・間隔を制御し、無限ループにしない（ストッパーを置く）
• 復旧アクションの前後で、状態（ip/route/DNS/ss）を自動記録する

これだけで、障害対応は「泥沼」から「手順化」に寄っていきます。

---

一般論の限界：ここから先は“あなたの構成”が答えを決める

ここまでの話は、ENONETを技術的に整理するための一般論です。ただ、実務では次の要因で答えが変わります。

• 閉域/VPN/拠点間などの境界設計（どの経路を正とするか）
• Kubernetes/CNI/NetworkPolicy の実装差（どこが状態を作るか）
• 監査・SLA・変更手順（何を“やってよい”か、いつやれるか）
• 既存システムの制約（止められない、変更できない、触れる範囲が限られる）

つまり、最後は「この構成・この契約・この運用」で、どの選択が安全かを決める必要があります。そこまで含めて“収束”させたいときは、第三者の視点が効きます。

次の一歩：困ったときに、相談先を1つ持っておく

ENONETは、原因が1つとは限らず、境界が増えるほど説明が難しくなります。もし「今の状況を整理して、最短で収束させたい」「顧客・社内への説明も含めて整えたい」と感じたら、株式会社情報工学研究所への相談・依頼を検討してください。

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983　電話番号：0120-838-831

“作業を増やす提案”ではなく、“必要な観測点を揃えて、収束させるための道筋”から一緒に組み立てます。

　

付録：現在のプログラム言語各種での注意点—ENONETを「握りつぶさず」「誤診しない」ために

ENONET(64) はLinuxカーネルが返す errno の一つで、ユーザー空間では「例外」や「エラーコード」として見えます。ただし、言語やライブラリによって見え方が違い、メッセージはロケールや実装差で変わります。重要なのは、“文字列”ではなく“元のOSエラー（errno/OS error code）”をログに残すことです。

---

C / C++（POSIXソケット）

• 失敗したsyscall（connect/sendto等）直後に errno を必ず採取する（別の呼び出しで上書きされる）。
• ログには「宛先IP/ポート」「送信元IF/送信元IP（分かる範囲で）」「タイムスタンプ」をセットで残す。
• 非同期I/Oや別スレッドでエラーを処理する場合、errnoの扱いを誤ると誤診につながる（スレッドローカルである点は理解していても、ログ集約で混線しがち）。

Go（netパッケージ）

• net.Dial等のエラーはラップされるため、ログでは errors.As で net.OpError / os.SyscallError / syscall.Errno を辿れる形にしておく。
• 「DNS解決で詰まっているのか」「接続で詰まっているのか」を分けるため、解決段階と接続段階のログを分離する。
• タイムアウトは必ず明示する（デフォルト任せは環境差が出る）。

Java（JVM言語含む）

• 例外（SocketException等）の メッセージ文字列に依存しない。環境やJRE差で表現が変わる。
• 名前解決（InetAddress）のキャッシュ挙動が問題の切り分けを難しくすることがあるため、DNS起因が疑わしい場合は「どの時点で名前を引いたか」をログに残す。
• 接続・読み書きのタイムアウト設定を明示し、どの段階で失敗したか（resolve/connect/read）を分けて記録する。

Python（socket / requests など）

• OSError系例外では、e.errno（または e.args）からOSエラー番号を確実に採取する。
• requests等の高レベルライブラリは例外がラップされるため、根の例外（__cause__ / __context__）を辿ってerrnoを残す設計が安全。
• リトライ実装は無限化しやすいので、回数上限・間隔・サーキットブレーカー的な抑え込み（ブレーキ）を入れる。

Node.js（JavaScript / TypeScript）

• ネットワークエラーは libuv 経由のコード（err.code など）で見える。ログには code と宛先、発生フェーズ（DNS/接続/送信）を必ず残す。
• DNSまわりは非同期で見え方が変わるため、「解決に失敗したのか」「解決後の接続で失敗したのか」を分けて扱う。
• 再接続ループが暴走するとログと負荷が増えるため、間隔制御と上限（ストッパー）を必須にする。

Ruby

• Errno::ENONET のように例外クラスとして見えることがある。文字列より 例外クラス と宛先情報を記録する。
• ライブラリが握りつぶすケースがあるため、例外チェーンや戻り値仕様を把握し、根の例外が残るようにする。

Rust

• std::io::Error は ErrorKind だけでなく、raw_os_error() を必ずログに残す（OS依存の差分を保持できる）。
• 非同期ランタイム利用時は、どのタスク/どの宛先で失敗したか（コンテキスト）をログに含める。

PHP

• stream_socket_client 等は警告やfalse戻りになることがあり、エラー原因がログに残らない実装になりやすい。必ずエラー番号・エラーメッセージを取得し、宛先とセットで保存する。
• FPM/ワーカー環境では、同時多発時にログが混線しやすいので、リクエストID等の相関キーを入れる。

C#（.NET）

• SocketException のエラーコードやSocketErrorで分類できるが、OS側のエラーとの差分が出ることがある。ログにはコードと宛先に加え、失敗フェーズ（名前解決/接続/送信）を残す。
• バックグラウンド再接続はスパイクを起こしやすいので、指数バックオフ等で温度を下げる。

---

言語を問わず共通の「事故を減らす」実装ポイント

• ログは「エラー文字列」よりOSエラー番号と失敗フェーズを残す（resolve/connect/send）。
• 宛先（FQDN/IP/Port）と、可能なら送信元（src/IF）も残す。可能であれば障害時に ip route get の結果を採取する。
• リトライは“正義”ではない。上限・間隔・停止条件を設計し、暴走を防ぐ（被害最小化）。
• コンテナ/K8sでは「ホストで通る」は根拠になりにくい。必ず同じnetnsで採取する。

付録まとめ：一般論を「あなたの現場で使える形」に落とす

ここまでの注意点は一般論ですが、実際には「どの言語で」「どのライブラリで」「どの境界（VPN/K8s/閉域）で」運用しているかで、最適なログ設計・切り分け設計が変わります。具体的な案件・契約・システム構成の制約を踏まえて、最短で“収束”させたい場合は、株式会社情報工学研究所への相談・依頼をご検討ください。

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983　電話番号：0120-838-831

　

なるほどと思える帰結：ネットワークは“ケーブル”ではなく“前提条件の集合”—監視・runbook・自動復旧で再発を潰す

ENONET(64) を追いかけていると、最後はだいたい同じ結論にたどり着きます。ネットワークは「線がつながっているか」ではなく、“前提条件が揃っているか”で成立している、ということです。

前提条件とは、ここまで扱ってきたもの――名前空間、IF状態、経路、名前解決――そして、それらを動かす運用（変更・再起動・自動化・権限分界）です。

---

ENONETが“再発”しやすいチームの共通点

これは個社批判ではなく、構造として起きがちな話です。ENONETが長引く現場は、次の条件を抱えやすいです。

• システムがレガシーで、止められない（検証が本番寄りになりがち）
• 境界が多い（VPN、拠点間、閉域、コンテナ、K8s、複数経路）
• 変更が多いのに、変更履歴と観測点が揃っていない（「いつ何が変わったか」が追えない）
• 責任分界が曖昧（アプリ／インフラ／ネットワーク／運用の“間”で詰まる）

こういう条件のとき、障害は“技術”だけでなく“説明”でも詰まります。だからこそ、再発防止は「機能追加」より場を整える方向が効きます。

---

再発防止は「観測できる前提条件」を作ること

ENONET対策で強いのは、次の3点を“毎回取れる形”にすることです。

狙い	具体策（例）	得られる効果
前提条件のスナップショット化	ip addr / ip route / ip rule / resolv.conf / ss の定期採取（差分ログ化）	「いつ崩れたか」が追える（説明が速い）
runbook（切り分け手順）の固定	本記事のsec04〜sec09の手順を、環境固有のコマンドに落として文書化	属人性を下げ、収束が速くなる
変更と復旧の“安全弁”	変更前後の状態採取、段階的ロールバック、影響範囲の限定	被害最小化・軟着陸がしやすい

---

“自動復旧”を入れるなら、先に「誤復旧」を防ぐ

自動復旧（再起動・再接続・再解決）は強力ですが、乱暴に入れるとログが埋まり、原因が隠れます。おすすめは「条件付き・段階的」です。

• まずは観測（採取）を優先し、失敗の瞬間を残す
• リトライは回数・間隔を制御し、無限ループにしない（ストッパーを置く）
• 復旧アクションの前後で、状態（ip/route/DNS/ss）を自動記録する

これだけで、障害対応は「泥沼」から「手順化」に寄っていきます。

---

一般論の限界：ここから先は“あなたの構成”が答えを決める

ここまでの話は、ENONETを技術的に整理するための一般論です。ただ、実務では次の要因で答えが変わります。

• 閉域/VPN/拠点間などの境界設計（どの経路を正とするか）
• Kubernetes/CNI/NetworkPolicy の実装差（どこが状態を作るか）
• 監査・SLA・変更手順（何を“やってよい”か、いつやれるか）
• 既存システムの制約（止められない、変更できない、触れる範囲が限られる）

つまり、最後は「この構成・この契約・この運用」で、どの選択が安全かを決める必要があります。そこまで含めて“収束”させたいときは、第三者の視点が効きます。

次の一歩：困ったときに、相談先を1つ持っておく

ENONETは、原因が1つとは限らず、境界が増えるほど説明が難しくなります。もし「今の状況を整理して、最短で収束させたい」「顧客・社内への説明も含めて整えたい」と感じたら、株式会社情報工学研究所への相談・依頼を検討してください。

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983　電話番号：0120-838-831

“作業を増やす提案”ではなく、“必要な観測点を揃えて、収束させるための道筋”から一緒に組み立てます。

　

付録：現在のプログラム言語各種での注意点—ENONETを「握りつぶさず」「誤診しない」ために

ENONET(64) はLinuxカーネルが返す errno の一つで、ユーザー空間では「例外」や「エラーコード」として見えます。ただし、言語やライブラリによって見え方が違い、メッセージはロケールや実装差で変わります。重要なのは、“文字列”ではなく“元のOSエラー（errno/OS error code）”をログに残すことです。

---

C / C++（POSIXソケット）

• 失敗したsyscall（connect/sendto等）直後に errno を必ず採取する（別の呼び出しで上書きされる）。
• ログには「宛先IP/ポート」「送信元IF/送信元IP（分かる範囲で）」「タイムスタンプ」をセットで残す。
• 非同期I/Oや別スレッドでエラーを処理する場合、errnoの扱いを誤ると誤診につながる（スレッドローカルである点は理解していても、ログ集約で混線しがち）。

Go（netパッケージ）

• net.Dial等のエラーはラップされるため、ログでは errors.As で net.OpError / os.SyscallError / syscall.Errno を辿れる形にしておく。
• 「DNS解決で詰まっているのか」「接続で詰まっているのか」を分けるため、解決段階と接続段階のログを分離する。
• タイムアウトは必ず明示する（デフォルト任せは環境差が出る）。

Java（JVM言語含む）

• 例外（SocketException等）の メッセージ文字列に依存しない。環境やJRE差で表現が変わる。
• 名前解決（InetAddress）のキャッシュ挙動が問題の切り分けを難しくすることがあるため、DNS起因が疑わしい場合は「どの時点で名前を引いたか」をログに残す。
• 接続・読み書きのタイムアウト設定を明示し、どの段階で失敗したか（resolve/connect/read）を分けて記録する。

Python（socket / requests など）

• OSError系例外では、e.errno（または e.args）からOSエラー番号を確実に採取する。
• requests等の高レベルライブラリは例外がラップされるため、根の例外（__cause__ / __context__）を辿ってerrnoを残す設計が安全。
• リトライ実装は無限化しやすいので、回数上限・間隔・サーキットブレーカー的な抑え込み（ブレーキ）を入れる。

Node.js（JavaScript / TypeScript）

• ネットワークエラーは libuv 経由のコード（err.code など）で見える。ログには code と宛先、発生フェーズ（DNS/接続/送信）を必ず残す。
• DNSまわりは非同期で見え方が変わるため、「解決に失敗したのか」「解決後の接続で失敗したのか」を分けて扱う。
• 再接続ループが暴走するとログと負荷が増えるため、間隔制御と上限（ストッパー）を必須にする。

Ruby

• Errno::ENONET のように例外クラスとして見えることがある。文字列より 例外クラス と宛先情報を記録する。
• ライブラリが握りつぶすケースがあるため、例外チェーンや戻り値仕様を把握し、根の例外が残るようにする。

Rust

• std::io::Error は ErrorKind だけでなく、raw_os_error() を必ずログに残す（OS依存の差分を保持できる）。
• 非同期ランタイム利用時は、どのタスク/どの宛先で失敗したか（コンテキスト）をログに含める。

PHP

• stream_socket_client 等は警告やfalse戻りになることがあり、エラー原因がログに残らない実装になりやすい。必ずエラー番号・エラーメッセージを取得し、宛先とセットで保存する。
• FPM/ワーカー環境では、同時多発時にログが混線しやすいので、リクエストID等の相関キーを入れる。

C#（.NET）

• SocketException のエラーコードやSocketErrorで分類できるが、OS側のエラーとの差分が出ることがある。ログにはコードと宛先に加え、失敗フェーズ（名前解決/接続/送信）を残す。
• バックグラウンド再接続はスパイクを起こしやすいので、指数バックオフ等で温度を下げる。

---

言語を問わず共通の「事故を減らす」実装ポイント

• ログは「エラー文字列」よりOSエラー番号と失敗フェーズを残す（resolve/connect/send）。
• 宛先（FQDN/IP/Port）と、可能なら送信元（src/IF）も残す。可能であれば障害時に ip route get の結果を採取する。
• リトライは“正義”ではない。上限・間隔・停止条件を設計し、暴走を防ぐ（被害最小化）。
• コンテナ/K8sでは「ホストで通る」は根拠になりにくい。必ず同じnetnsで採取する。

付録まとめ：一般論を「あなたの現場で使える形」に落とす

ここまでの注意点は一般論ですが、実際には「どの言語で」「どのライブラリで」「どの境界（VPN/K8s/閉域）で」運用しているかで、最適なログ設計・切り分け設計が変わります。具体的な案件・契約・システム構成の制約を踏まえて、最短で“収束”させたい場合は、株式会社情報工学研究所への相談・依頼をご検討ください。

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983　電話番号：0120-838-831