OpenVPN プロファイルから key-method を削除しても何も変わらない

何年も動いていたプロファイルがある日突然起動を拒否し、メッセージには誰も追加した覚えのないディレクティブの名前が出てきます。それが key-method です。次の検索結果は互換性のために key-method 2 を足すよう勧めますが、それは別の時代の助言です。この行を拒否したパーサーは現行のもので、そもそもそんなオプションはありません。行を削除すれば起動は直り、二つのピアがセッションをどう守るかは何も変わりません。

プロファイルが持っているものと、プロトコルが実際にやっていることの間のこのずれが、ここでの主題そのものです。そして、人が同時に行いがちな他のいくつかの編集も説明します。そうした編集がたいてい一まとめで現れる理由も説明します。

症状はハンドシェイクの失敗ではなく、パースエラーです

オプションは、どのパケットを送るよりも前に読み込まれます。未知のディレクティブを含むプロファイルはその段階で失敗するため、プロセスはネットワークに到達せず、ハンドシェイクエラーも出しません。メッセージはたいていオプションとファイルを示すので、原因を特定しやすい失敗の一つです。パケットもルートもファイアウォールも関係しません。

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

メッセージがディレクティブ名を示していれば、診断はそれで終わりです。このビルドが受け付けないものがファイルに入っている、ということです。逆にファイルパスを示しているなら、問題は足りない include か鍵であり、同じ起動段階の別の部分です。

ここから「クライアントやサーバーが古いプロトコルモードを必要としている」と結論してはいけません。パースの失敗は、あなたのファイルとバイナリの間の語彙の問題であり、この場合バイナリは語彙から一語を落としただけです。

ディレクティブとワイヤー形式は別物です

旧来の key-method オプションは TLS 鍵交換の枠組みを選ぶものでしたが、現代の交換は、かつてそのオプションが要求していた複数パケット方式です。何も選ばなくなったためオプションは消え、それが指していた形式が唯一の形式になりました。したがって行を削除しても、セッションは以前と同じ枠組みのままです。テキストの編集でどちらの方向にも変えられるものではありません。

だからといって、「方式2」を「復元」しようと古いバイナリを戻すのは誤った修理です。戻るのは古い既定値を持つ古いパーサーだけで、その後に来た修正を失います。証明書の検査や暗号リストを弱めて接続が戻ることを期待するのも同じ理屈です。

有効な確認は、バージョンとパースされた設定であって、ファイルにその語があるかどうかではありません。

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

何を、どのファイルから削除するか

実行中のプロセスが実際に読んでいるファイルだけを編集してください。パッケージ化されたシステムでは、たいていユニットが示すクライアント用またはサーバー用ディレクトリのプロファイルであり、参照用にホームディレクトリへ置いた複製ではありません。生成されたプロファイルはテンプレートから再構築されることがあるため、配備済みの複製だけを変えても、次のプロビジョニング実行で元に戻ります。

古い行を削除し、エンドポイント、証明書、暗号ポリシー、制御チャネルの設定には手を触れないでください。これらはプロセスが必要とする正式にサポートされたオプションであり、パースエラーとは無関係です。同じプロファイルに心当たりのないディレクティブがある場合は、プロセスが起動するまでまとめて削除するのではなく、一つずつ実行中のバージョンと突き合わせてください。

そのうえで目的のインスタンスを起動し、起動時の出力を読んでください。リスナーが存在する状態でのきれいな起動が、この段階が終わったことの確認です。その後のクライアント試験は別の問いに答えるものです。

拒否されたプロファイルと拒否されたクライアントは似て見えます

二つの失敗は似たサポートスレッドを生みますが、必要な証拠は違います。自分の設定を拒否するサーバーは決して起動しないので、どのクライアントも接続できません。問題なく起動して一人のクライアントを拒否するサーバーは動いており、そのログに理由があります。証明書の問題、クライアントが受け付けないプッシュされたオプション、暗号の不一致です。

削除したオプションは二つ目のケースの診断にはならず、それにすがると同じ一時間を二度無駄にします。クライアントのログがサーバー側の拒否を示すならその拒否を読み、ローカルのエラーを示すなら調べるべきはクライアントのプロファイルです。もう存在しないディレクティブにすがることは、どちらの調査も同じだけ遅らせます。

その行が決して答えなかった互換性の問い

このディレクティブとともに出回るプロファイルは、たいてい特定のプラットフォームにまつわる話を伴い、その話は技術的な理由より長く生き残ります。モバイルやデスクトップのクライアントには今でも 完全にサポートされたプロファイル が必要です。信頼できる証明書チェーン、両端が受け入れるデータ暗号、両端が実装する制御チャネルモード、そしてクライアントのビルドが拒否しないディレクティブです。どれも古い key-method 行の有無で決まるものではありません。

圧縮は同じ形をした別のポリシー上の問いです。key-method 行を削除しても、圧縮のディレクティブがあなたの配備でサポートされているか許容されるかについては何も言えず、二つの判断は独立に行うべきです。何かがつながるまでセキュリティに関わる設定をまとめて削除していくのが、動いていたプロファイルを説明のつかないプロファイルに変える道です。

何をなぜ削除したかを短く記録してください。オプション、それを拒否したバージョン、エラーを示したコマンドの三つです。プロファイルを引き継ぐ次の人にはまさにその三つの事実が要りますし、後から再構成するより今書くほうが安く済みます。