iPhone の VPN DNS：その設定の所有者が適用範囲を決める

iPhone の Wi-Fi 設定にプライベートリゾルバーのアドレスを入力すると、電話がそのネットワークを離れるまで機能しますが、そこがまさに VPN が引き継ぐべき地点です。これがモバイル DNS の最初の罠であり、設定を入力した場所が適用範囲を定義し、その範囲は多くの人が想定するより狭いのです。編集する前に、答えがどの制御を触るべきかを決めるため、展開に関する三つの問いに答えてください。この手順は設定探しではなく、設計レビューとして扱ってください。

リゾルバーのアドレスを入力する前の三つの問い

第一に、どの名前が実際に特別な扱いを必要とするのでしょうか。corp.example のようなプライベートゾーンは名前空間であり、単一のホストではないため、答えはひとつのレコードではなくドメインであるべきです。第二に、そのために権威を持つリゾルバーはどれで、そのサービスは誰が所有しているのでしょうか。第三に、トンネル、ルーティングされた Wi-Fi ネットワーク、それともまったく別のものか、そのリゾルバーを電話から到達可能にする経路はどれでしょうか。

これら三つのいずれかに所有者がいなければ、止めてください。名前空間、権威あるソース、到達可能な経路なしに行う DNS 変更は推測であり、オフィスとは違う形でセルラーで失敗します。

Wi-Fi の DNS エントリはその Wi-Fi ネットワークに属する

iOS の手動 DNS 設定はネットワークごとに保存されます。電話がその SSID に接続している間は適用され、接続していないときは適用されないため、セルラートラフィックを統制したり、VPN クライアントが何をするかを記述したりはできません。セルラーで失敗するアプリを直すためにこれを編集することは、失敗する経路が決して読まない設定を変えることです。

それでもネットワークごとの DNS が無用になるわけではありません。ホームラボや単一のオフィス SSID にとって、内部リゾルバーに到達する最も簡単な方法であり、その境界について正直です。

VPN の DNS メカニズムはプロトコルとクライアントに従う

iOS のパケットトンネルプロバイダーは Apple の DNS 設定 API を通じて DNS を構成でき、これは接続を所有するトンネルにリゾルバーのアドレスとドメイン一致を公開します。ネイティブの IKEv2 構成は、ゲートウェイが押し出したときに IKE 構成ペイロードを通じて DNS を受け取れますが、特定のクライアントが受け取ったものを適用するかは検証すべき実装の詳細です。アプリベースのクライアントは独自の解決経路を完全に実装できます。

これらは異なる統合点であり、そのひとつの結果がすべての iPhone の規則になるわけではありません。サポートされるメカニズムは、使用中のプロトコルについてプロファイルまたはプロバイダーが文書化したものです。

便利さではなく所有権で決める

デバイスが管理されている場合、プロファイルの所有者が VPN 構成とともに DNS 設定を配信すべきであり、そうすれば再登録でユーザーが何も覚えていなくても復元されます。プロバイダーのアプリがトンネルを所有している場合、その設定画面が確認すべき場所であり、そのドキュメントが何を分割できるかの権威です。電話が個人用で、必要がひとつのネットワーク上のひとつの内部名であれば、ネットワークごとの設定が比例しています。

判断規則は短く、設定は接続がプロビジョニングされる場所に属します。それ以外の場所では、次のネットワーク変更が消すローカルの例外です。

電話が実際に使う経路で検証する

プライベート名を必要とするアプリから新しい要求を、オフィスの Wi-Fi、セルラー、そしてその間の遷移で試してください。独自のリゾルバー統合を持つアプリはシステムとは別の経路をたどることがあるので、たまたま動くブラウザータブではなく実際のアプリを試してください。

プライベート名が失敗したときは、正確なエラーとプロファイルの状態を保存してください。名前が存在しないと答えるパブリックリゾルバーは間違った問いへの正しい答えであり、それを社内リゾルバーの隣に追加することは名前空間の設計ではありません。

最後に、検証済みのポリシーをプロビジョニングのソースとともに保存してください。次回の再接続や登録では、プロファイルがそう言ったから同じ名前サービスが復元されるべきであり、誰かが二年前にひとつのホットスポットで行った編集を覚えていたからではありません。