fips-updates を有効にして再起動すると、マシンは無線インターフェースなしで戻り、VPN クライアントはカーネルモジュールが無いため起動を拒否します。通常のパッケージの意味では何も削除されておらず、だからクライアントを再インストールしても何も変わりません。マシンは、そのドライバーが一度もビルドされたことのないカーネルで動いているのです。症状は二つ、原因は一つ、そして原因は一つのコマンドで見えます。

再起動が実際に切り替えたもの

Ubuntu Pro の FIPS 更新は認定されたカーネルの変種を導入し、それを既定の起動エントリにします。その変種は本物のカーネルです。起動し、動作し、すでにあったサービスを開始します。そこに含まれないのは汎用カーネル向けにビルドされたすべてのモジュールで、ツリー外でコンパイルされた無線ドライバーや、DKMS 経由で提供されるトンネルモジュールも含まれます。ドライバー群はパッケージマネージャーではなくカーネルとともに動きます。だからハードウェアはそこにあり、それを話すソフトウェアは無いのです。

ネットワーク設定を開く前に、動作中のカーネルとインストール済みパッケージを比べてください。バージョン文字列には汎用カーネルには無い印が付いており、その一点が欠けた二つの部品の両方を説明します。

起動エントリも読んでください。認定カーネルがインストールされていても、それが動いていない場合があるからです。その場合モジュールの話はまったく別で、再インストールしようとしていたポートやドライバーは問題ありません。

クライアント設定より先にモジュールの状態を読む

見つからないモジュールと、存在するが読み込みを拒否するモジュールは、別の障害であり別の対処です。modinfo はどちらかを示し、lsmod は今なにが読み込まれているかを示します。VPN クライアントの設定に触る前に両方を行ってください。クライアント自身のエラーは両者をほとんど区別しないからです。

無線側も同じ切り分けが要ります。決して現れないインターフェースはドライバーを指し、存在するがブロックされたままのものは rfkill かネットワークマネージャーを指します。デスクトップのアプレットでは同じに見えますが、中身は何も共有していません。

障害がまだ再現するうちに、マシン自身で検査を実行してください。別のホストから貼り付けた出力では代わりになりません。

uname -r
pro status --all | grep -E 'fips|kernel'
modinfo wireguard 2>&1 | head -3
rfkill list

modinfo がモジュールをまったく見つけられないなら、ユーザー空間のパッケージを再インストールしても無駄です。ユーザー空間が欠けていた部分ではなかったからです。この観察で一時間のパッケージ作業が省け、カーネルへ一直線に進めます。

カーネルを残す順序で戻す

FIPS を誤って有効にした場合、文書化された復旧手順はサービスを無効にし、そのパッケージを削除し、そのあと汎用カーネルを戻します。この順序は飾りではありません。削除処理は別の Ubuntu カーネルを見つけられないと続行を拒否します。唯一のものを消せば起動できないマシンが残るからです。その検査がロールバックと作り直しの違いです。汎用カーネルがすでに削除されているとこの手順が失敗するのも、同じ理由です。

汎用カーネルがまだインストールされているうちに実行し、カーネルを削除するという警告を受け入れ、そのあと再起動します。続いて、インストール済み状態の FIPS パッケージが残っていないこと、動作中のカーネルが期待したものであることを確認します。

遠隔ホストなら、先にコンソールか帯域外のアクセスを用意します。SSH 越しのカーネル削除は、戻ってこない再起動の直前までは問題ありません。

dpkg -l | grep -E 'linux-image|fips'
sudo pro disable fips-updates --purge
sudo apt install --reinstall linux-generic
sudo reboot

認定が要件である場合

認定が契約上のものなら、戻すのは間違った一手です。マシンが監査の示す構成から外れてしまうからです。その場合ドライバーの欠落はハードウェア選定の問題です。ドライバーが認定カーネルに同梱される無線アダプターを選ぶ、有線のみのマシンを受け入れる、またはトンネルを認定カーネルがすでに支える構成要素へ移してください。

ツリー外のモジュールを認定カーネルに組み込むのは中立な回避策ではありません。カーネルが実行する内容を変えてしまい、それこそが認定の示す性質です。

決定は所有者の名前とともに記録してください。Wi-Fi だけ動くようにしてほしいという依頼は、数か月後に文脈を失って戻ってきます。今の短いメモが、後での同じ議論を防ぎます。

変更後はスタックを層ごとに確認する

ロールバックやハードウェア変更のあとは、VPN クライアントから下へではなく、下から上へ確認します。インターフェースがあり、リンクが上がり、リゾルバーが動き、そのうえで初めてトンネルが意味を持ちます。各層はそれぞれのメッセージで失敗し、順に読めば診断は誠実なままです。

前回の起動から残った DNS の状態はよくある誤検知です。トンネルが壊れたと結論する前にリゾルバーを読んでください。

nmcli device status
ip -brief link
resolvectl status | head -12
systemctl --failed

カーネルが戻ってもトンネルが失敗するなら、クライアントの要約行ではなく失敗している段階を読んでください。読み込まれなかったモジュール、相手が拒否した証明書、サーバーが拒否した資格情報は三つの別問題で、再起動が代わりに区別してくれることはありません。段階の名前をチケットに残せば、次の担当者はあなたが止まったところから始められます。

関連記事