VPN をオンにすると iPhone アプリがローカルデバイスを見つけられない

iPhone アプリが VPN 越しにプリンターやテレビへ届くかを決めるのは二つの門です。ローカルネットワークの許可と、トンネル自身のルート。順に確認してください。

プリンターアプリは空のリストを表示し、カメラアプリはデバイスが見つからないと報告し、動画アプリのキャストボタンは諦めるまで回り続けます。VPN アイコンはステータスバーにあり、電話は電波がフルで、Safari はページを問題なく読み込むので、接続には何も壊れた様子がありません。そこでアプリ自体の設定を開いても、切り替える項目が見当たりません。

自宅ネットワークのラベルプリンターで、私はまさにこの壁にぶつかりました: アプリにはローカルネットワークへのアクセスが一度も与えられておらず、テストしていたプロファイルは 192.168.1.0/24 宛てのパケットをすべて飲み込むフルトンネルでした。独立した二つの門が閉じており、片方を開いても症状は消えませんでした。

一つのアプリと一つのプリンターの間にある二つの門

第一の門はアプリではなく OS に属するプライバシーの判断です。iOS はアプリがローカルネットワーク上のアドレスへ通信を送ってよいかを決め、アプリが最初に試したときにユーザーへ尋ねます。第二の門はルーティングテーブルです。192.168.1.50 宛てのパケットは、Wi-Fi 経由でプリンターへ出るか、トンネルへ入るかのどちらかで、その選択は VPN プロファイルに書かれています。

二つの門は別々の形で失敗し、それが診断を可能にします。許可を拒否されるとアプリ自身のソケット呼び出しが死ぬため、アプリには報告するものがなく、一般的な空状態に落ちます。ルーティングの問題は、パケットが電話を出て向こう側のどこかで死んでいるので、タイムアウトのように見えます。同じ空白の画面、別の修理。

VPN に触れる前に許可の状態を読む

設定、次にプライバシーとセキュリティ、次にローカルネットワークを開きます。アクセスを求めたアプリはすべてスイッチ付きでそこに現れます。Apple はこの画面の一部を iOS 14 から iOS 18 の間で移動し、名前も変えているので、項目が期待した場所にない場合は、ツリーを探し回らずに設定の検索欄へローカルネットワークと入力してください。

人を最も捕まえるのは一度きりの確認です。iOS はアプリが初めてローカルネットワークに触れたときだけ尋ねます。許可しないを押すと、次回起動時に確認は戻らず、スイッチが唯一の戻り道で、しかも最初はオフです。アプリを再インストールすると判断がリセットされるので、再インストールで検出が直ったというトラブルシューティングのスレッドがあります。拒否を消したから実際に直っています。

監視対象や管理対象の iPhone では、スイッチが灰色になることがあります。MDM が配布するプライバシー設定のペイロードは、ローカルネットワークへのアクセスを事前に設定したり固定したりでき、固定されたオフのスイッチは、修理が端末の変更ではなくポリシーの変更であることを意味します。Apple はこの確認とアプリごとのスイッチをここに文書化しています: support.apple.com/en-us/102229。

トンネルが実際に何をルーティングするか確認する

フルトンネルは 0.0.0.0/0 を取り、それとともにすべてのプライベート範囲を取ります。10.x、172.16.0.0/12、192.168.x.x 宛てのパケットはサーバーへ渡り、サーバーは通常それを捨てるか自分のサブネットへ変換するので、許可を与えた後でもプリンターには届きません。分割トンネルは逆のことをしますが、プロファイルが列挙する範囲に限られます。

Apple Configurator で作るか .mobileconfig として配布する IKEv2 プロファイルは、これを全トラフィック送信の設定と、分割時の除外するローカルネットワークの明示的なリストとして表現します。NEPacketTunnelProvider 上に作られたクライアントアプリは同じ判断を includedRoutes で表現します。どちらもステータスバーからは見えません、しかも両方ともアプリが期待する表示を上書きします。

私が使うのはこのテストです。VPN を接続したまま、Safari でルーターの管理ページを LAN アドレスから開きます。公開サイトが読み込めるのにそのページがタイムアウトするなら、プライベート範囲はトンネルの中です。ページが開くなら、ローカル通信はまだ Wi-Fi から出ており、遮断は別の場所にあります。

症状を門に対応づける

同じ電話の二つのアプリが食い違うことがあるのは、許可がアプリごとに、ルートがプロファイルごとに与えられるからです。何かを変える前に何が失敗するかを比べてください: たいてい模様が門の名を自分で名乗ります。

What you seeGateNext step
Device list stays empty, Local Network switch is offPermissionEnable the switch, force-quit the app, reopen it
Switch is on, router page times out, public sites loadRoutingExclude the local range in the profile, or move to a split tunnel
Both pass, direct IP works, discovery stays emptyLink-local multicastEnter the device address by hand, or check profile discovery support
Works by IP address, never by name such as printer.localName resolutionFix mDNS reachability or use the numeric address
Everything fails with the VPN off, on hotel Wi-FiClient isolationChange network, do not change permissions

mDNS の行には注が必要です。Bonjour とほとんどのキャストプロトコルの検出トラフィックは、リンクローカルスコープで 224.0.0.251 と ff02::fb へマルチキャストされ、ルーティングされたトンネルはそれを運びません。だからデバイスは直接接続には応答しても、リストには決して現れないのです。

アイコンではなく操作をテストする

ローカルネットワークのスイッチを切り替えたら、アプリスイッチャーからアプリを強制終了して開き直します。動作中のプロセスは変更前の拒否状態を保持することがあり、空のリストを返し続けるアプリは、許可が効いたかどうかに関係なく同じに見えます。そのあと、デバイスリストが埋まるのを待つのではなく、テストページを印刷する、動画を開始するといった具体的な操作を一つ実行してください。

比較の間は VPN プロファイルを固定します。切断して初めて検出が動くなら、原因は許可ではなくトンネルだと分かりました。試行ごとに変えるのは一つだけにしてください、そうでなければ次の実行は何も教えてくれません。

この順で直す

以下の順序は私が今守っているもので、次に試すテストが読めなくなる中途半端な状態に電話を残しません。

  1. アプリがプライバシーとセキュリティ、ローカルネットワークの下にあり、スイッチがオンであることを確認します。
  2. 強制終了してアプリを開き直し、実際の操作を一度だけやり直します。
  3. 接続したままルーターのページを LAN アドレスで開き、プライベート範囲がトンネルを通るかどうかを確かめます。
  4. トンネルを通るなら、プロファイルを編集してローカルネットワークを除外するか、プロファイルの管理者に頼んでください。
  5. スイッチが灰色なら、端末は管理対象とみなし、依頼を管理者へ回してください。

通常はそのうち一つだけが当てはまります。どれも結果を変えないなら、残る容疑者はネットワーク自体、たとえばアクセスポイントの分離や Wi-Fi アドレスに紐づくクライアント許可リストで、上の対応表がどれかを指しています。

関連記事