Ubuntu のアップグレード後に OpenVPN が接続できなくなった理由

先週まで動いていた VPN プロファイルが Ubuntu のリリースアップグレード後に壊れ、ログはアップグレードにほとんど触れません。ログが名指しするのは失敗した層です。すなわち TLS ハンドシェイク、データチャネル用に交渉された暗号、インストールされたパッケージ、あるいは起動時にバイナリが読み込む OpenSSL のコピーです。層ごとにエラーの形と修復方法が違うため、分類が最初の作業、編集が次の作業になります。ログが名指しするまでプロファイルは無実と考えてください。

どの層が失敗したか：ハンドシェイク、暗号、パッケージ、ライブラリ

プロファイルに触る前にクライアントのログを読んでください。出力の最初のエラーが層を特定します。その後に印字されるものは、たいていこの最初の失敗の結果です。クライアントがまったく起動しない場合、VPN のログは開くべきファイルではありません。

証明書や署名に関する不満、あるいは鍵長についてのメッセージは、制御チャネルとそれを律するライブラリ方針から来ます。一方、DEPRECATED OPTIONで始まる警告はデータチャネルの交渉に属します。

この種の行はUnrecognized option第三のカテゴリです。新しいバイナリは古いものが許していた指示を受け付けないので、ライブラリを緩めるのではなくプロファイルを書き直す必要があります。パッケージの失敗はまた別に見えます。トンネルのコードが動く前に起きるからです。バイナリの欠落、読み込まれないプラグイン、誤ったコードネームを指すリポジトリは、いずれもその形になります。四つの症状、四つの確認箇所、そして修復同士の重なりはほとんどありません。

ハンドシェイクが失敗するとき、TLS 方針が証明書を拒否している

Ubuntu 22.04 はシステムを OpenSSL 3 に移し、その系列の既定のセキュリティ水準は 20.04 より証明書の署名と鍵の長さに厳しくなりました。古いダイジェストで署名された CA 証明書や、現在のしきい値を下回る鍵は、ハンドシェイクの途中で失敗します。まだ何も認証されていないため、エラーは誤ったパスワードや死んだサーバーのように読めます。

狭い修復は暗号文字列をこの接続だけに結び付けます。デスクトップのエディタでプロファイルを開き、詳細設定に移り、TLS 暗号の欄にDEFAULT:@SECLEVEL=0を入れてください。NetworkManager のキーファイルは[vpn]の下で同じ値を受け取ります。

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

NetworkManager を再起動して再接続してください。デーモンは解析済みのプロファイルをキャッシュするため、そうしないと既に持っているコピーを使い続けます。行を残す前に何をするのかを知ってください。この設定は暗号名ではなく、複数の証明書と鍵のパラメータにまたがるしきい値なので、下げると単一のプロファイルが受け入れる範囲が広がります。どのサーバーがそれを要求したかを記録し、運用者が最新の素材を再発行したら設定を外してください。/etc/ssl/openssl.cnfを変えると同じファイルを読むすべてのプログラムに同じしきい値が及ぶため、VPN のはるか外に影響します。

OpenVPN 2.6 は交渉用の暗号を一覧に必要とする

Ubuntu 22.10 は OpenVPN 2.6 を載せ、その版では--cipherがデータチャネルを独力で選ぶのをやめます。暗号は交渉されるdata-ciphersの一覧にも入っていなければならず、そうでないとクライアントは非推奨の警告を出したうえでトンネルを立ち上げられません。

同じ時期の NetworkManager プラグインは依然として古い指示しか書きませんでした。この点が診断を分けます。手で直したプロファイルはシェルからは接続でき、デスクトップのアプレットからは失敗することがあるからです。一覧を接続ファイルの[vpn]の下に加えてください。

data-ciphers=AES-256-CBC

覚えている値ではなくサーバーが告知する値を使ってください。AES-256-GCM を出すサーバーは CBC だけを挙げるクライアント一覧とは交渉しません。マネージャーを再起動して再接続し、次にシェルから暗号を交渉とフォールバックの両方に明示して試行を繰り返します。

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

そのコマンドでトンネルが立ち上がれば、サーバー、証明書、資格情報はすべて健全で、残る不具合はマネージャーの保存した項目だけです。keysize指示についての警告も同じ後片付けに属します。コメントアウトし、元のファイルをプロファイルの隣に残してください。

パッケージとプラグインの不具合は VPN の不具合に見える

アップグレード後の失敗がすべて暗号関連とは限りません。リリースが使わないコードネームの下に追加された OpenVPN リポジトリは、決してインストールされないパッケージを生みます。lsb_release -aが何を報告するかを、追加した一覧ファイルと比べてください。universeコンポーネントやセキュリティポケットが欠けていれば、まったく見つからないパッケージになります。どちらの場合もプロファイルは無傷のまま、トンネルは不可能です。

VPN のログより先にパッケージマネージャーのエラーを読んでください。クライアントが一度もインストールされていなければ、どれほどプロファイルを編集してもハンドシェイクは生まれません。

問い合わせをやめる二要素プロファイルは、同じ話のプラグイン版です。挑戦は認証プラグインから来ており、それを外したか置き換えたアップグレードは、プロファイルを無傷に保ったまま問い合わせを消します。接続を機能させるために第二要素を消すのではなく、対応するプラグインを再インストールしてください。

ベンダーのライブラリが方針エラーの背後に隠れることがある

一つの型は認識に値します。あらゆる方針の修復を無力化するからです。ハードウェアベンダーの設定ツールは独自の OpenSSL ライブラリをインストールし、ローダーの探索経路でシステムのコピーより前に置くことができます。するとクライアントは誰も更新していないライブラリに対して起動し、起動失敗は拒否された証明書とそっくりに見えます。

VPN パッケージを再インストールしても、どのライブラリが先に見つかるかは変わりませんし、TLS の水準を下げてもシステム由来でないライブラリには届きません。ローダーに、バイナリが実際に解決する暗号オブジェクトを尋ねてください。

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

ベンダーのコピーを削除するか向け直し、同じ確認をもう一度実行します。プロファイルに戻る前に、期待する版が使用中でなければなりません。

古いクライアントを固定するのは時間を買うことで、解決ではありません

前のクライアント版を保持すると、保持が続く限りトンネルは戻ります。同時にそのパッケージのセキュリティ更新を凍結し、次のアップグレードに同じ破綻を予定することになるので、解決ではなく日付付きの暫定策として扱ってください。

それでも固定するなら、無人更新が固定を解除できないようパッケージを明示的に保持し、理由と再検討の日付を書き、提供元の次のプロファイル公開に備えてリマインダーを設定します。注視すべき条件は、現行の暗号を交渉するサーバープロファイルであり、それが存在すれば固定に正当性は残りません。逆に記録のない固定は、半年後に誰も説明できない障害になります。適用した人は去り、ファイルには何も残らないからです。

次にリリースアップグレードの後で VPN が死んだら、五つの問いを順に立ててください。どの層が最初のエラーを出したか、TLS 方針が証明書を拒否したか、暗号は両方向に交渉できるか、パッケージとプラグインは実際にインストールされたか、そしてプロセスはどのライブラリを読み込むか。五つすべてが清潔に返ってきて初めて、ダウングレードに意味があります。