OpenVPNエンジンかTunnelblickか――MacのVPNセッションは誰のもの？

HomebrewはOpenVPNのプログラムを導入し、Tunnelblickは一つ以上のエンジンを動かすマネージャーを導入する。これは別の層であり、有益な問いはターミナルを使うのが好きかどうかではない。設定、DNSの変更、認証情報の要求、セッション終了時の後片付けを誰が所有するかである。これらの層に一人の所有者がいることが、構成を予測可能にする。

以下の五つの確認を順に行う。最初に所有者が二人になる確認こそ、人々がOpenVPN自体のせいにする奇妙な半接続状態を生む。各確認は、それを決める証拠を挙げる。

確認一：実際に動いているOpenVPNバイナリはどれか

接続中にpgrep -fl openvpnを実行し、コマンドライン全体を読む。最初のパスが実際に動いているエンジンだ。Apple SiliconではHomebrewの導入先は通常/opt/homebrewの下にあり、Intel Macは/usr/localを使い、Tunnelblickは自身のアプリケーションバンドル内からエンジンを動かす。

Tunnelblickはエンジンを同梱し、構成がそのうち一つを選べるようにする。Homebrewのフォーミュラを更新しても変わるのは独立したバイナリであり、Tunnelblickプロファイルが起動するエンジンではない。動作の違いを説明するためにバージョンを比べるなら、パッケージマネージャー側ではなくプロセス一覧側のエンジンを比べる。バージョン文字列だけでは、そのエンジンがどのプロファイルを読み込んだかは分からない。

コピーしたプロファイルは、別のファイルを読んでいるのに二つのエンジンを同じに見せることもある。コマンドラインのプロファイルパスは、実行中のプロセスがどの構成を読み込んだかを示す；エディタで開いたプロファイルは証拠にならない。動作を比べる前にそのパスを比べる。

確認二：DNSとルートを変えるのは誰か

エンジンはOpenVPN自身のup/downディレクティブを実行できるが、同じライフサイクルをマネージャーが所有している場合がある。Tunnelblickのネームサーバー設定は標準の接続・切断スクリプトを制御しており、その統合が有効なときはプロファイル内の競合するディレクティブが無視されうる。

DNSは、動いているトンネルが最もよく壊れて見える場所だからだ。接続中にscutil --dnsを確認し、どのリゾルバが先頭かを記録し、切断後に戻ることを確かめる。プロファイルが自分でDNSを設定しようとし、マネージャーも管理しているなら、どちらかが負ける。

最初の接続前にどの層がDNSを所有するかを決め、両方を残すのではなく負ける側のディレクティブを削除する。ルートの変更も同じ規則に従う：所有者は一人、構成に見え、復元手順が文書化されていること。

確認三：認証情報はどこから来るか

対話的な要求と無人プロセスでは要件が異なる。あるアプリが保存した認証情報が別のプロセスで自動的に使えるわけではなく、マネージャーに限定されたキーチェーン項目はシェルから起動した独立エンジンには見えないことがある。

プロファイルの認証情報の出所を列挙する：クライアント証明書と鍵、ユーザー名とパスワードの要求、外部ヘルパーが渡すトークンのいずれかだ。そのうえで、接続が再起動をまたぐ必要があるなら、選んだ所有者が人の介在なしにその出所へ届くことを確かめる。

確認四：プロセスを起動し、監視し、停止するのは誰か

独立した配備が動き続けるには監視役が要る。Launchdはログイン時や要求に応じてエンジンを起動し、クラッシュ後に再起動し、きれいに停止できるが、そのジョブを書いて所有する人が必要だ。ターミナルでコマンドを動かすのは試験には向くが、ウィンドウを閉じる利用者には向かない。

Tunnelblickが所有者のままなら、二つ目のエンジンを起動するのではなく、そのサポートされた操作を使う。Homebrewのバイナリは、コピーしたプロファイルを与えられると、既存のTunnelblickセッションに命令するのではなく、独自の構成と統合の文脈で独立した接続を開く。

どの所有者を選んでも、スリープ、ネットワーク変更、ログアウトで何が起きるかを決めておく。マネージャーは通常これらのイベントを扱うが、素のプロセスは通常扱わず、その結果残る古いルートやリゾルバはサーバーの障害と誤読されやすい。

確認五：引き継ぎをどう検証するか

古い所有者を無効にして新しい所有者を試し、残すつもりなら古い所有者をもう一度試す。一方のワークフローでは応答し、他方では応答しないプライベート資源は、欠けている統合の証拠であり、サーバーの証拠ではない。

独立エンジンへの引き継ぎでは、プロファイルのパス、バイナリのパス、監視役、DNSの所有者、認証情報の出所を記録する。そのうえで、プライベート資源、公開インターネットへの経路、きれいな切断の順に確認する。切断後にDNSやルートが残るなら、新しい所有者の仕事は終わっていない。

Tunnelblickへの引き継ぎでは、構成のエンジンを選び、意図するDNS統合を有効にし、それと衝突するプロファイルのディレクティブを外す。そのうえで同じ三つの確認を繰り返す。動くがリゾルバを変えたままにする接続は、トンネルが上がっても失敗した引き継ぎだ。

パッケージングはサーバー互換性を決めない。サービス自身のクライアント要件を確認し、その管理を自分で用意するつもりがあるときだけエンジン単体を選ぶ。