クライアントが証明書を検証するようにパッチを当てよという助言は、行動に移すには曖昧すぎます。それは修正済みのソフトウェア不具合、ある提供元の古いビルド、あるいはその検査を一度も要求していないプロファイルのいずれかを指している可能性があります。これらは三つの異なる変更であり、三者三様の所有者がいます。どれに直面しているかを知らずにその一文で動くことは、正常なクライアントを理由もなく変更してしまう道です。

三つの主張を切り分ける

ソフトウェア不具合には勧告、影響を受けるバージョン、修正版リリースがあります。提供元のビルドには独自の配布経路と独自の更新周期があります。プロファイルの不足にはそのどちらもなく、実行ファイルは正常で、設定があなたの想定より少ないものを要求しているからです。主張がこの三つのどれかを名指しするまで、検証するものはありません。

検索する前に、主張を一文で書き出してください。その文が何が壊れているかを名指しできなければ、検索には的がなく、どの結果も関連ありに見えます。

ClaimEvidence that settles itWho owns the change
Software defectAdvisory naming affected versionsPackage or product maintainer
Provider buildRelease notes for that clientThe provider
Profile omissionThe configuration actually loadedWhoever owns the profile

実際に動作している実行ファイルを見つける

どのバージョンを見る前に、何が接続を開始するのかを特定してください。配布サービスのユニット、デスクトップのプラグイン、ベンダーのアプリは、それぞれ別の実行ファイルやエンジンを使うことがあります。シェルの検索パスにたまたまあるバイナリが表示するバージョンは、マシンの棚卸しではありません。実際に接続を行ったユニットやプロセスを読んでください。

systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpn

パッケージ照会が示すのは、ローカルのメタデータがインストール済みかつ利用可能と信じている内容であり、そのキャッシュは古いことがあるので、まず更新してください。また、稼働中のサービスが五分前にインストールされたバイナリを読み込んだかどうかも何も語りません。パッケージの記録と、実際に接続しているプロセスを比べてください。

バージョンの印象ではなくパッケージの証拠

ディストリビューションのセキュリティ保守は修正を後方移植することがよくあるため、古く見える upstream のバージョンでもパッチを含んでいる場合があります。逆に、見慣れないリポジトリのパッケージには、現在の保守を自動的に主張する根拠はありません。バージョン番号ではなく、リリースのサポート状況を読んでください。

その区別こそ、実際の空白と、単に古く見える数字との違いです。同じバージョン文字列がまったく異なる経路とまったく異なるサポートで届きうることを踏まえ、パッケージがどこから来たリポジトリかを記録してください。

設定がもう半分

保守されている実行ファイルでも、あると思っている検査を要求するプロファイルが必要です。信頼の起点、相手側の想定された役割、期待するサーバー名は関連しつつ別個の判断です。役割の検査は名前の検査ではなく、どちらも他方を代替しません。警告が設定についてなら、修正はプロファイルを持つ人の仕事です。

検証されていないプロファイルを補うために場当たり的なパッチを入れてはいけませんし、本当の実装不具合を直すためにディレクティブを足してもいけません。どちらの誤りも前進のように感じられるからこそ、どちらも繰り返されます。

記録の証拠で決める

判断は、あなたが確定したことから導かれます。文書化された影響パッケージならサポートされる更新が、サポートされない基盤なら移行経路が、提供元のクライアントならその提供元の指針が必要です。曖昧な指示は、そのどれかを適用する前に、勧告と影響を受ける構成要素を必要とします。

稼働中のクライアント、完全なバージョン、勧告、プロファイルの所有者を変更記録にまとめて残してください。それはチュートリアルの参照より強く、次の人が実際に必要とするものです。

関連記事