iPhone の Always On VPN と VPN On Demand:どちらを配備すべきか

On Demand はルールに一致するとトンネルを開き、管理された Always On は監視対象の端末でカバレッジを強制します。選び方と動作を証明する手順です。

二台の iPhone がどちらも VPN と言いながら、まったく違う動きをすることがあります。On Demand はルールに一致したときにトンネルを開き、利用者は設定から切ることもできます。管理された Always On は監視対象の端末で、トンネルが上がらない瞬間も含めてカバレッジを強制します。利用者が何もしないときに何が成り立つべきかを問うて選び、定常状態ではなく遷移を試験します。以下の手順は、配備が実際に失敗する順序に沿っています。

手順 1:端末が何を強制できるかを確定する

Always On は監視対象端末向けの機能です。端末群が監視下になければ議論は始まる前に終わり、どの payload キーも監視外の端末を強制端末にはしません。管理側と端末の両方から監視状態を確認し、続いて プロファイルに誰が署名したかを確認します。

端末では設定、一般、VPN とデバイス管理の順に開きます。プロファイルの項目には所有者が示され、手動で入れた個人プロファイルは管理サービスが配布したものとは見え方が違います。プロファイル名や提供者の marketing 表記から強制の有無を判断しないでください。表記はプラットフォームのポリシーではありません。

設定に触る前に三つの事実を書き留めます。監視下かどうか、管理プロファイルか個人プロファイルか、どのクライアントがトンネルを担うか。以後の手順はすべてこの三つに依存し、個人端末の挙動を管理プロファイルへ移すことが、誤った基準で配備を承認する道になります。

手順 2:機能名ではなく on-demand ルールを読む

On Demand は順に評価されるルールの一覧です。各ルールは動作とそれを選ぶ条件を示し、条件こそが肝心です。インターフェース種別、Wi-Fi の SSID、DNS ドメイン接尾辞、または探査 URL です。決して一致しないルール集合は、決して接続しない機能です。

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

配列全体を読み、ルールごとに二つ問います。この条件はこの端末群で成り立ち得るか、どのルールも一致しないとき何が起きるか。企業ネットワークはアクセスポイント名を変え、SSID を統合し、DNS 接尾辞を変えるので、そのどれもがルールを現実から静かに切り離します。

DNS 接尾辞の条件は現場で最もよく誤ります。ゲスト網で端末が報告する接尾辞は、社内リゾルバーが提供するものではないからです。ルールを信じる前に、端末が実際に解決する名前を確認します。

手順 3:静的な接続ではなく遷移を試験する

見ている間に上がっているトンネルはほとんど何も証明しません。各遷移を意図的に実行し、端末の挙動を記録します。毎回同じプライベート資源を使って結果を比較可能にします。

  • ルールが一致すべきネットワークに接続し、プライベート資源を要求して読み込めることを確認します。
  • アプリを背面にしたまま携帯網へ切り替え、前面に戻して同じ要求を繰り返します。
  • キャプティブポータルの Wi-Fi に接続し、ポータルに届くのか、認証前に強制が遮るのかを見ます。
  • 監視対象端末でトンネルを手動で切り、ひとりでに戻るか、どれくらい速いかを確認します。

監視外の端末があれば同じ一覧を実行します。二つの結果の差が配備の実際の挙動であり、接続中のトンネルの画面写真が決して見せない部分です。

手順 4:二つの故障の形を知る

強制カバレッジは遮断で失敗します。トンネルが確立できないと、端末はプライベート資源とともに通常のインターネット接続を失い、利用者はオンラインなのに閲覧できない端末を体験します。再接続と遮断は別の観測なので、インターネット欠如を一つの症状として扱わず両方を記録します。

On Demand は発火しないことで失敗します。ルールが一致せずトンネルは現れず、プライベート資源はただ時間切れになります。クライアントは設定どおりに動いているため、サーバーの問題と誤診しやすいところです。

キャプティブポータルは両者の間にあります。トンネルが存在する前に接続性を必要とするため、トンネルが上がるまで全遮断する方針にはポータルを通る文書化された経路が要ります。これは設計で決めることで、ヘルプデスクではありません。

手順 5:検証し、その後ロールバックを練習する

検証は無害な通信で実際の経路に行います。公開されてはならないプライベート資源を要求し、端末が外部に提示するアドレスを確認し、再起動後にも繰り返して起動順序を見ます。温まった状態だけでは足りません。

次に、本番で必要になる前に試験端末で削除を練習します。プロファイルを外すと端末は以前の状態に戻り、どれだけかかるか、利用者に何が見えるかを知ることは runbook の一部です。Apple の VPN セキュリティガイドは、これらのポリシーについてプラットフォームが文書化している内容の参照であり、プラットフォーム以上を主張する設定を書く前に読む価値があります。

最初の手順の三つの事実を、ルール集合と試験結果の隣に置きます。次に人が、なぜある端末は一方の網でつながり他方でつながらないのかと尋ねたとき、この記録は作り直しではなく一分で答えます。

関連記事