本事象は、ユーザーセッション側の自動起動設定を整理する過程で systemctl –user enable を用いた設定変更を行った直後に発生した。作業内容自体は入力メソッドの自動起動に関するもので、ネットワーク設定を変更した意図はなかったが、その後の再起動を契機に当該ホストのみネットワーク疎通が失われ、「IP アドレスは取得できているのに、LAN の外へ出られない」「ゲートウェイへ ping が通らない」「他ホストからもこのホストに到達できない」という状態になった。調査の結果、このタイプの障害は DNS ではなく、より下の層 (L2/L3) が壊れている場合に典型的に現れることが分かり、さらに確認を進めると、Debian 系の GNOME / Xfce4 環境で標準的に使用される NetworkManager に加え、何らかの契機で systemd-networkd が同時に有効化され、同一 NIC を二重に管理したことで近傍解決 (ARP) が崩れ、直感に反する「IP はあるのに孤立する」状態が発生していた。本稿は、このように一見ネットワークと無関係な設定変更をトリガーとして発生した障害を例に、問題提起から切り分け、暫定対応、恒久対応、運用設計までを再現可能な手順として整理する。[1][2][3]
問題提起
ネットワーク障害の多くは「IP が付かない」「DNS が引けない」など分かりやすい形で表面化する。しかし次のような状態は混乱しやすい。
- ホストは IP アドレスを保持している (例: DHCP で割り当て済み)。
- それでもゲートウェイ (以後 <GW_IP> と表記) に到達できない。
- 同一 LAN 内の別ホストからも当該ホスト (<HOST_IP>) に到達できない。
- 自ホスト宛の ping は通る (自己スタックは動作)。
この場合、「IP が見える」ことに引っ張られて DNS やアプリ層を疑いがちだが、実際は L2 (ARP) または L3 (ルーティング) が壊れていることが多い。特に「ゲートウェイに届かない」「他ホストからも届かない」は、当該ホストが LAN から孤立しているシグナルである。[4][5]
前提と用語
本稿は Debian 系の GNOME / Xfce4 ホストを想定する。GUI を導入すると NetworkManager が導入・有効化されやすい。[1] 一方で systemd-networkd は systemd が提供する別系統のネットワーク管理機構であり、/etc/systemd/network/ の設定に従って NIC を設定する。[2][6]
本稿では具体的な数値を伏せるため、次のプレースホルダーを使う。
- <HOST_IP>: 当該ホストの IPv4 アドレス
- <GW_IP>: デフォルトゲートウェイの IPv4 アドレス
- <IFACE>: 対象インタフェース名 (例: enpXsY, wlpXsY)
トリガー: なぜ「関係ない操作」の後に起きるのか
今回の根は「ネットワーク管理の競合」だが、トリガーは一見ネットワークと無関係なことがある。例えば user unit (systemctl –user) の追加・有効化、既存 unit の enable/disable、設定ファイルの整理などを行った直後に発生することがある。ここで重要なのは、systemd の世界では unit の依存関係・起動条件・ソケット起動などにより「どの経路でサービスが起動するか」が増える点である。disable は自動起動を外すだけで、依存関係や手動起動の経路は残り得る。一方 mask は unit を起動不能にするため、意図しない経路を物理的に遮断できる。[3][7][8]
つまり「unit を少し触った」ことが直接ネットワークを壊したのではなく、その過程で systemd-networkd が有効化 (あるいはソケット起動可能状態) になり、NetworkManager と同じ NIC を触り始めたことが真のトリガーになり得る。二重管理の入り口は、systemd-networkd 自体だけでなく systemd-networkd.socket も含む。[6]
なぜこの現象が起きるのか
ネットワークは「1 つの NIC を誰が設定するか」を前提に整合性が保たれる。NetworkManager は接続プロファイルに従って IP/ルート/DNS/リンク状態などを管理し、nmcli で状態確認や再接続ができる。[9][10] systemd-networkd は .network ファイル等に従って同様の領域を管理する。[2][5]
同じ NIC を 2 つの管理者が同時に触ると、例えば次が競合し得る。
- IP アドレスの付与・削除
- デフォルトルートの設定
- リンクの再初期化 (down/up)
- 近傍 (ARP) の状態遷移
この競合がやっかいなのは、DHCP 自体は片方が成功して「IP は付いている」ように見える一方で、ARP が崩れるとゲートウェイの MAC を解決できず、結果として LAN 内通信が成立しない点にある。観測点として ip neigh が有効で、ゲートウェイが INCOMPLETE/FAILED になりやすい。[11][12]
切り分け: まず何を見ればよいか
ここからは「観測→仮説→検証」を固定手順にする。闇雲な再起動や設定変更は再現性を下げるため、まず観測値を揃える。
1) インタフェースと IP
リンク状態とアドレスの有無を確認する。ここで IP が付いていないなら、別の障害 (DHCP 不達など) を疑う。
1 2 | ip -br link ip -br addr |
2) ルーティング
default via が無ければ「ゲートウェイへ届かない」のは当然なので、まずルートを直す必要がある。
1 | ip route |
3) 近傍 (ARP)
ゲートウェイ (<GW_IP>) が INCOMPLETE/FAILED なら L2 を強く疑う。ARP は L2 の成立条件であり、ここが崩れると「IP はあるのに孤立」が起きる。
1 | ip neigh |
4) 管理方式の競合チェック
GUI ホストで NetworkManager と systemd-networkd が同時に active なら競合を疑う。今回の事象はこの条件を満たしていた。
1 2 | systemctl is-active NetworkManager systemctl is-active systemd-networkd |
この段階で「IP はある」「default route もある」「ARP が張れない」「両方 active」が揃ったら、原因は二重管理が最有力になる。[13]
暫定対応
暫定対応の目的は、いま目の前の通信を戻すことだ。恒久対応は後段で整理する。まずは networkd 側の介入を止め、NetworkManager に単独管理させる。
1) networkd を止める (一時)
まず stop して状況が変わるかを見る。ただし stop だけでは再起動や依存関係で復帰する余地があるため、これは暫定と考える。
1 2 | sudo systemctl stop systemd-networkd sudo systemctl stop systemd-networkd.socket |
2) NetworkManager を再初期化
NetworkManager を再起動し、接続状態を確認する。
1 2 | sudo systemctl restart NetworkManager nmcli device status |
ここでゲートウェイへ到達できるようになれば、競合が原因である可能性がさらに上がる。[10]
恒久対応
恒久対応の目的は「意図しない経路で networkd が起動して競合する」可能性を消すことだ。GUI ホストで NetworkManager を採用する方針なら、systemd-networkd を mask して起動不能化するのが最も確実である。
1) /etc/systemd/network の残骸を退避
設定ファイルが残っていると、将来 networkd が何らかの理由で起動したときに再び NIC を触る。まず退避して「networkd で管理する意思がない」状態に揃える。
1 2 | sudo mkdir -p /root/networkd_backup sudo mv /etc/systemd/network/* /root/networkd_backup/ 2>/dev/null |
2) systemd-networkd を disable + mask
disable は自動起動を外すだけであり、起動経路自体は残り得る。mask は unit を起動不能化する。GUI ホストでは mask を基本にする。
1 2 3 4 | sudo systemctl disable --now systemd-networkd sudo systemctl disable --now systemd-networkd.socket sudo systemctl mask systemd-networkd sudo systemctl mask systemd-networkd.socket |
3) NetworkManager を再起動して単独管理へ戻す
1 | sudo systemctl restart NetworkManager |
4) 復旧確認
ルートが復帰し、ゲートウェイへ到達できることを確認する。
1 2 | ip route ping -c3 <GW_IP> |
それでも復旧しない場合は、NetworkManager の接続プロファイルが壊れている可能性がある。nmcli で接続を作り直すのが最短である。[10][14]
5) 接続プロファイルの作り直し (必要時のみ)
1 2 3 4 | nmcli device status sudo nmcli connection delete "Wired connection 1" 2>/dev/null sudo nmcli connection add type ethernet ifname <IFACE> con-name wired autoconnect yes sudo nmcli connection up wired |
運用設計
今回の教訓は「技術選定」ではなく「運用設計」の問題として扱うのがよい。つまり、ホストごとにネットワーク管理者を明確に決め、混在を許さない設計にする。
設計原則
- 1 インタフェースを管理する主体は 1 つにする。
- GUI ホストは NetworkManager を採用し、networkd は masked に固定する。
- 完全ヘッドレスで固定設定のサーバーのみ networkd を採用する余地があるが、その場合は NetworkManager を無効化する。
Debian のネットワーク管理ツールは複数存在するため、混在のルールを明文化しないと、変更作業の偶発で競合が復活する。[15][16]
運用チェックリスト
ネットワークと無関係に見える作業 (user unit の追加、サービス enable/disable、設定整理) の後でも、次は必ず確認する。
1 2 | systemctl is-active NetworkManager systemd-networkd systemctl is-enabled NetworkManager systemd-networkd systemd-networkd.socket |
期待値 (GUI ホスト):
- NetworkManager: active / enabled
- systemd-networkd: inactive / masked
- systemd-networkd.socket: inactive / masked
障害時の最短診断セット
同じ症状が出たら、まず以下のコマンドで「L2/L3 破綻」「二重管理」を即断する。
1 2 3 4 5 | ip -br addr ip route ip neigh systemctl is-active NetworkManager systemd-networkd nmcli device status |
参考文献
- NetworkManager — Debian Wiki. https://wiki.debian.org/NetworkManager
- systemd-networkd.service(8) — systemd — Debian manpages. https://manpages.debian.org/testing/systemd/systemd-networkd.service.8.en.html
- systemctl(1) — systemd — Debian manpages. https://manpages.debian.org/testing/systemd/systemctl.1.en.html
- ip(8) — iproute2 — Debian manpages. https://manpages.debian.org/bookworm/iproute2/ip.8.en.html
- systemd.network(5) — systemd (upstream). https://www.freedesktop.org/software/systemd/man/systemd.network.html
- systemd-networkd.socket(8) — systemd — Debian manpages. https://manpages.debian.org/testing/systemd/systemd-networkd.socket.8.en.html
- systemd.unit(5) — systemd — Debian manpages. https://manpages.debian.org/testing/systemd/systemd.unit.5.en.html
- systemd.service(5) — systemd — Debian manpages. https://manpages.debian.org/testing/systemd/systemd.service.5.en.html
- NetworkManager.conf(5) — Debian manpages. https://manpages.debian.org/testing/network-manager/NetworkManager.conf.5.en.html
- nmcli(1) — Debian manpages. https://manpages.debian.org/testing/network-manager/nmcli.1.en.html
- ip-neighbour(8) — Debian manpages. https://manpages.debian.org/testing/iproute2/ip-neighbour.8.en.html
- arp(7) — Linux man-pages. https://man7.org/linux/man-pages/man7/arp.7.html
- Debian Reference — The systemd system and service manager. https://www.debian.org/doc/manuals/debian-reference/ch06.en.html
- NetworkManager connection settings — upstream documentation. https://networkmanager.dev/docs/api/latest/nm-settings.html
- NetworkConfigurationTools — Debian Wiki. https://wiki.debian.org/NetworkConfigurationTools
- Debian Reference — Network configuration. https://www.debian.org/doc/manuals/debian-reference/ch05.en.html
- systemd documentation — systemctl (upstream). https://www.freedesktop.org/software/systemd/man/systemctl.html
- systemd documentation — systemd-networkd.service (upstream). https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html
- NetworkManager — upstream documentation. https://networkmanager.dev/docs/
- iproute2 — upstream documentation. https://wiki.linuxfoundation.org/networking/iproute2
- iputils arping(8) — Debian manpages. https://manpages.debian.org/testing/iputils-arping/arping.8.en.html
- Linux man-pages — ping(8). https://man7.org/linux/man-pages/man8/ping.8.html
- NetworkManager — Freedesktop.org wiki. https://wiki.freedesktop.org/NetworkManager/
- systemd project — Freedesktop.org wiki. https://www.freedesktop.org/wiki/Software/systemd/