消えた /etc/network/interfaces の謎
Debianや古いバージョンのUbuntuを管理して育った人にとって、サーバーの応答がなくなると、体が覚えている操作で真っ先に /etc/network/interfaces を開こうとするでしょう。そこには eth0 や ens33 の見慣れた設定リストがあるはずです。しかし、Ubuntu Server 22.04や24.04 LTSなどのモダンなエディションでは、そのファイルを開いても空だったり、別の場所を見るように促すコメントが1行あるだけだったりします。
この変化は、当初多くのシステム管理者に頭痛の種をもたらしました。かつて私が20台のWebノードをデプロイした際、レガシーな設定編集が再起動のたびに消えてしまう理由を突き止めるのに30分も費やしたことがあります。実質的に、自分のリモートインスタンスから締め出されてしまったのです。これはバグではなく、Linuxネットワーク抽象化レイヤーの完全な刷新によるものでした。
なぜUbuntuはNetplanに切り替えたのか
Canonicalは、ハイレベルなトランスレーター（翻訳役）として機能させるために Netplan を導入しました。systemd-networkd や NetworkManager のための複雑で低レベルなスクリプトを書く代わりに、単一のYAMLファイルに設定の意図を定義するようになりました。Netplanはこのファイルを読み取り、バックエンドに応じた具体的な設定ファイルを生成します。
Ubuntu Serverは通常、デフォルトのレンダラーとして systemd-networkd を使用しますが、Desktop版は NetworkManager を使用する傾向があります。この統一された構文は強力ですが、正確さが求められます。YAMLは空白（スペース）に非常にうるさいことで知られています。2つのスペースの代わりにタブ文字を1つ使っただけで、ネットワークスタック全体が読み込まれなくなってしまいます。
設定ファイルの場所
ネットワーク定義は /etc/netplan/ に保存されています。通常、01-netcfg.yaml や 50-cloud-init.yaml といった名前のファイルが見つかります。ファイル名の先頭にある数字は、複数のファイルがある場合の読み込み順序を決定するものです。
設定を変更する前に、ハードウェアの論理名を確認しましょう。カーネルが認識している名前を確認するには、ip link コマンドを実行します。
ip link showenp0s3 や ens18 といった識別子を探してください。YAMLファイルではこれらの文字列を正確に使用する必要があります。そうでないと、設定をハードウェアに紐付けることができません。
基本的なDHCP設定
DHCPがIP割り当てを行う標準的なラボ環境やパブリッククラウドのVPC内であれば、設定は非常にシンプルです。標準的なDHCP設定は以下のようになります。
network:
version: 2
renderer: networkd
ethernets:
enp0s3:
dhcp4: trueこの階層構造では、network がルートであり、version: 2 が現在の標準です。各レベルは正確に2つのスペースでインデントする必要があります。タブは使用しないでください。使用するとNetplanが構文エラーを返します。
静的IPアドレスの設定（モダンな方法）
本番環境のサーバーでは、ほぼ常に静的IPが必要です。データベースクラスターの運用でもWebプロキシの構築でも、内部ルーティングにおいてIPの永続性は不可欠です。私はこれまで何百もの本番環境デプロイメントで、以下のテンプレートを問題なく使用してきました。
以下は、Ubuntu 22.04および24.04で検証済みの静的IP設定です。
network:
version: 2
renderer: networkd
ethernets:
enp0s3:
addresses:
- 10.0.0.50/24
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
routes:
- to: default
via: 10.0.0.1重要な構文の変更点:
- addresses: CIDR表記が必要です。標準的な255.255.255.0のサブネットマスクには
/24を使用します。 - nameservers: ブラケット内にコンマ区切りで複数のDNSプロバイダーをリストできます。
- routes: 古い
gateway4キーは正式に非推奨となりました。モダンなNetplanでは、routesブロックを使用してゲートウェイIPへのdefaultパスを定義します。
「セーフティネット」コマンド
SSH経由でネットワーク設定を変更するのは、自分自身を手術するようなものです。タイポ（打ち間違い）ひとつでサーバーから切り離され、データセンターまで足を運ぶか、シリアルコンソールでのログインを余儀なくされます。Netplanは「try」機能でこの問題を解決します。
設定を盲目的に適用するのではなく、必ずこのコマンドを実行してください：
sudo netplan tryこのコマンドは設定を適用しますが、120秒のカウントダウンを開始します。Enterキーを押して確定しない限り、Netplanは接続が失われたと判断し、自動的に以前の動作していた設定にロールバックします。これはリモート管理者にとって最も重要なツールです。
インデントとロジックのトラブルシューティング
netplan apply が失敗する場合、原因のほとんどはフォーマットエラーです。YAMLはタブをサポートしていないため、テキストエディタがスペースを挿入するように設定されているか確認してください。「Invalid YAML」エラーが表示された場合は、カラム（列）の位置を再確認しましょう。
内部で何が起きているかを確認するには、デバッグフラグを使用します：
sudo netplan --debug applyこの出力により、NetplanがYAMLを /run/systemd/network/ にある実際のファイルにどのように変換しているかがわかります。YAMLが有効なのにIPが表示されない場合、デバッグログを見れば、バックエンドのデーモンがパラメータを拒否しているかどうかが判断できます。
複数インターフェースの処理
モダンなサーバーでは、パブリックなインターネット通信とプライベートなバックエンドネットワークでトラフィックを分けることがよくあります。Netplanでは、ethernets キーの下にセカンダリエントリを追加することでこれを管理します：
network:
version: 2
renderer: networkd
ethernets:
enp0s3:
dhcp4: true
enp0s8:
addresses:
- 192.168.10.15/24このシナリオでは、enp0s3 がインターネットアクセスのために動的IPを取得します。一方で、enp0s8 はローカルのデータベース通信のために静的なプライベートIPに固定されます。enp0s8 にはゲートウェイがないため、システムはすべての外部トラフィックを最初のインターフェースのDHCPから提供されたゲートウェイ経由で正しくルーティングします。
まとめ
Netplanへの移行は、古い方法に慣れている人には手間に感じるかもしれませんが、Linuxのネットワーク管理に待望の構造化をもたらしました。ネットワークを宣言的なYAMLファイルとして扱う手法は、モダンな「Infrastructure as Code」のワークフローに完璧に適合します。スペースの一貫性を保つこと、そして不慮の締め出しを避けるために必ず netplan try を使用することを忘れないでください。
