Mac VPN On Demand：SSID の一致は実際に何を証明するのか

事務所の Wi-Fi 以外のあらゆる場所で VPN に接続するというのは、二行のポリシーのように聞こえますが、難しいのはネットワーク名を認識することではありませんでした。難しいのは、一致した名前が何を証明してよいのかを決めることです。どのアクセスポイントでも見慣れた SSID を広告できますし、あるアドレスへの ping が成功しても、一つの探査に応答があったことを示すだけです。どちらの観察も、Mac が認証された内部ネットワーク上にあることを立証しません。

名前は身元ではない

SSID は無線が発信するラベルです。鍵でも証明書でもなく、ハードウェアの所有者についての宣言でもありません。イベント会場や隣の事務所が、何の調整もなく同じ文字列を発信することができます。ラベルを保護を切る指示として扱うと、判断は最寄りのアクセスポイントを設定した人に委ねられます。

ping によるテストが失敗するのは、もっと微妙な理由です。到達可能性についての問いに答えるだけで、メンバーシップについて答えているわけではありません。応答するターゲットはどこからでも到達できるかもしれませんし、判断しようとしているトンネル経由でしか到達できないかもしれませんし、応答に見えるものを返すキャプティブポータルかもしれません。到達可能性は有用な事実ですが、信頼の境界としては貧弱です。

On Demand がルールセットを評価する仕組み

Apple の On Demand モデルは、アクションと任意のネットワーク条件を組み合わせ、ルールは順に評価されます。すべての条件が一致する最初のルールがアクションを提供し、残りは参照されません。その順序こそがポリシーであり、「念のため」に追加したルールが、機能していた動作を黙って書き換えることがあるのはそのためです。

SSID 条件が参照するのは現在の主接続ネットワークであり、スキャンで見えるすべての名前ではありません。これにより三つの異なる状態が生まれ、それを二つに畳むのがよくある設定ミスです：

ポリシーが存在する場所で設定する

承認された VPN クライアントや管理ワークフローが、このルールの置き場所です。提供元によって、利用できる制御の一部だけが公開されます。したがってそのパネルに項目がないということは、クライアントが公開していないという意味であり、プラットフォームが表現できないという意味ではありません。

自動アクティベーションには、人を介さずに完了できる認証の仕組み、たとえば証明書や別の対応方式も必要です。保存されたワンタイムコードはその仕組みではありませんし、認証を完了できない間に発火するルールは、バックグラウンドで静かに失敗する接続試行を生みます。

ランブックに書く価値のある二つのパターン

一つ目は模倣された名前です。会議場、ホテル、同じ建物のテナントが、あなたのルールが「内側」と見なす文字列を発信し、保護はまさに最も外してほしくない場所で切れます。名前は嘘をついていません。ルールが、答えられない問いを名前に向けたのです。

二つ目は自滅する探査です。スクリプトがプライベートアドレスに ping し、トンネル経由の応答を見て、すでに内部ネットワークにいると結論して切断します。すると探査が失敗するので、スクリプトは再接続して繰り返し、個々の手順は正しく見えるのにトンネルが振動します。結果がトンネルに依存するテストは、トンネルがあるべきかどうかも同時に決めることはできません。

既定値を決め、その後は別に強制する

未知のネットワークの場合と有線の場合には、引き継がれた既定値ではなく明示的な答えが必要です。システムがまだネットワークを分類している間やトンネルを立ち上げている間に、保護されたトラフィックを遮断したままにする必要があるなら、それには独自の対応する強制制御が必要です。On Demand のトリガーが与えるのは接続の挙動であり、遮断の保証ではありません。

正しく書かれた管理者ルールは、承認された例外、それを正当化する証拠、そしてその証拠がない場合の意図的なフォールバックを述べます。Wi-Fi の名前を認識することは、その判断への正当な入力です。それは判断の正当化ではなく、ルールの唯一の行であってはなりません。