二つ目のVPNを起動すると一つ目の状態が置き換わる

二つのクライアント、二つの接続アイコン、そして通信が今や両方を通っているという思い込み。その思い込みを、各プラットフォームが実際に何を許すのかと比べてほしい。スマートフォンのVPNサービス用スロットは通常ちょうど一つであり、デスクトップでは同じルートと同じリゾルバを奪い合う複数のクライアントを同時に動かせる。この二つの状況の違いが、別のVPNを起動したときにVPNが落ちるという報告の大半を説明する。

アイコンが表すのはプロセスであり、連鎖ではない。

スマートフォンは一枠、デスクトップは複数の要求者

Androidでは、プラットフォームはユーザープロファイルごとに一つのアクティブなVPNを持つVPNサービスモデルを提供するため、二つ目を起動すると一つ目が停止する。これはシステムが独自のルールを適用しているのであり、どちらのクライアントの不具合でもない。デスクトップでは複数のクライアントが同時に動作し続けることができ、その場合ルーティングテーブル、ポリシールール、リゾルバ設定、仮想インターフェースを巡って競合する。どちらの結果も、設計どおりに動作しているプラットフォームである。

どちらの結果も、それ自体では入れ子トンネルを生み出さない。連鎖には、一方のトンネルが他方の暗号化パケットを運ぶ必要があり、それは順序の偶然ではなくアーキテクチャである。

二つ目のクライアントが上書きするもの

二つ目のクライアントは通常、デフォルトルートをインストールし、独自のルールを追加し、独自のリゾルバを押し込む。一つ目は通信のないプロセスとして生き残るか、もう勝てないルートを保持し続ける。ドメイン固有のルートが典型的な犠牲者であり、そのため一部の宛先は動き続け、他の宛先は失敗する。目に見える症状は切断であり、実際の状態は部分的な置き換えである。

出口IPの確認ではこれは明らかにならない。一つの宛先に対して一つのアドレスを報告するだけで、どのルートが上書きされたか、どのリゾルバが今応答しているかは何も語らない。被害を見るには、ルーティングテーブルとリゾルバの状態を読むことだ。

入れ子は設計であり、クリックの順序ではない

入れ子が目的なら、各エンドポイントの外側の経路、その障害ポリシー、MTUへの影響を文書化する。外側のトンネルが落ちても内側がまだ接続していると信じているとき、何が起きるかを決めておく。幸運な順序でクライアントを起動することは設定ではない、次の更新や再接続が順序を入れ替えるからだ。入れ子の構成は、他のどんなトポロジーと同じ注意を必要とする。

一方の接続が仕事用で他方が私用なら、プラットフォームが対応する分離や管理された構成に頼ること。企業の管理機構を引きちぎることは分離の戦略ではない。

アイコンではなくアプリケーションで検証する

本当に重要なアプリケーションを、使うつもりのあらゆる状況から実際に動かし、リゾルバの挙動と再接続もテストに含める。最終的な出口アドレスは上書きされたすべてのルートを特定できず、緑のアイコンはそのどれも特定できない。接続の所有者と、実際にサポートされる組み合わせを記録する。

製品が別の製品との共存を明示的にサポートしていない場合、場当たり的なルートや権限の変更は保守可能な展開を生まない。次の更新までしか動かない展開を生むだけだ。

どのクライアントがデフォルトルートを所有し、どのリゾルバが応答し、それぞれが停止したときに何が起きるかを書き留める。