Libertine は Ubuntu Touch に端末全体の VPN をもたらすか

Ubuntu Touch では二つの問いが一つとして尋ねられる。このデスクトップパッケージは動くのか、そして端末は VPN を得るのか。コンテナが答えるのは前者だ。その中身は後者に何も答えない。コンテナはファイルシステムについて独自の見方を持つのに対し、ネットワークスタックとその方針は端末に属するからだ。ワークフローを約束する前に、どの部品がどこにあるかを追おう。

一つのように見える二つの問い

コンテナ内でデスクトップアプリを動かすことはパッケージングの成果だ。端末の接続マネージャにトンネルを確立させ、サスペンドをまたいで維持し、切断時に何が起きるかを決めさせるのはプラットフォームの仕事だ。コンテナ内で完了するインストーラが証明するのは、そこで依存関係が解決されたことだけだ。端末に承認済みの VPN プラグインがあるか、トンネルが再起動を越えて残るか、どのアプリがそれを使うかについては何も語らない。

どの評価でも二つを別の文に分けておく。これを一つにまとめることが、実験室のデモを誰も守れないサポート約束に変える道だ。

コンテナの境界が実際に与えるもの

Libertine コンテナは、ベースシステムが読み取り専用の端末の上に重ねられた書き込み可能な環境だ。だからこそそこへのパッケージ導入がそもそも機能し、ベースシステムへの同じ導入は機能しない。またアプリを前面で、端末の画面と統合して動かし、サーバーソフトを動かしたりプロセスを背面で生かし続けたりする手段では明示的にない。これらの制約は、常時稼働が期待される VPN クライアントにとって重要だ。

libertine-container-manager list
libertine-container-manager info -i <container-id>
libertine-launch -i <container-id> bash

一覧はどのコンテナがあるかを示し、info コマンドはディストリビューションと導入状態を報告する。launch コマンドは内部のシェルを与え、パッケージが実際に何を入れたかを調べるのに適した場所だ。与えないのは端末のネットワークに対する権限だ。トンネルを作りたいコンテナ内のバイナリには特権インターフェースが必要で、そのインターフェースはプラットフォームに属し、コンテナには属さない。

端末のネットワーク状態がある場所

名前、ルート、接続プロファイルは、どのコンテナの外にある端末のネットワークサービスが管理する。トンネルの項目は、プラットフォームがその VPN 種別を支え、事業者が対応するプラグインを導入したときにだけそこに現れる。

nmcli connection show
ip route get 10.42.0.10
ip -br addr show

接続一覧が、この端末に VPN プロファイルがあるかという問いへの正式な答えだ。トンネルがその一覧になければ、コンテナ内でどれだけ作業しても現れない。ルート照会が答えるのはより狭い問い、この端末が一つの宛先にどのインターフェースを使うかだ。変化のたびに繰り返すべき確認はこれだ。プロファイルは存在しても、あるアプリが取る経路ではないことがある。

一つのワークフローを端から端まで読む

実際の作業を選ぶ。たとえばデスクトップクライアントで私設データベースに到達することだ。次に流れを追う。アプリはコンテナで起動し、端末が使うリゾルバでホスト名を解決し、ソケットを開き、端末のルーティングがどのインターフェースで運ぶかを決める。各段階には持ち主がいる。コンテナがアプリを、プラットフォームがリゾルバとルーティングを、VPN 端点が認証を持つ。どの段階での失敗もその段階の失敗であり、着想全体の失敗ではない。

私設のホスト名と私設のアドレスを別々に試す。公開アドレスに解決する名前と、トンネルへ経路付けられるアドレスは別の観察であり、混同すると再現できない報告になる。

答えが否のときに記録すること

この端末がこのリリースではワークフローを運べない、というのが正直な結論のこともある。証拠とともに書き留める。プラットフォームが提供する接続種別、試したクライアント、失敗した段階だ。

次に受け入れた代替を示す。別の機器、別のアクセス方法、あるいは私設ネットワークに触れずコンテナ内にとどまるより狭い作業だ。

古い手順を再現するためにベースシステムを再マウントしたり、説明のない権限を与えたりする誘惑に抗う。起動する端末は、半年後もなおネットワーク方針を論じられる端末とは同じではない。