iPhone VPN をドメイン単位で: 拒否をどこで行うかを決める

二つの要件が一つの文として書かれ、その後まったく異なる場所で実装されます。このサイトは VPN 経由でのみ到達できるべきだというのは受け入れに関する表明であり、その自然な場所はサービスの前にあるネットワークです。この iPhone はそのドメインに直接接続してはならないというのはデバイスに関する表明であり、管理されたクライアントポリシーだけがそれを表現できます。プロファイルエディタを開く前に、実際にどちらなのかを決めてください。

同じに聞こえる二つの要件

例示的なホスト records.corp.example を考えます。受け入れの場合は VPN の背後にあるアドレスにだけ公開するので、セルラーの電話からの直接の試行はネットワークで失敗し、同じ要求がトンネル経由では成功し、それでも実際のアカウントログインを要求します。デバイスの場合は電話が公衆インターネットに到達できるので、ホストは誰にでも解決して応答し、試行を止められる唯一の場所はデバイスです。サービスは、決して自分に届かない要求について規則を適用できません。

要件の読み違えは、特定の展開として現れます。レコードは公開されたままで、運用者は VPN が必須だと信じており、セルラーでの試行を監査すると要求がトンネルに入っていないことが分かります。何もブロックされていないので、ログに壊れた様子はありません。

評価アクションを文字どおりに読む

オンデマンドの仕組みには二つの別個のアクション層があり、それらを混同することがここでの混乱の大半を生みます。外側のルールアクションは、ルールが一致したときにトンネルをどうするかを決め、接続評価アクションは、評価ルール内のホスト名一致をどうするかを決めます。Apple の Never Connect のリファレンスは二番目の層だけを説明しています。

neverConnect は名前がブロックを連想させるため最もよく誤読される値です。これは一致したホスト名に対してトンネルの起動を制御するもので、電話が名前に到達する許可ではありません。したがって Never Connect の項目はドメインのブロックではありません。設計文書でそう呼ぶと、実際には持っていない強制境界で展開が承認されてしまいます。

サービスを所有しているなら、境界で強制する

受け入れを制限するとは、VPN の経路が届く場所にだけ名前を公開し、意図した経路が機能し、別の経路が機能しないことをテストすることです。公開したすべてのレコード、公開するなら両方のアドレスファミリー、アプリが使う中間名や代替名もすべて対象にします。公開ロードバランサーを指したままの古い CNAME があると、主要なレコードがどれほど整っていても直接経路は生き続けます。

これはデバイスではなくサービスを守ります。電話が DNS クエリを送るのを止めませんし、アプリが試すのを止めません。そうした試行が許容できるなら、境界での強制はより安価で持続的な選択です。設定したクライアントだけでなく、すべてのクライアントに効くからです。登録されたことのない電話でも機能します。

電話に試させることすら許さないなら、管理されたポリシーが必要

試行を止めるには、接続前、トンネル障害中、ネットワーク変更後にアプリや宛先を対象とする、サポートされた強制ポリシーが必要です。VPN またはデバイス管理のプロバイダーに、そのポリシーの名前、組織的な管理が必要かどうか、他に何に影響するかを尋ねてください。アプリごとのトンネルとオンデマンドルールは同じものではなく、ホーム画面の接続へのショートカットも同じではありません。

トンネルを無効にして要求が出ていくかどうかを観察し、障害のケースをテストします。出ていくなら、文書化した境界は展開した境界ではありません。

三つの質問で決める

第一に、サービスを制御しているのか、電話だけなのか。第二に、デバイスは他のすべてに公衆インターネットを正当に使ってよいのか。第三に、電話は管理されているのか、誰によってか。サービスを所有し管理された端末群があればどちらの層も使えますが、電話だけを所有する場合はクライアントポリシーが唯一の選択肢であり、それがサポートされている必要があります。

プロファイルに触れる前に、その三つに答えてください。そうすれば設定は、Never という名前のチェックボックスの意味を推測することではなくなります。