ConnMan VPN：消えたメニューはデーモンの問題であり、プロトコルの問題ではない

よくある思い込みは、デスクトップに VPN の項目がない ConnMan システムには VPN サポートが入っていないというものだ。実際には Wi-Fi のサポートはあっても、VPN デーモン、プロバイダー設定、認証エージェントのいずれも欠けていることが多く、これは三つの別々の不在である。メニューはそうした部品を映す画面であって、機能そのものではない。 バージョンとパッケージ構成を確認する は、どれだけ多くのデスクトップのバグ報告よりも、一つのコマンドで多くを教えてくれる。

俗説：メニューが VPN 機能である

まず、インストールされている ConnMan のバージョンと、それに付いてきたパッケージを確認する。古いリリースのバグ報告は別の機能群を説明しており、それを引用すると、置き換える必要のなかったネットワークマネージャーを誰かが再インストールする結末になりがちだ。

何かを変える前に、実際に何があるのかを書き出しておく： デーモンのバイナリ、プロバイダーのディレクトリ、そしてエージェントが存在するかどうか。

どのデーモンがトンネルを所有するか

Debian bookworm 向けの ConnMan 1.41 のドキュメントでは、connman-vpnd が connmand と並んで VPN 接続を管理するデーモンである。名前付き VPN ヘルパー向けの統合が列挙されており、OpenVPN や OpenConnect も含まれる。その一覧はヘルパーについての記述であって、あらゆるプロトコルや認証フローが動くという約束ではない。互換性の保証としてではなく、何を確認すべきかの一覧として読むべきだ。

次に、その統合をゲートウェイの承認済みプロトコルに合わせる。Cisco という語は、旧来の vpnc 形式の接続が必要なのか、AnyConnect 互換のフローが必要なのかを教えてくれない。選び間違えると、認証情報の問題に見える認証失敗が起きる。

単独のヘルパーと ConnMan のどちらでもトンネルを上げられるなら、どちらがルート、DNS、ライフサイクルを所有するのかを、開始前に決めておく。

デーモンの設定はプロバイダーの設定ではない

デーモンの全体設定と個々のプロバイダーの設定は、形式の異なる別々のファイルである。ドキュメント化された bookworm の構成では、デーモンは /etc/connman/connman-vpn.conf を読み、プロバイダーのプロビジョニングファイルは /var/lib/connman-vpn/ の下に .config という拡張子で置かれる。OpenVPN のプロファイルをそのディレクトリに置いても、ConnMan のプロビジョニングファイルにはならない。バージョン別のプロバイダーマニュアルも、プロバイダーのセクションと、それらのファイルが実際に必要とする種類固有のフィールドを説明している。

翻訳は、インストールされた統合が対応するマッピングを通してのみ行う。証明書の信頼、秘密鍵への参照、ゲートウェイの識別、ルート、認証の入力はそれぞれ固有の役割を持ち、別のプロバイダー種別向けのサンプルは、どちらもサーバーアドレスを必要とするからといって互換にはならない。

プロバイダーの読み込みに失敗したら、ブログの例ではなく、インストールされているリリースのマニュアルとフィールドを照合する。

認証エージェントは別個の依存関係である

プロバイダー定義は、認証情報を取得したり認証のやり取りを完了したりするために、依然としてエージェントを必要とすることがある。OpenConnect 統合について、同じマニュアルは、認証に関係する値が欠けている場合に VPN Agent API 経由で要求できること、また短命な cookie は一般に恒久的な設定上の秘密としては適さないことを説明している。その仕組みは、あらゆるブラウザーログイン、MFA の要求、ゲートウェイのポスチャチェックを保証するものではない。ワークフロー全体を、配備を所有する担当者と確認すること。

エージェントの不在を、パスワードやセッショントークンを広く読めるファイルに書くことで補ってはならない。それは不在の統合を認証情報の露出に変えてしまい、二つ目の問題は一つ目より長く残る。

ゲートウェイが対話的なログインを必要とするなら、エージェントは任意の追加ではなく設計の一部である。

確認すべき結果は一つではなく四つ

承認されたプロビジョニングの後、四つの事柄を別々に確認する。プロバイダーが選択されていること、接続が認証されたこと、有効なルートが意図したとおりであること、リゾルバーが期待どおりに動作することだ。稼働中のデーモン、一覧に出るプロバイダー、アプリケーションがリソースに到達できることは三つの異なる結果であり、利用者の本当の目的は最後の一つだけである。別々に記録すれば、どの段階を直すべきかが分かる。

その確認には、再接続の挙動と求められる利用不可状態のポリシーも含める。一度上がって二度と復旧しないトンネルは配備済みとは言えない。VPN 統合を変更する間も、動作している基本ネットワーク設定は復元可能なままにしておく。

ボタンを得るために Wi-Fi マネージャーを置き換えるのは、必要だった欠けた操作よりはるかに大きな変更であり、たいていは俗説の勝ちである。