ifupdownからNetplanへの本番ネットワーク設定移行｜段階検証と切り戻し手順

ifupdownとNetplanの位置づけ（2026年現在）

ifupdownは長年Debianおよびその派生ディストリビューションで使われてきたネットワーク設定ツールです。/etc/network/interfacesに設定を記述し、ifup/ifdownコマンドで制御する方式は、シンプルで見通しが良いという利点がありました。しかしUbuntu 18.04 LTSからはNetplanが標準の設定フロントエンドとして採用され、Ubuntu 20.04・22.04・24.04とLTSを経るたびにNetplanへの統一が進んでいます。

Netplanの役割はYAML形式の設定ファイルを受け取り、バックエンド（systemd-networkdまたはNetworkManager）向けの設定を自動生成して渡すことです。設定の実体はバックエンドが担うため、Netplan自体はあくまで「抽象レイヤー」です。2026年現在、Ubuntu 24.04 LTSではifupdownはデフォルトでインストールされておらず、Netplanとsystemd-networkdの組み合わせがサーバー環境の標準となっています。Debian 12（Bookworm）でもNetplanパッケージは利用可能ですが、ifupdownが引き続きデフォルトであるため、ディストリビューションごとの差異に注意が必要です。

移行前の準備と確認事項

本番環境で作業を行う前に、現状の設定と依存関係を正確に把握することが不可欠です。以下の確認を順番に実施してください。

現在の設定をバックアップする

作業開始前に/etc/network/interfacesと関連ファイルをまとめてバックアップします。

sudo cp -a /etc/network/interfaces /etc/network/interfaces.bak.$(date +%Y%m%d)
sudo cp -a /etc/network/ /root/network-backup-$(date +%Y%m%d)/

設定ファイルの退避だけでなく、現在のIPアドレス・ルーティング・DNSの状態もテキストファイルに記録しておきます。

ip addr show > /root/ip-addr-before.txt
ip route show > /root/ip-route-before.txt
cat /etc/resolv.conf >> /root/ip-addr-before.txt

インターフェース名の確認

ifupdownの設定ではeth0のような旧来の名前が使われているケースがあります。一方、systemd-networkd環境ではenp3s0やens3のような予測可能なデバイス名（Predictable Network Interface Names）が使われます。ip link showでカーネルが認識している現在の名前を確認し、設定ファイルと突き合わせてください。

名前が異なる場合、Netplan側の設定でMACアドレスによるマッチングを使うことで確実に対応できます。

Netplanパッケージのインストール確認

apt-get install -y netplan.io
systemctl enable systemd-networkd
systemctl enable systemd-resolved

systemd-resolvedはNetplan＋networkd構成でDNS解決を担います。/etc/resolv.confがstub-resolv.confへのシンボリックリンクになっていない場合、後述の検証ステップでDNS解決が失敗することがあるため、事前に確認しておきます。

Netplan設定ファイルの作成手順

Netplanの設定ファイルは/etc/netplan/以下に配置します。複数のYAMLファイルを置ける構造になっており、ファイル名の数値プレフィックスが小さいものが優先されます。既存のNetplan設定が残っている場合は必ず内容を確認してから作業します。

静的IPアドレスの設定（想定例）

以下は想定例です。IPアドレス・ゲートウェイ・DNSは環境に合わせて書き換えてください。

# /etc/netplan/99-migration.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      match:
        macaddress: "aa:bb:cc:dd:ee:ff"
      set-name: enp3s0
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4
      dhcp4: false

YAMLはインデントがそのまま構文の意味を持つため、スペース数のずれが設定ミスに直結します。タブ文字は使用できません。作成後にnetplan generateでバックエンド設定の生成だけを試し、エラーがないことを確認してから次のステップに進みます。

sudo netplan generate

このコマンドは設定ファイルの構文チェックと/run/systemd/network/への設定生成を行いますが、ネットワーク設定の適用はまだ行われません。

段階的な検証：netplan tryの活用

Netplanが提供するnetplan tryコマンドは、本番移行の安全弁として重要な役割を担います。このコマンドは設定を一時的に適用し、120秒（デフォルト）以内にEnterキーで確認しなければ自動的に元の設定へ戻す仕組みになっています。

sudo netplan try

物理コンソールまたはIPMI/iDRACなどのアウトオブバンド管理経路でアクセスできる状態で実行することを強く推奨します。SSH越しにnetplan tryを実行した場合、設定ミスで疎通が切れると確認操作ができなくなり、タイムアウト後に自動ロールバックが発動します。このタイムアウトによる自動復旧はハイパーバイザー上のVMでも同様に機能します。

