古い .ovpn プロファイルが Ubuntu 24.04 で失敗する: 削除すべき行

プロファイルはダウンロードされ、インポートされたあと、ファイルの 12 行目で Unrecognized option というメッセージとともに停止し、そこには keysize が示されています。アカウント側には何も変わっておらず、サーバーは他のクライアントを今も受け入れています。変わったのはクライアント自身です。Ubuntu 24.04 は OpenVPN 2.6 を導入しますが、書き出しは 2.4 向けに作られていました。修正は短い削除の連続で、順序が重要です。古いオプションのそれぞれが、次の行が読まれる前に解析を中断するからです。

ファイルに触る前にエラー行を読む

OpenVPN は解析が止まったファイルと行を示すので、一度の実行で直せる問題は一つだけです。プロファイルはデスクトップのアプレットではなく端末から起動してください。アプレットは通常 stderr を飲み込み、行番号が得られる唯一の確かな手がかりだからです: sudo openvpn --config /etc/openvpn/client/provider.ovpn。その行を直して再実行すれば、次の失敗は別のオプションを示します。

解析エラーは TLS ハンドシェイクより必ず前に現れるので、証明書に言及するメッセージはすでに構文の段階を通過しています。この区別があれば、認証だけで失敗しているファイルを編集せずに済みます。メッセージの中央ではなく最初の語を読んでください。

失敗は三つのクラス、修正も三通り

古い書き出しは三つの区別できる仕方で失敗し、それを一つの問題にまとめてしまうからこそ、決して壊れていないパッケージを再インストールする人が出ます。メッセージの言い回しは、ファイルを開く前にどのクラスかを教えてくれます。

• 解析エラーはファイルと行を示し、通信が存在する前に停止します。
• ネゴシエーションのエラーは接続したあと、両端が共通の暗号や受け入れ可能なデータチャネルで合意できなかったと報告します。
• 認証のエラーは最も遠くまで進み、証明書、ユーザー、または拒否された資格情報を示します。

プロファイルの編集で直るのは最初のクラスだけです。ネゴシエーションはトンネルの両端での判断を必要とし、拒否された資格情報は構文の問題ではありません。メッセージに共通の暗号やデータチャネルが出てくるなら、以下の削除は何も変えません。

2.6 が削除したオプションを、この順で消す

これらの行はそれぞれ単独で解析を止めるため、クライアントは一つずつ報告します。リストを下へたどり、削除のたびに再実行してください。

まず keysize を削除します。現代的な代替がなく、その存在は現在のクライアントがどのみち拒否する暗号を示すことが多いからです。次に、暗号のネゴシエーションを制御していましたが 2.5 で非推奨になり 2.6 では存在しない ncp-disable を削除します。ns-cert-type server を remote-cert-tls server に置き換えます。同じ意図をサポートされた検査で表すものです。2.6 の変更履歴は残りの削除を置き換えと並べて示すので、パーサーがまだ拒否するものには文書化された答えがあります。

最初の編集の前に元のプロファイルの複製を取ってください。プロバイダーは書き出しを作り直しますし、手を付けていないファイルとの diff が、自分の変更と相手の変更を分ける最短の方法です。削除によってクライアントは起動してもトンネルがまだ失敗するなら、ネゴシエーションのクラスに移っています。残りの行は原因ではありません。クライアントの版をファイル名に入れておけば、次に触る人がどのリリース向けの編集か分かります。

BF-CBC は限定的なフォールバックとしてだけ動かす

一部のプロバイダーは今も BF-CBC で終端しており、OpenVPN 2.6 は助けなしではこれをネゴシエーションしません。暗号のブロックが 64 ビットだからです。狭い修正はフォールバック一覧と古い OpenSSL プロバイダーであり、クライアント全体を下げることではありません。

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

最初の行は古いプロバイダーを読み込み、OpenSSL がその暗号を今も生成できるようにします。二番目の行は対応する相手のために現代的なネゴシエーションを保ち、三番目の行はサーバーがより良いものを提示しないときだけ適用されます。これは意図的なトンネルの弱体化なので、なぜ存在するのかをファイルのそばに記録してください。フォールバックは目的地ではなく橋なので、同時にプロバイダーへ書き出しの再生成も依頼しましょう。

--compat-mode を万能の答えとして頼らないでください。これは複数の挙動を一度に変え、ネゴシエーションと再ネゴシエーションの既定値も含むため、どの変更が効いたのか分からなくなります。上の三行を明示的に選ぶほうがよく、それぞれが自分の効果を述べています。

クライアントが実際に読み込むプロファイルで確認する

インポートされた接続はシステムのディレクトリにコピーされることが多く、ダウンロード先のファイルを編集しても何も変わらない場合があります。実行されている複製を探してください: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn。そのうえでトンネルを起動し、実際に選ばれたデータチャネルの暗号を報告するログ行を読みます。フォールバックでハンドシェイクが完了する接続は、サーバーが現代的なものを一度も提示しなかったことを示します。

プロバイダーが想定するネットワークとは違う回線で試してください。キャプティブポータルやフィルタされたゲスト網がプロファイルの不具合に見えてしまうからです。サポート依頼にはクライアントの版を添えてください。

トンネルが上がったら、必ず通るべき要求と通ってはいけない要求を一つずつ送り、リゾルバーの応答が期待どおりに変わったことを確認します。プロファイルが解析できるようになっても接続が失敗するなら、構文の問題は置き去りにされており、エラー文は新しいクラスを示します。編集したファイルは、対象とする OpenVPN のリリースを記したメモとともに版管理に置いてください。