オフラインVPNパッケージ：必要なものを標的機に尋ねる

VPNクライアントが必要なのは、通常ならそのパッケージを供給してくれるネットワークに到達するためであり、これは整った小さな循環です。別のマシンで単一のOpenVPN DEBをダウンロードすると、たいていは二つ目の不足依存で終わり、次に三つ目、そしてライブラリのバージョンを追いかけて一晩が過ぎます。代わりに、接続されていないマシン自身に、自分の言葉でパッケージマネージャーが必要とするものを述べさせます。以下のすべては、誰が尋ねるのかというこの逆転から導かれます。

Debian系のシステムでは、その対話はapt-offlineを通じて行われます。要求と返却のワークフローです。そのランタイムはまず標的機に存在している必要があり、承認されたメディアか管理者が管理する別のブートストラップから導入されていなければなりません。どのツールも無から自分を起動することはできません。

補助機の状態ではなく、標的機のパッケージ状態から始める

何よりも先に、標的機のディストリビューションのリリース、ユーザー空間のアーキテクチャ、設定済みのパッケージソースを記録します。この三つの事実が、どのVPN実装とどのデスクトップ統合が適切かを決め、接続された補助機では提供できない事実でもあります。

補助機はファイルをダウンロードするだけで、依存関係の基準にはなりません。OpenVPNがすでに入っている新しいノートPCは標的機とはまったく異なるパッケージ状態を持つので、その成功は標的機が何を受け入れられるかを何も証明しません。

実際に何が欲しいのかも決めます。VPNエンジン、NetworkManagerのサービスプラグイン、グラフィカルエディターは別々のパッケージであり、正しい選択はリリースと、利用者が接続をどう管理するかによって変わります。画面のないサーバーにはエンジンと設定ファイルが必要です。デスクトップには ネットワーク設定にトンネルを所有させるプラグインが必要です。間違った集合を要求すると、成功するインストールと、誰も開始できない接続が生まれます。

二回の往復を、この順序で

マニュアルは三つの操作を分けています。切断されたシステムで要求を生成し、接続された補助機でダウンロードし、標的機へ取り込むという流れです。パッケージを要求する前に標的機のリポジトリのメタデータを更新してください。パッケージ要求はそのメタデータから作られ、古い索引は補助機が満たせない要求を生むからです。

標的機では、apt-offline set vpn-meta.sig --updateという形式の管理者コマンドが更新要求を書き出します。そのファイルを接続されたマシンへ運び、apt-offline get vpn-meta.sig --bundle vpn-meta.zipでバンドルをダウンロードします。バンドルを持ち帰り、apt-offline install vpn-meta.zipで標的機へ取り込みます。これも管理者として行います。

次に、更新されたメタデータからパッケージ要求を作り（たとえばapt-offline set vpn-deps.sig --install-packages openvpn）、新しいバンドル名で往復を繰り返します。各要求はそれが生んだバンドルと対にして保管してください。古いメタデータに対して作られたバンドルは、ファイル名が入れ替え可能に見えても同じ要求ではありません。

統合パッケージは、設計がそれを必要とするときだけ加える

デスクトップがネットワーク設定を通じてトンネルを管理するのであれば、要求にはエンジンだけでなく対応するプラグインも必要です。別のディストリビューションから覚えた一覧ではなく、自分のリリースが提供する具体的なパッケージ名を含め、一覧が変わるたびに新しい要求を生成します。バージョンの固定も考える価値があります。新しいリリース向けにビルドされたパッケージは名前を満たしても実行時に失敗することがあります。ここで四つのパッケージという固定の集合が負債になります。正しい一覧は標的機の性質であり、標的機だけがそれを計算できるからです。

ここでもまた、四つのパッケージという固定の集合が負債になります。正しい一覧は標的機の性質であり、標的機だけがそれを正しく計算できます。

バンドルの取り込みはVPNのインストールではない

名前とは裏腹に、インストール操作はAPTのデータをパッケージ管理環境へ置くだけです。パッケージのトランザクションは実行しません。ローカルで提供されたデータから標的機の実際のAPTインストールを完了して確認し、ZIPの成功がソフトウェアの存在を意味すると決めつけずに出力を読んでください。

そのトランザクションがまだ利用できないファイルを求めるなら、具体的に不足している依存やリポジトリのエラーを残し、そこから次の要求を生成してください。別のリリースのDEBで置き換えたり、通すためにチェックサムやリポジトリ認証の検査を切ったりしないでください。マニュアルはダウンロードしたファイルの検証を飛ばすことに明確に警告しており、それは正しい判断です。検証されていないパッケージは、失敗したインストールより悪い結果です。

パッケージはまだ前半にすぎない

ソフトウェアのインストールは、承認されたエンドポイント、プロファイル、信頼の材料、資格情報を入手することとは別であり、それぞれに独自の管理された受け渡しがあり得ます。有効なプロファイルのない動作するパッケージ集合は、どこにも接続しません。

その後も、将来の更新のためにオフラインの転送経路を生かしておいてください。最初の接続成功を保守の終わりとみなすと、次のセキュリティ更新は車を持つ誰かが来られるまで待つことになり、そうしてオフラインのネットワークは静かに何年も遅れていきます。