DNS du VPN sur iPhone : qui possède le réglage décide où il s'applique

Saisissez une adresse de résolveur privé dans les réglages Wi-Fi d'un iPhone et elle fonctionnera jusqu'à ce que le téléphone quitte ce réseau, c'est-à-dire exactement le moment où un VPN est censé prendre le relais. C'est le premier piège du DNS mobile : l'endroit où vous avez saisi le réglage définit sa portée, et cette portée est plus étroite que la plupart des gens ne le supposent. Avant de modifier quoi que ce soit, répondez à trois questions sur le déploiement, car les réponses déterminent quel contrôle vous devez toucher. Traitez la séquence comme une revue de conception plutôt que comme une chasse aux réglages.

Trois questions avant de saisir une adresse de résolveur

Premièrement, quels noms ont réellement besoin d'un traitement particulier ? Une zone privée comme corp.example est un espace de noms, pas un hôte unique, et la réponse devrait être un domaine plutôt qu'un seul enregistrement. Deuxièmement, quel résolveur fait autorité pour elle, et qui possède ce service ? Troisièmement, quel chemin rend ce résolveur joignable depuis le téléphone : le tunnel, un réseau Wi-Fi routé ou quelque chose de complètement différent ?

Si l'un de ces trois n'a pas de propriétaire, arrêtez-vous. Un changement de DNS effectué sans espace de noms, sans source faisant autorité et sans chemin joignable est une supposition qui échouera différemment sur le réseau cellulaire qu'au bureau.

Une entrée DNS Wi-Fi appartient à ce réseau Wi-Fi

La configuration DNS manuelle sur iOS est stockée par réseau. Elle s'applique tant que le téléphone est associé à ce SSID et cesse de s'appliquer lorsqu'il ne l'est plus, ce qui signifie qu'elle ne peut ni régir le trafic cellulaire ni décrire ce que fait un client VPN. La modifier pour réparer une application qui échoue sur le réseau cellulaire revient à changer un réglage que le chemin défaillant ne lit jamais.

Cela ne rend pas le DNS par réseau inutile. Pour un laboratoire domestique ou un seul SSID de bureau, c'est le moyen le plus simple d'atteindre un résolveur interne, et il est honnête sur sa limite.

Le mécanisme DNS du VPN suit le protocole et le client

Un fournisseur de tunnel de paquets sur iOS peut configurer le DNS via l'API des réglages DNS d'Apple, qui expose les adresses de résolveur et la correspondance de domaines au tunnel propriétaire de la connexion. Une configuration IKEv2 native peut recevoir le DNS via la charge utile de configuration IKE lorsque la passerelle la pousse, mais la façon dont un client donné applique ce qu'il reçoit est un détail d'implémentation que vous devez vérifier. Un client basé sur une application peut implémenter entièrement son propre chemin de résolution.

Ce sont des points d'intégration différents, et le résultat de l'un d'eux ne devient pas une règle pour tous les iPhone. Le mécanisme pris en charge est ce que le profil ou le fournisseur documente pour le protocole utilisé.

Décidez par propriété, pas par commodité

Si l'appareil est géré, le propriétaire du profil devrait livrer le réglage DNS avec la configuration VPN, afin qu'un réenrôlement le restaure sans que l'utilisateur ait à se souvenir de quoi que ce soit. Si une application de fournisseur possède le tunnel, son écran de réglages est l'endroit où regarder, et sa documentation fait autorité sur ce qu'elle peut séparer. Si le téléphone est personnel et le besoin un nom interne sur un réseau, le réglage par réseau est proportionné.

La règle de décision est courte : le réglage appartient là où la connexion est provisionnée. Partout ailleurs, c'est une exception locale que le prochain changement de réseau effacera.

Vérifiez sur les chemins que le téléphone utilise réellement

Testez une requête fraîche depuis l'application qui a besoin du nom privé, sur le Wi-Fi au bureau, sur le réseau cellulaire et lors d'une transition entre les deux. Une application dotée de sa propre intégration de résolveur peut emprunter un chemin différent de celui du système, alors testez l'application réelle plutôt qu'un onglet de navigateur qui fonctionne par hasard.

Lorsque le nom privé échoue, conservez l'erreur exacte et l'état du profil. Un résolveur public qui répond que le nom n'existe pas donne une réponse correcte à la mauvaise question, et l'ajouter à côté du résolveur de l'entreprise n'est pas une conception d'espace de noms.

Enfin, stockez la politique vérifiée avec la source de provisionnement. La prochaine reconnexion ou inscription devrait restaurer le même service de noms parce que le profil l'a dit, pas parce que quelqu'un s'est souvenu d'une modification faite sur un point d'accès il y a deux ans.