opt-verify を追加しても OpenVPN の暗号エラーが直らない理由

opt-verify を追加する提案を見つけて行を足しても、暗号エラーは元の場所にそのまま残ります。この結果は予想どおりで、このオプションが暗号を交渉したことは一度もありません。これはオプション整合性の検査で、2.6 で非推奨、2.7 で削除され、これを含むプロファイルがパースできても、それで何かが強制されたわけではありません。

その行が以前何をしていたのかを知ってから、これが欠けている部品だと結論づけると役に立ちます。経緯は、今なぜ役に立たないのかも説明します。

このオプションが以前強制していたこと

2.6 のマニュアルは opt-verify を非推奨と記し、以前の動作として、宣言されたオプションが自分のものと一致しないクライアントをサーバーが切り離し、デバイスの種類や MTU などを比較することを説明しています。この検査はオプション整合性チェックが有効なままであることにも依存するため、disable-occ で動くサーバーにはそもそも存在しませんでした。比較の材料が、相手側の設定を記述したテキストであることに注目してください。データチャネルがどの暗号を使うかについては何も語っていません。

これが、このフラグで暗号エラーを修復できない第一の理由です。暗号の選択は data-ciphers ポリシーと双方が対応するものによって決まり、テキストの整合性検査はその一覧を広げることも交渉を行うこともありません。第二の理由は範囲で、検査は宣言されたオプションが互換に見えるかどうかであり、その結果できる経路の品質ではありません。

2.7 がこの行を見たときの動作

2.7 ではこのオプションはありません。パーサーは名前をまだ認識するため、古いプロファイルは構文エラーなしで読み込まれ、黙って見逃すのではなく削除されたことを報告します。名前を認識することと動作を強制することは別物で、今も起きているのは前者だけです。削除の注記は、パラメーターを交渉できるようになると二つのピアが接続に合意しながら正当に異なるオプション文字列を持つことができるからだと説明しています。

したがって、パースが通るプロファイルは、何らかの受け入れ検査が実行された証拠ではありません。唯一の手がかりがクライアントが接続したことなら、構文が受け入れられたとわかっただけです。

障害が実際にどこにあるか

後のメッセージはたいていその結果なので、何かを変える前に最初の具体的なエラーを保存してください。データチャネルの交渉失敗は承認された暗号ポリシーと双方が実際に告知する能力に属します。TLS のバージョンやスイートの失敗は制御チャネルに属します。証明書の拒否には身元と信頼チェーンが必要で、互換性フラグではありません。

両端のエンジンも特定してください。デスクトップアプリは、テストしたコマンドラインのバイナリとは別のビルドを同梱することがあり、オプションの対応も両者で異なります。プロファイルを取り込むすべてのプログラムが同じように振る舞うと決めつけず、そのエンジンのドキュメントを確認してください。

行だけでなく意図を置き換える

古い管理サーバーが本当に整合性チェックに頼っていたなら、アップグレード前にどんな制約を強制していたかを記録してください。新しいプロファイルで無視されるオプションを残してもそのポリシーは保てず、行をやたらに削除しても同じです。

すべての暗号が無効だという古い提案に、過去のアルゴリズムをすべて有効にして応じないでください。

承認された修正の後、新しい接続で交渉結果を確認し、利用者が本当に必要とするアプリケーションを試してください。サーバーのバージョンと有効なポリシーをその結果のそばに残し、次に読む人が単に受け入れられたことではなく、何が合意されたかを見られるようにします。

目標は、まだパースできる遺産的なフラグではなく、サポートされた制約と機能する認証済みの経路です。