VPNに接続するとHandoffが止まる：確認すべきこと

iPhoneでページを開き、Macのそばへ移動してもDockのアイコンが現れない。VPNを切ると動く。この流れはVPNの問題に見えるし、実際そうであることも多いが、人が考える理由ではない。Handoffは端末間のローカル機能であり、トンネルはインターネット側ではなくローカル側を妨げている。

タスクを一つ、端末を一組に絞る

Handoffに対応するタスクを一つ、たとえばSafariのウェブページやNotesの下書きを選び、端末も一組だけにする。アプリ、アカウント、物理的な位置を同じに保ち、変数は一度に一つだけ変える。三つを同時に動かすテストは、使えない観察結果しか生まない。

Handoffはタスクの継続であり、画面キャストやファイル共有ではない。要件が画面のミラーリングや共有のマウントなら、前提の異なる別の機能を調べていることになる。

正確なタスクを書き留めておく。どんな修正も、その同じタスクが動くことで検証されるからだ。

前提はローカルであって、遠隔ではない

AppleによるHandoffの要件は、近くにある対応端末、両方でWi-FiとBluetoothが有効、同じApple Accountでサインイン、Handoffがオンであることだ。共有Macでは異なることがあるため、アプリを買ったアカウントではなくContinuityに使うアカウントを確認する。そのうえで、アプリとタスクが本当にHandoffに対応しているかを確かめる。任意のアプリが開いているだけでは何も証明にならない。これらの確認は安価で、最初に除外すべきものだ。

これはすべてローカルの無線で行われる。Bluetoothが活動を通知し、Wi-Fiがデータを運ぶので、両方にインターネットがあっても端末は近くにある必要がある。

どちらの端末が使う公開アドレスにも、これは依存しない。

VPNクライアントがローカル通信にすること

フルトンネルのクライアントは、ほかのすべてと一緒にローカルサブネットも捕捉することがあり、ローカルネットワークへのアクセスを許可しない限り、まさにそうするクライアントもある。Appleは、ローカルネットワークを妨げるVPN構成がContinuityの機能に干渉しうると警告している。これはクライアントのポリシーについての説明であり、特定のポートが遮断されるという話ではない。

多くのクライアントはローカルアクセスの例外を用意している。有効にする前に何が許可されるかを読み、ファイアウォール規則を手で書き換えるより、ベンダーが対応する選択肢を優先する。

クライアントにその選択肢がない場合、設計上の判断は配備を所有する側に属する。

共有の出口が与えないもの

同じVPNサーバーを使う二台の端末は出口アドレスを共有するが、共有するのはそれだけだ。Bluetoothの通知は作られず、同じローカルリンクにも置かれず、一致しないApple Accountも直らない。共通の公開アドレスを前提とみなすのはカテゴリーの誤りで、無意味なクライアント変更につながる。

VPNサービス上の加入者分離も、近くの二台がタスクを継続することとは別の問題であり、加入者間の転送を開くことはHandoffの手順ではない。

ルーターベースのVPNは端末に適用されるポリシーを変えるが、欠けている無線やアカウントを補うものではない。

ポリシーの所有者と決め、そのうえで両方の結果を検証する

修正は三つの条件で決まる。VPNを切った状態で前提の連鎖が成り立つか。クライアントに対応済みのローカルアクセス選択肢があり、ポリシーがそれを許すか。そして、トンネルが存在する理由である保護を弱めずに変更を検証できるか。三つ目の答えがノーなら、変更には回避策ではなく管理者が必要だ。

承認された変更のあとで、両方の結果を確認する。タスクは近くの端末で継続し、トンネルを必要とするアプリは意図したアクセスと遮断を保つ。

例外はその接続の構成の隣に記録する。さもないと次のプロファイル更新で黙って消える。