netplan tryで設定が適用された直後に、別のターミナル（または同一セッション）で以下の確認を行います。

# IPアドレスの確認
ip addr show

# デフォルトルートの確認
ip route show

# DNS解決の確認
resolvectl status
ping -c 3 8.8.8.8
dig +short example.com

疎通・DNS解決・ルーティングの三点が確認できたら、netplan tryを実行しているターミナルでEnterを押して設定を確定します。確認できなかった場合は何もせず待つか、Ctrl+Cを押せばロールバックが発動します。

確定後はnetplan applyを改めて実行する必要はありません。netplan tryでEnterを押した時点で設定は恒久的に適用されています。

切り戻し手順：ifupdownへの復帰

netplan tryのタイムアウトによる自動ロールバックは「Netplan設定適用後」の短期復帰には有効ですが、Netplan自体をやめてifupdownに戻す必要が生じた場合は手動での切り戻しが必要です。

Netplanを無効化してifupdownを有効化する

# ifupdownのインストール（未インストールの場合）
sudo apt-get install -y ifupdown

# バックアップから設定を復元
sudo cp /etc/network/interfaces.bak.YYYYMMDD /etc/network/interfaces

# systemd-networkdを停止・無効化
sudo systemctl stop systemd-networkd
sudo systemctl disable systemd-networkd

# networking.service（ifupdown）を有効化
sudo systemctl enable networking
sudo systemctl start networking

切り戻し後は/etc/netplan/以下のYAMLファイルを削除するか、ファイル名を.yaml.disabledのように変更して無効化しておきます。削除せず放置すると、次回起動時に再度Netplanが読み込もうとしてエラーが発生する場合があります。

resolv.confの確認

Netplan＋systemd-resolved環境では/etc/resolv.confが/run/systemd/resolve/stub-resolv.confへのシンボリックリンクになっています。ifupdownに戻した後もsystemd-resolvedを継続して使うのであれば問題ありませんが、完全に撤退する場合はシンボリックリンクを削除して通常のファイルとして再作成します。

sudo rm /etc/resolv.conf
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'

2026年現在の環境差分と注意点

Netplanのバージョンアップにより、いくつかの設定項目の書き方や挙動が変わっています。移行先の環境で使用しているNetplanのバージョンをnetplan --versionで確認し、公式ドキュメントと照合することを推奨します。

Netplan 1.0以降の変化

Netplan 1.0（Ubuntu 24.04に同梱）以降では、gateway4・gateway6キーが廃止されています。旧来の設定をそのままコピーすると警告やエラーが出るため、ルートの記述は以下の形式に変更してください。

# 旧来の記述（非推奨・Netplan 1.0では廃止）
# gateway4: 192.168.1.1

# 現行の記述
routes:
  - to: default
    via: 192.168.1.1

NetworkManagerバックエンドとの使い分け

デスクトップ用途やクラウドインスタンスではrenderer: NetworkManagerを使うケースがあります。サーバー用途ではrenderer: networkdが一般的ですが、クラウドプロバイダーが提供するcloud-initの設定テンプレートではNetworkManagerを前提としている場合があります。既存のcloud-init設定と競合しないよう、/etc/cloud/cloud.cfg.d/以下の設定も確認してください。

Debian環境での注意

Debian 12（Bookworm）ではNetplanはデフォルトでインストールされておらず、ifupdownが標準のままです。Debian環境でNetplanを使う場合はnetplan.ioパッケージを手動でインストールし、networking.serviceとの競合を意識した設定変更順序が必要です。Ubuntu前提の手順をそのままDebianに適用すると、サービス管理の差異でトラブルになることがあるため注意が必要です。

ボンディング・VLANを含む複雑な構成

ifupdownでbonding・bridgeを設定していた場合、Netplanでの記述方法が異なります。bonds:・bridges:・vlans:といった専用セクションを使用します。これらの複合構成はnetplan tryのタイムアウトが短い場合に確認作業が間に合わないことがあるため、--timeoutオプションで猶予時間を延ばして作業することを検討してください。

sudo netplan try --timeout 300

移行作業全体を通じて、コンソールアクセス手段の確保・設定バックアップ・netplan tryによる段階確認の三点が安全な移行の要点となります。特に本番系のネットワーク設定変更は、メンテナンスウィンドウ内で実施し、切り戻し手順を事前にテスト環境で確認してから臨むことが重要です。