Linux リリースが実際にサポートできる OpenVPN パッケージとは
古いガイドにあるバージョン番号は、機能の代理にすぎません。実装とベースリリースを突き合わせ、システムがすでに提供しているものを確認してください。
特定の OpenVPN リリース名を挙げた手順は、たいてい何らかの機能を暗に示しており、バージョン番号はその代理でしかありません。読む時点では、ディストリビューションが指定版より新しいものを同梱していても必要な統合が欠けていることがあり、逆に古いものが要件をすでに満たしていることもあります。番号を目的とみなすと、何も解決しないリポジトリ変更が生まれます。要件の症状とみなせば、はるかに小さな判断で済みます。
両者を分けるのは、どの実装か、どのベースリリースか、誰が更新を担うかという三つの問いです。
バージョン番号は機能要件ではない
どのパッケージが提供するかを問う前に、接続が何を必要とするかを尋ねてください。プロファイルは暗号、TLS モード、認証プラグイン、管理インターフェースを要求することがあり、満足のいくバージョン文字列を報告するビルドでもどれかが欠けている場合があります。逆に、少し古いビルドがプロファイルの使うすべてを実装していることもあります。バージョン文字列はパッケージ作成者が書いた要約であり、機能一覧ではありません。
その手順が「この機能以降」を意味するのか、「このビルドを実際に試した」を意味するのかを明確にしてください。二つの答えは別のリポジトリへ導きます。
コードネームはベースリリースと一致しなければならない
リポジトリはディストリビューションのコードネームで管理されており、派生版のリリース名はそのベースのコードネームではありません。/etc/os-release を読んで VERSION_CODENAME と ID_LIKE を確認し、派生版がどのベースリリースを追っているかを突き止めてください。あるデスクトップリリースを一つの Ubuntu コードネームに対応づけた古い回答は、次のリリースについて何も語りません。コードネームを推測すると、別の C ライブラリに対してビルドされたパッケージをシステムが取り込むことになります。
何かを追加する前に、パッケージマネージャーが apt-cache policy openvpn で何を提供しているかを確認してください。もし インストール済みの候補が要件を満たすなら、リポジトリの問いは消えます。
上流リポジトリが実際に結びつくもの
上流チャネルは特定のベースリリース向けにビルドを公開し、その手順はリポジトリ行を署名鍵と対応づけ、サポートされるコードネームを示します。これらの部分は、たまたま知っているコードネームに置き換えてよいプレースホルダーではありません。依存関係はビルドが対象としたリリースに対して解決されるため、きれいにインストールできたパッケージでも、同じライブラリを共有する無関係なソフトウェアを壊すことがあります。
選んだ実装のリポジトリガイドを読み、古いブログのコピーではなく、その現在の互換性表に従ってください。
インストールは統合ではない
openvpn のバイナリを置き換えても、欠けている NetworkManager プラグイン、インポートダイアログ、デスクトップエディターは追加されません。それらは network-manager-openvpn やそのデスクトップ版といった別のパッケージにあり、クライアントライブラリとは独自のバージョン関係を持ちます。OpenVPN 3 Linux はさらに別の実装で、独自のセッションと設定モデルを持つため、そのパッケージは 2.x プロファイルの作業手順をそのまま置き換えるものではありません。
何かをインストールする前に、実行中のトンネルをどのコンポーネントが所有するかを決めてください。一つのホストに二人の管理者がいると、二人のクライアントと同じ二重トンネルの混乱が生じます。
三つの決定を書き留める
実装、ベースリリース、更新の担当者を記録し、そのうちどれが変わる見込みかを書き添えてください。その記録は、ディストリビューションのリリース後にリポジトリ行が機能しなくなったとき、将来のアップグレードが読むものです。それがなければ、次の人がより新しい番号でコードネーム当てを繰り返します。
必要なチャネルがベースリリースをもうサポートしていないなら、答えはプラットフォームの移行であり、三つ前のリリースのリポジトリではありません。