Netplanの設定ミスでSSH接続不能に。BMCからDHCPを戻して復旧する

ネットワーク設定を変更した直後から、いつものSSHで入れなくなった。そんなとき、OSを再起動する前にできることがあります。UbuntuサーバーでIPv4アドレスを失う設定ミスを再現し、BMCのコンソールから修正して、SSHで再接続できるまでを実機で確認しました。

実機検証：2026年10月24日 ／ Ubuntu 26.04.1 LTS・Netplan 1.2 ／ ASUS ESC4000A-E12・ASMB11-iKVM

今回は、固定IPへの変更途中などで「DHCPを無効にしたのに、静的IPv4の設定もない」状態になったケースを意図的に再現しています。DHCPサーバーの故障ではなく、対象サーバー側の設定ミスが原因です。

動画で復旧の流れを見る

約4分12秒。BMCの実録映像で、設定の確認・編集・適用を紹介します。

今回の環境と、復旧に必要な条件

今回は手元にあるGPUサーバーを使いましたが、この手順にGPUは必要ありません。BMCのリモートコンソール機能、そこへ到達できる管理経路、OSコンソールのログイン資格情報が必要です。

BMCの認証とOSの認証は別です。 SSH鍵で入れるサーバーでも、コンソールからログインできるとは限りません。今回は撮影前にコンソール認証を準備し、実際にログインしてから、そのセッションを維持して検証しました。障害発生後に初めてOSへログインする手順を収録したものではありません。

変更前に、元の設定と戻る手段を確保する

今回の実験では、元の /etc/netplan を別のディレクトリへ保存しました。また、BMC操作ができなくなった場合に備えて、10分後に元の設定を復元して適用する自動復旧をサーバー側に予約しました。この予約は撮影時の予備手段で、実際の復旧には使っていません。

通常の変更作業でも、設定のバックアップと、SSH以外の管理経路を先に確認します。次はバックアップの一例です。既存のバックアップへ上書きしない保存先を選んでください。

sudo cp -a /etc/netplan /root/netplan-backup-YYYYMMDD-HHMM

以下のファイル名やNIC名は今回の実機のものです。自分のサーバーでは、ip -br link、ls /etc/netplan、sudo netplan get などで対象を確かめてから操作します。Netplanは複数の設定ファイルを統合するため、別ファイルの上書き設定にも注意します。

1. 同じ接続先の22番へ、SSHで入れなくなる

正常時は dhcp4: true でした。これを false に変更して適用すると、対象NICのIPv4アドレスがなくなりました。接続元では、通常と同じ接続先・ポートで次のエラーになりました。公開用に接続先を SERVER_IP へ置き換えています。

ssh -p 22 USER@SERVER_IP
ssh: connect to host SERVER_IP port 22: Connection timed out

タイムアウトの原因はさまざまですが、今回は直前の設定変更が手掛かりです。ポートやSSH鍵を変えるのではなく、BMCからOS側の状態を調べます。

2. BMCから、IPv4・SSHサービス・設定を確認する

このBMCでは Remote Control → Launch H5Viewer からコンソールを開けます。BMCへログインしただけでOSのシェルが使えるわけではなく、OS側にもログインが必要です。今回の確認と修正は、事前にログインしておいたBMCコンソールで実行しました。

ip -4 -br address show ens10f0
systemctl is-active ssh.service
sudo grep dhcp4 /etc/netplan/00-installer-config.yaml

IPv4を表示する最初のコマンドには出力がありません。一方、SSHサービスは active。最後のコマンドには dhcp4: false と表示されました。

今回の設定ID primary はNetplan内の名前で、OSのNIC名 ens10f0 と同じ文字列ではありません。MACアドレスでどのNICに適用されるかを確かめました。

3. NetplanのDHCP設定を元へ戻す

BMCコンソールから、対象ファイルを管理者権限で開きます。

sudo nano /etc/netplan/00-installer-config.yaml

