アプリごとの VPN か split tunnel か？Mac のルートが決められること

二つのアプリが同じオフィスサーバーへ接続を開き、トンネルを使うべきなのはそのうち一つだけだ。ルートはその希望を表現できない。ルーティングテーブルは宛先をキーにしており、どのプロセスがソケットを開いたかという概念を持たないからだ。人が求めるものと必要なものはしばしば別物である。設定を変える前に、その二つを切り分けよう。

セレクタは宛先であり、プロセスでは決してない

ルーティングの判断はすべて宛先アドレスから始まり、インターフェースで終わる。カーネルはどのバイナリがパケットを送ったかを問わず、macOS では pf もプロセスでルーティングしないため、ファイアウォールの規則で一つのアプリを別の経路に置くことはできない。だから同じサーバーへブラウザから届いてもレポートツールから届いても、両方とも同じ経路を通る。アプリ単位の分離はしたがって、ルート以外の何かから来なければならない。ソケットを所有する VPN プラグイン、アプリの代わりに接続を引き受けるプロキシ、あるいは別のネットワークスタックである。どれもルーティングの変更ではない。

一つのアドレスと通信する二つのアプリは、設計を試す最も明快な方法だ。両者で答えを変えられないなら、その設計は呼び名が何であれ宛先ベースである。

普通の split tunnel が実際にもたらすもの

split tunnel はプライベートなプレフィックスにルートを入れ、それ以外はすべて物理経路に残す。通常、要求の意味はこれだ。オフィスサーバーへはトンネル経由で届き、一般のブラウジングは直接のままにする。単純で、主要なクライアントはすべて対応しており、他のルートと同じ仕組みで強制される。既定ルートを読むのではなく、route -n get で特定の宛先を確認しよう。split tunnel は既定ルートをしばしば手つかずに残すからだ。

既定ルートを手で編集することは何かへの切り替えではない。それはクライアント自身のルート復元と衝突し、保護ポリシーを導入するクライアントでは、あなたもクライアントも想定しない状態にマシンを残しかねない。代わりにクライアントの対応する設定で split tunnel を構成しよう。

macOS のアプリ単位 VPN が求めるもの

macOS における本物のアプリ単位 VPN は、構成プロファイルによって駆動される Network Extension の機能だ。管理用ペイロードが選択したアプリを VPN 構成に割り当て、システムはそれに従って当該アプリのトラフィックをルーティングする。これは管理された配備であり、MDM、署名済みプロファイル、そしてその両方を所有する管理者を必要とする。

クライアントを手でインストールしてもその割り当ては作られず、通常の設定パネルではアプリを個別に選択できない。ベンダーが独自のアプリ規則を公開することはあり、それは一般的な規則ではなくベンダーの文書に従う。

MDM なしでアプリ単位の分離を実現する三つの方法

管理が使えない場所では、プロキシが現実的な答えだ。アプリ自身のプロキシ設定を行うか、そのアプリだけのために宛先とプロトコルで選ぶ PAC ファイルを使う。

ローカルプロキシは接続を終端し、トンネル経由で張り直すので、アプリはルートを必要としない。第二の選択肢は別のネットワークスタックだ。独自の既定ルートを持つ仮想マシンやコンテナで、アプリはローカルアドレス経由でそこへ届く。第三は宛先ベースのルーティングを受け入れ、要件を捨てることだ。両方のアプリがトンネルを使ってよいなら、それは正直な選択である。三つとも検証でき、どれもルートがプロセスを知っているふりをしない。

要求を書き、答えを曖昧にしない

仕組みではなくワークフローを書こう。どのアプリがどのサービスを必要とするか、別のアプリを同じサービスから遠ざける必要があるか、トンネルが落ちている間に何が起きるべきか。この三つの答えが設計を選ぶ。そして管理者に、その要求がルーティングの変更なのか配備プロジェクトなのかを伝える。

除外されるアプリのケースを明示的に含めよう。保護された経路が使えないときにアプリを停止するクライアントは、物理インターフェースへ戻すクライアントとは挙動が異なり、利用者はその違いにすぐ気づく。期待をチケットに書く。そのうえで実機で検証しよう。同じ製品でも macOS と Windows で挙動が異なることが多く、macOS の文書だけがその設定の動作について信頼できる情報源だからだ。