再起動後のiPhoneのVPN：最初に何が起きるべきか

「VPNをつけたままにする」という方針は、およそ三十秒の問い詰めに耐える。再起動後もオンか。端末のロック解除前にオンか。Wi-Fiがまだサインインページを表示している間もオンか。トンネルが上がるまで通信を遮断するのか、最初のアプリに直接接続を試させるのか。これらは四つの異なる要件であり、端末の設定で保証できるのはその一部にすぎない。答えは段階のあるタイムラインとして書き、実際の再起動のあとに各段階を確認する。

要件をタイムラインとして書く

ビジネスにとって重要な瞬間とは、どの保護対象タスクがトンネルなしで起きてはならないのか、そのタスクが起動後どれくらいで実際に試みられるのか、という点で決まる。その瞬間より前はすべて順序であり、確認するのはその順序だ。「VPNはオンでなければならない」というメモは検証できないが、「トンネル確立前に記録ホストへの通信はない」は検証できる。

次に、個人の端末でできることと管理された端末群でできることを分けるべきだが、両方の答えは互換ではない。

第一段階：最初のロック解除前の状態

ロック解除後に見たトンネルから、ロック解除前の挙動を推測してはならない。正直な検証は、再起動し、端末をロックしたままにし、反対側からトンネルができるかどうかを観察することだ。ほとんどの個人設定では答えは「いいえ」であり、それは不具合ではなく、端末のロック解除前に最初の保護対象タスクを試みてはならないという意味にすぎない。

ロック解除前のカバレッジに本当に依存する要件なら、クライアントの設定ではなく導入の責任者に持ち込む。

第二段階：ネットワークの準備とキャプティブポータル

管理されたAlways Onは利用者の操作なしに有効になり、プロファイルがインストールされている限り再起動をまたいで持続し、確立はインターフェースがIP到達性を得たあとに続く。重要なのはこの最後の文であり、まだアドレスを得ていない端末には土台となるものがない。まだ受け入れていないホテルのポータルは、まさにこの意味で準備ができていないネットワークであり、記憶されたVPN設定が代わりに片づけてくれるわけではない。

だから受け入れの記録にはポータルの場合の一行が要る。端末が待つのか、利用者が先にポータルを通るのか、どちらが許容できるかは誰が移動するかで決まる。朝七時に再起動する人が思いつくはずはないので、選択を書き残す。部屋番号を要求するポータルは、チェックボックスだけを受け付けるものとも別のケースである。

第三段階：人の手をまだ必要とする認証

自動有効化と自動認証は別の能力である。デバイス証明書を使うプロファイルは後者を人の手なしに完了できるが、ワンタイム要素を要求するゲートウェイはできず、どんなポリシーでもそれは変わらない。ハンズフリーの起動順序を約束する前に、どちらを導入するのかを決める。

次に中間状態を明示的に記録する: 認証が保留中なら、通信は遮断されるのか、待ち行列に入るのか、それとも直接送られるのか。この答えは計画に入れるべきで、設定の誤りが漏洩に変わるのはこの窓だからだ。ゲートウェイを到達不能にして端末がどう動くかを見て確かめるがよく、クライアント自身の説明を読むのではない。

第四段階：最初の保護対象タスク、そのあとに遷移

計画した再起動のあと、保護対象タスクを開き、成功することと実際にトンネルを使ったことを確認する。そのあと同じタスクをWi-Fiから携帯回線への遷移のあいだに繰り返すべきで、この移動は下位のネットワークを再交渉するため、起動時にしか動かなかったプロファイルが失敗し始めるのはそこだ。実行ごとに、接続が自動で上がったか、認証が必要だったか、期待したリソースが応答したかの三つを記録する。

間隙のあいだの保護が必須なら、導入の責任者が承認する検証方法を使う。一回のページ読み込みの成功だけでは、その前に何も直接出ていなかったことを示せない。