管理対象iPhoneアプリのアプリ別VPN：何が経路になり、何がならないか

iPhoneのアプリ別VPNは電話機全体のスイッチではありません。管理対象アプリ一つとVPNペイロード一つの関連付けであり、アプリ配備時に作られ、それ以外の通信は以前の経路のままです。だからこそ 同じ電話機が一貫しない動きをする：業務アプリは内部ページを開くのにSafariは同じホストに届かない、あるいはトンネルがまったく上がらず、アプリは認証情報の誤りに見えるタイムアウトを報告します。確認は最も広い原因から順に下ろすので、最初に失敗したところで止めます。

まずペイロードとアプリのレコードを確認する

関連付けは二つのオブジェクトに存在し、一つではありません。VPNペイロードはトンネルの種類、サーバー、認証、DNS、独自クライアント使用時のプロバイダのバンドルIDを定義します。アプリのレコードがそのペイロードを指し、多くの管理コンソールはアプリ構成でPer-App VPNに近い名前のアプリ別オプションとして提供します。どのアプリも指さないペイロードはアプリ別に何も経路化しません。誰かが手動で起動する通常のトンネルとして振る舞います。

電話機に触れる前に両方のオブジェクトを読みます。アプリ構成が、テスト中のペイロードを指し、古いコピーを指していないことを確認します。移行後はほぼ同名の重複ペイロードがよくあり、アプリは喜んで廃止済みを指します。次に構成が端末に届いたことを確認します。設定、一般、VPNとデバイス管理にインストール済みプロファイルとして表示される必要があります。そこのVPN一覧は試験ではありません。アプリ別サービスには通常手動スイッチがないため、正しく配備された構成が起動可能なVPNに現れないこともあります。不在はアプリのレコードと、アプリの最初の要求でトンネルが上がるかどうかに現れます。

一つの条件が多くのチケットを説明します。このモデルはアプリが管理経由で届くことを要求します。サイドロードされたコピーや個人購入のコピーは、バンドルIDが一致しても関連付けを得ません。AppleのVPN配備ガイドはその背後のペイロードモデルを説明しています（support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web）。

インストール済みアプリが管理対象コピーであることを確認する

関連付けはインストール済みの管理対象アプリに従います。誰かが個人のApple IDでApp Storeから再インストールした、再署名した企業ビルドに置き換えた、端末を再登録してアプリが別経路で戻った場合、アプリ自体は完全に正常に見えてもトンネルは下がったままになり得ます。

比較で試験し、単一の観察で判断しません。管理インベントリでは、その端末に対して管理対象として、レコードにVPNマッピング付きで表示されるべきです。電話機では、アプリ起動時と最初の要求が出るときにトンネルが上がるべきで、設定で別の手動構成を開始したときだけではありません。アプリ起動で何も変わらず、その手動構成で変わるなら、アプリはアプリ別トンネルにまったく結び付いていません。

更新は重要です。管理経由で配信された更新はマッピングを保ち、利用者が開始した再インストールは失うことがあります。不具合が更新から始まるなら、ネットワークより先にアプリのレコードを確認します。

トンネルが何を取れるかを確認する

アプリ別トンネルは送信元アプリで選ばれるため、電話機の既定経路は依然としてWi-Fiか携帯網に属します。それを変えるのがOverridePrimaryです。プロファイルがこれを設定すると、トンネルは完全トンネルとして振る舞い、すべてのアプリが継承するので、VPNを通るすべてがアプリの不具合ではなくプロファイルの問題になります。

オンデマンド規則が持続性を決めます。OnDemandEnabledとその規則セットが、アプリが通信を送るときにトンネルを戻し、Wi-Fiから携帯網への切り替えを生き延びさせ、アプリが背景に移ると落とします。接続してから静かに死ぬ配備は通常、アプリが待機中に決して発火しないプローブだけに一致する規則を持ちます。

次に経路側を正直に読みます。プロバイダやベンダーのプロファイルが包含リストを提供する場合、10.20.0.0/16だけを運ぶトンネルは10.30.0.0/16のサービスを運びません。それはリストが仕事をしているのであり、アプリ別の不具合ではありません。組み込みのiOSペイロードに包含リストはありません。それがなければ分割はプロバイダの既定とIncludeAllNetworksに従い、隠れたリストには従いません。

アプリを試験し、次にアプリから出るものを試験する

アドレスだけでなく名前で試験します。管理対象アプリ内で内部ホストを解決できることは、DNSもトンネルを通った証拠です。ペイロードがどのリゾルバが応答し、どの検索ドメインが適用されるかを決めるからです。名前解決が失敗しても経路は完璧なことがあり、二つの症状は別の設定を指します。

次に境界を両側から試験します。個人アプリやSafariは通常の公開ページに届き、通信事業者か自宅のアドレスを報告するはずで、管理対象アプリは社内サービスに届きます。両方が同じ公開アドレスを報告するなら、アプリのレコードが何と言おうと、トンネルはもうアプリ別ではありません。

アプリから出るフローが混乱したチケットを生みます。Safariで開くリンク、共有シートで渡される書類、ブラウザに切り替わるSSOログインは、アプリのプロセスとともにトンネルを離れます。アプリ内で表示されるログインは通常アプリに帰属するため、同じURLがSafariで失敗する場所でも埋め込みログインは成功し得ます。それを仮定せず検証します。IDプロバイダがトンネル経由でしか届かない場合は、ログインをアプリ内に保つか、プロバイダのドメインをペイロードのSafariドメインに追加して一致するSafari通信を捕捉します。

症状を層に合わせる

失敗の形が、どの確認を繰り返すべきかを教えます。

中央の行の背後には二つの詳細があり、アプリ別トンネルは健全でも、どのプロバイダリストにも含まれないサブネットを落とすことがあり、管理対象の電話機は複数のVPN構成を保てるので、読んでいるものがそれだと決め付けず、アプリがどれに結び付いているかを確認します。

この順で直します—アプリのレコードを有効なペイロードに向け、管理経由でアプリを再インストールし、アプリの最初の要求でトンネルが上がることを確認してから、名前と境界の試験を繰り返します。最初の要求でトンネルがまったく起動できない場合は、止まってプロバイダ側を確認してください—独自クライアントには インストール済みアプリと一致する識別子を持つNetwork Extensionの存在が必要です。

スクリーンショットの代わりに三つの事実を返します。アプリのレコードがどのペイロードを指すか、設定がインストール済みプロファイルとして表示するか、失敗した要求は名前かアドレスかブラウザへの引き渡しか。この三つの答えが配備の誤りと経路の誤りを分け、次の担当者は診断を繰り返さずに動けます。