アプローチの比較：systemd-networkd vs. ifupdown vs. Netplan
Linuxのネットワーク設定は、長年にわたり断片化された状態が続いてきました。ディストリビューションごとに異なるツールが採用され、IPアドレスの割り当て、ルーティングテーブルの構成、仮想インターフェースのセットアップといった、まったく同じ基本的なタスクに対して競合する手法が乱立していました。
歴史的に、Debian環境では/etc/network/interfaces経由でifupdownが使われてきました。シンプルではあるものの、シェルスクリプトへの依存度が極めて高く、NICのホットプラグや動的なリンク状態の変化、systemdネイティブのサービス順序制御への追従に難を抱えています。
CanonicalはUbuntu向けにNetplanを開発し、/etc/netplan/内のすっきりとしたYAMLファイルで設定を一元化できるようにしました。しかし、Netplanはあくまで設定ジェネレーターであり、ネットワークデーモンそのものではありません。問題が発生した際には、YAMLのインデントミスと、/run/systemd/network/配下に生成されたバックエンドファイルの両方をデバッグする羽目になります。
NetworkManagerは、ワークステーションやノートPC向けの標準的な選択肢であり続けています。不安定なWi-Fiのハンドオフ、モバイルブロードバンドモデム、VPNなどを手軽に処理できます。しかし、ヘッドレスサーバーや最小構成のコンテナにおいては、D-Busデーモンや約30 MBのメモリフットプリントが、不要なオーバーヘッドとなってしまいます。
systemd-networkdは、それらの余分なレイヤーを排除します。systemdツリーの内部に直接統合されており、/etc/systemd/network/内の宣言的な.netdevおよび.networkユニットファイルを使用します。ラッパーや中間のYAMLパーサーを介さず、Linuxカーネルのrtnetlinkサブシステムを直接制御するため、わずか4〜8 MB程度の極めて小さなメモリ使用量で動作します。
systemd-networkdのメリット・デメリット
systemd-networkdへ直接移行することで、挙動の予測がしやすく軽量なスタックを手に入れることができます。ただし、本番環境での一般的な制約と強みを天秤にかけて検討することが大切です。
メリット
- 追加パッケージ不要：ディストリビューションがsystemdで起動していれば、networkdはすでにディスク上に存在します。Pythonランタイムや外部のヘルパーツールは必要ありません。
- 圧倒的な起動速度：初期ユーザー空間（early userspace）でデーモンが起動します。複数のインターフェースを非同期かつ並列に設定するため、システムの起動時間を1.5〜3秒ほど短縮できるケースが珍しくありません。
- 統一されたINI構文：ネットワークユニットは、
.service、.mount、.timerなどの各ユニットと完全に同じフォーマットを採用しています。 - ネイティブな仮想デバイスサポート：ブリッジ、VLANトランク、ボンディングペア（LACP）、WireGuardトンネルの設定を、数行のシンプルな宣言で記述できます。
デメリット
- Wi-Fiの手動管理が必要：デーモン単体ではWPA-PSKや802.1Xのネゴシエーションに対応していません。
iwdやwpa_supplicantと組み合わせる必要があります。 - 対話型のCUIツールがない：NetworkManagerの
nmtuiに相当する機能がありません。設定ファイルは手動で記述する必要があります。 - デスクトップトレイとの非連動：標準的なデスクトップアプレット（GNOME Control Centerなど）は、リンク状態の取得をNetworkManagerのD-Bus APIに依存しています。
推奨アーキテクチャ：3種類の設定ユニットファイル
永続的なネットワーク設定は、すべて/etc/systemd/network/内に配置します。デーモンはファイルを厳密な辞書順でパースします（例えば、10-eth0.networkは99-default.networkよりも優先されます）。
保守性の高い構成を実現するには、主に以下の3つのファイルタイプを使い分けます：
.link：物理ハードウェアのプロパティと照合し、インターフェースが起動する前にMACアドレス、インターフェース名、MTUなどを調整します。.netdev：ソフトウェアブリッジ（br0）、VLAN（vlan20）、ボンディングペアなどの仮想ネットワークデバイスを作成します。.network：レイヤー3のルーティングパラメータ、固定IPアドレス、DHCPリース、DNSリゾルバーを定義します。
ステップ・バイ・ステップ実装手順
以下の手順では、インターフェースをsystemd-networkdへ移行し、静的/動的IPを設定した上で、本番環境向けのVLANおよびブリッジインターフェースを構築する流れを解説します。
ステップ1：現在のインターフェースを確認する
まずは、アクティブなインターフェース名、MACアドレス、現在のIP割り当て状況を確認します：
ip -brief link show
ip -brief address show本ガイドでは、対象となるプライマリの10GbE物理NICをens18として進めます。
リモートサーバーを操作する際の注意点：サブネットマスクの設定ミスやデフォルトゲートウェイの不備があると、即座にSSHセッションが切断されます。稼働中のネットワークユニットを変更する前に、必ずProxmox NoVNC、Hetzner Robot vKVM、AWSシリアルコンソールなどのアウトオブバンドシリアルコンソールを確保してください。
ステップ2：競合するデーモンを無効化する
同一の物理アダプターを2つのデーモンが管理すると、ルートフラッピングの原因になります。NetworkManagerが稼働している場合は、停止してマスク（mask）します：
sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
sudo systemctl mask NetworkManagerUbuntuを使用している場合は、/etc/netplan/*.yaml配下の設定を削除するか、レンダラー（renderer）をnetworkdに切り替えてNetplanの自動生成を無効化します。
次に、systemd-networkdとDNS名前解決用のsystemd-resolvedを有効化して起動します：
sudo systemctl enable --now systemd-networkd
sudo systemctl enable --now systemd-resolvedステップ3：動的IP（DHCP）を設定する
DHCPv4およびIPv6 SLAAC/DHCPv6経由でインターフェースが自動的にアドレスを取得できるように、ネットワークユニットを作成します：
sudo nano /etc/systemd/network/10-ens18-dhcp.network以下の設定を記述します：
[Match]
Name=ens18
[Network]
DHCP=yes
[DHCPv4]
RouteMetric=100
UseDNS=true新しいプロファイルを即座に読み込みます：
sudo networkctl reload
sudo networkctl reconfigure ens18ステップ4：固定IPv4とDNSを設定する
データベースやWebサーバーをホストする本番環境では、予測可能で静的なアドレスが必須です。先ほどDHCPプロファイルを作成した場合は、競合を避けるために削除またはリネームします：
sudo rm -f /etc/systemd/network/10-ens18-dhcp.network
sudo nano /etc/systemd/network/10-ens18-static.network固定IP、デフォルトルート、DNSの設定を記述します：
[Match]
Name=ens18
[Network]
Address=192.168.1.50/24
DNS=1.1.1.1 8.8.8.8
Domains=internal.lab
[Route]
Gateway=192.168.1.1
Metric=100変更を適用し、リンクの状態を確認します：
sudo networkctl reload
sudo networkctl reconfigure ens18
networkctl status ens18ステップ5：802.1Q VLANタグを設定する
単一の物理ケーブルを通して複数の分離されたネットワークセグメントをトランキングするには、2つの要素が必要です。仮想サブインターフェースを生成する.netdevユニットと、そのVLANタグを物理カードへバインドする.networkユニットです。
まず、VLAN 20を作成します：
sudo nano /etc/systemd/network/20-vlan20.netdev[NetDev]
Name=ens18.20
Kind=vlan
[VLAN]
Id=20次に、ベースとなるインターフェースens18に対してVLAN 20を転送するように通知します。/etc/systemd/network/10-ens18-static.networkを更新します：
[Match]
Name=ens18
[Network]
Address=192.168.1.50/24
DNS=1.1.1.1
VLAN=ens18.20
[Route]
Gateway=192.168.1.1
Metric=100続いて、新規作成された仮想インターフェースens18.20にIPアドレスを割り当てます：
sudo nano /etc/systemd/network/20-vlan20.network[Match]
Name=ens18.20
[Network]
Address=10.20.0.5/24systemd-networkdをリロードして仮想デバイスを作成し、アドレスを紐付けます：
sudo networkctl reload
sudo networkctl reconfigure ens18
ip -brief address show ens18.20ステップ6：ソフトウェアネットワークブリッジを構築する
KVM仮想マシンやLXCコンテナをホストする際、ゲストがホストの物理LANセグメントと直接通信できるようにソフトウェアブリッジ（br0）を構成する必要があります。
重要：ブリッジトポロジーでは、物理アダプターは純粋なパイプ（レイヤー2）として機能します。IPアドレス、ゲートウェイ、DNSは物理カードではなく、必ずブリッジデバイス自体に設定する必要があります。
まず、ブリッジデバイスbr0を作成します：
sudo nano /etc/systemd/network/05-br0.netdev[NetDev]
Name=br0
Kind=bridge次に、ens18をbr0のメンバーポートとして割り当てます。既存の10-ens18-static.networkファイルを以下のように置き換えます：
sudo nano /etc/systemd/network/10-ens18-member.network[Match]
Name=ens18
[Network]
Bridge=br0続いて、ブリッジインターフェースに対して直接固定IPのパラメータを設定します：
sudo nano /etc/systemd/network/20-br0.network[Match]
Name=br0
[Network]
Address=192.168.1.50/24
DNS=1.1.1.1 8.8.8.8
[Route]
Gateway=192.168.1.1
Metric=100ルーティングルールの重複を防ぐため、ens18に残っている不要な静的プロファイルをクリーンアップし、再設定を適用します：
sudo rm -f /etc/systemd/network/10-ens18-static.network
sudo networkctl reload
sudo systemctl restart systemd-networkd
networkctl status br0ステップ7：日常的な運用コマンド
付属のCLIユーティリティであるnetworkctlを使用すれば、日常のステータス確認や監視が簡単に行えます：
networkctl list：すべての物理および仮想インターフェースの概要、動作ステータス（routable、degraded、carrierなど）、ドライバ情報を一覧表示します。networkctl status ens18：詳細なリンク統計、MTU値、アクティブなDHCPリース、DNSサーバーなどの情報を出力します。networkctl reload：既存のリンクを切断することなく、ディスク上の変更された.networkおよび.netdevファイルを再パースします。networkctl reconfigure ens18：特定のインターフェースに対し、現在の設定プロファイルの破棄と再適用を強制します。networkctl lldp：LLDP（Link Layer Discovery Protocol）パケットを解析し、接続先スイッチのポート情報をコマンドラインから直接確認します。
これらの基本的な設定ユニットをマスターすることで、ラッパースクリプトや余分なバックグラウンドサービスに煩わされることなく、Linuxネットワークスタックを完全に制御・可視化できるようになります。