今回修正するのは、この1行です。YAMLのインデントと、それ以外の設定を保ったまま変更します。

# 誤った設定
      dhcp4: false

# 元のDHCP構成へ戻す
      dhcp4: true

もともと固定IPを使うサーバーで、無条件にDHCPを有効にする手順ではありません。 今回は変更前がDHCPだったため true へ戻しました。固定IPの誤りなら、正しいアドレス・プレフィックス・経路などを元の構成に合わせて修正します。

nanoでは Ctrl+O → Enter で保存し、Ctrl+X で終了します。今回のKVMではキーの組み合わせが意図どおり送られない場面があったため、画面下部の LCTRL ボタンでCtrlの押下・解放を指定して保存できました。保存後にファイル内容を確認します。

4. 構文を検査し、BMCから適用する

sudo netplan generate

今回はエラーなく完了しました。構文に誤りがあれば、適用する前に修正します。ただし、generate は通信できることを保証する試験ではありません。設定を生成できることと、実際に通信できることを分けて確認します。

sudo netplan apply

復旧中の操作経路はBMCなので、OS側のネットワークを設定し直している間もコンソールを利用できました。適用後に、対象NICへIPv4アドレスが再び付いたことを確認しました。

ip -4 -br address show ens10f0

録画では接続先の値を出さずに確認するため、IPv4アドレスの行数も表示しています。

ip -4 -o address show dev ens10f0 | wc -l
1

行数が1であることだけでは、正しいアドレスを取得できたとは断定できません。実際のアドレスの照合と、次のSSH再接続まで確認しています。

5. 接続元からSSHで入り直す

ssh -p 22 USER@SERVER_IP
hostname
# h100x2
systemctl is-active ssh.service
# active

同じ接続先の22番でログインできました。設定ファイルのSHA-256も変更前と一致し、変更箇所が元に戻ったことを確認しました。自動復旧が作動した記録はなく、予約を停止しています。BMCでの修正・適用によって戻った結果です。

これは撮影時の操作記録です。一般的な復旧所要時間を保証するものではありません。

実録だけをまとめて見る

約1分22秒の無音の実録抜粋。診断、編集、保存・構文検査、適用・IPv4再取得の順です。待ち時間を省略し、MACアドレスを伏せています。ナレーション付き動画では画面上下を抜粋・拡大しています。

次の設定変更では、締め出される前に確認する

今回は netplan apply で復旧しました。今後のリモート変更では、確認の期限を設ける netplan try も選択肢です。

sudo netplan try --timeout 120

この機能は、期限内に確認しなければ設定を戻すためのものです。正常に接続できることを別の端末から確認してから確定します。公式資料にも、タイムアウトやキャンセル後は本当に元へ戻ったかを確認するよう記載があります。今回の撮影で使った10分後の自動復旧予約は別の仕組みで、このコマンドを実演したものではありません。

• 変更前：元の設定を保存し、BMCからOSへログインできることを確認する。
• 変更時：構文検査、適用、接続確認を分けて行う。
• 変更後：元のSSHセッションが残っているだけで判断せず、新しいSSH接続でも確かめる。

検証後の状態と参考資料

元のネットワーク設定を復元し、SSH接続成功、H100を2枚認識、失敗状態のsystemdサービスなしを確認しました。撮影用に設定したOSコンソールの一時パスワードは、元のロック状態へ戻しています。SSHのパスワード認証は終始無効です。OS再起動や既存のデータ領域の変更は行っていません。

• Netplan公式：YAML configuration
• Netplan公式：netplan try
• ASUS ASMB11-iKVM User Guide
• 前回の記事：USBなし・現地作業なしでUbuntuを再インストール

意図的な設定ミスの実機検証です。すべてのSSH障害やDHCP障害を扱うものではありません。BMC操作は実録、接続元のSSH表示は実測ログからの再構成です。接続先のIP・認証情報は公開素材に含めていません。ナレーションはOpenAIのAI音声「Marin」です。