iPhoneのオンデマンドVPNはセルラーではなく社内Wi-Fiに接続する
除外ルールは存在するのに負け続ける。オンデマンドのリストは上から順に読まれるため、先頭の包括的なルールが、社内ルールが読まれる前に朝の結果を決めてしまう。
九時になると端末は社内の無線LANにつながり、トンネルはひとりでに上がって一日中そのままになる。セルラーは後から、全員が意図したとおりに振る舞う。数週間前に誰かが社内ネットワーク向けの除外を追加したので、プロファイルはレビューではきれいに見えるのに、毎朝同じ結果を生む。端末は与えられたリストに従っており、リストはその作者が信じていたものとは別のことを言っている。
リストは上から読まれ、最初に一致したものが勝つ
エントリは順に評価される。条件が成立する最初のエントリがその時点の結果を決め、その下にあるものは決して見られない。したがって順序は、ルール内に書かれたどんな条件とも同じだけの意味を持つ。配列を上から読めば、明らかに含んでいる除外を無視しているように見えるプロファイルが説明できる。
社内の除外より上に置かれた一般的な無線接続のエントリは、現地でのトンネルを保証する。挙動が反転するためにペイロードのほかの何かを動かす必要はない。
切断エントリは二つの仕事をする
アクションが切断のとき、そのエントリはすでに走っているセッションを閉じ、条件が真の間は新しいセッションを遮断する。除外にとって両方の半分が重要であり、後半は忘れられがちだ。同じエントリが二つ目のプロファイルにあると、建物のほかは動いているのにVPNが起動を拒むフロアを説明できる。誰もトンネルには触れておらず、そうしたのはリストだ。
表はその形を示しており、除外が先で、名前は自社の配備から取る必要がある。ふつうは二つのエントリで足り、セルラー用の三つ目が残りを予測可能にする。
| Order | Action | Conditions |
|---|---|---|
| 1 | Disconnect | Wireless interface plus office network name |
| 2 | Connect | Wireless interface |
| 3 | Connect | Cellular interface |
除外には両方の条件を残す
ネットワーク名をインターフェイスの種類と組み合わせる。名前だけでは同じラベルを持つテザリング回線で発火しうるし、種類だけでは利用者がその日に訪れるすべての無線ネットワークを除外してしまう。両方の半分は一つのエントリに属し、たまたま隣り合っている二つのルールに属するのではない。
名前の比較は完全一致で、大文字と小文字を区別し、それは一つの既知のネットワークには合うが、ほかのどこでも窮屈だ。ゲストネットワークはなじみのあるラベルを再利用し、拠点は合併後に改名され、有線のデスクには名前がまったくない。壁の標識から読むのではなく、ネットワークチームに正確なラベルを尋ねること。
プローブが名前を上回るとき
プローブのエントリはURLを要求し、成功した応答を条件が真であると読む。内側からしか応答しないホスト、たとえば公的に解決できないイントラネットサービスを選べば、ルールはネットワークが自分を何と呼ぶかを気にしなくなる。どこからでも応答するプローブは建物ではなくインターネットを試している。これが機能するかを決める性質は、応答がリダイレクトなしで届くことであり、すべての要求をはね返すゲストポータルは、プローブを雑音に変える。
ドメインベースのルールは別の形式で、NEEvaluateConnectionRule は要求されたドメインに一致し、名前が引かれたときに接続できる。そのワイルドカードは左端のラベルとしてのみ受け入れられるので、*.example.com は有効だが example.*.com はそうではない。プロファイルがインターフェイス条件も到達性プローブも使っていないなら、代わりにそのルール種別を使っていないか確認すること。
オンデマンドのルールが制御しないもの
ルールはトンネルを開始するかどうかを選ぶだけで、動かし続けることには口を出さない。現れて数分後に消えるセッションは、アイドルタイマー、ゲートウェイのセッション上限、経路のサイズを示している。どれも異なる痕跡を残すので、どれかを変える前にルールのリストを除外しておくべきだ。キープアライブの設定はそのパターンを説明せず、変えても原因に触れずに作業を移すだけになる。
利用者は設定でオンデマンドをオフにでき、管理された割り当ては次のチェックインでそれを復元できる。トグルが何度も前の位置に戻り続けるなら、割り当てが能動的な側だ。この区別は重要で、強制はひとりでに戻るのに対し、提供はオフのままにとどまる。
どのプロファイルグループが端末を所有しているのか、そして意図がトンネルの強制なのか単なる提供なのかを確認すること。その答えが、利用者の設定を不具合と見るか機能と見るかを決める。