DNS WireGuard sur iPhone : le domaine n’est qu’un suffixe de recherche

Vous écrivez une ligne avec une adresse de résolveur et un domaine d’entreprise, en attendant que seuls les noms de ce domaine utilisent le résolveur du tunnel. Sur le client Apple, tous les noms y vont désormais, et les noms courts du domaine sont aussi résolus. La ligne fait deux choses distinctes, et une seule concerne les requêtes que le tunnel traite. L’autre est une commodité de saisie promue au rang de politique par une lecture complaisante.

Ce en quoi la ligne DNS est découpée

Le client lit l’entrée comme une liste et classe chaque élément selon sa forme. Tout ce qui ressemble à une adresse devient un serveur DNS ; tout ce qui ressemble à un domaine devient un suffixe de recherche. Les deux finissent dans les réglages du tunnel, mais dans des champs différents. Une ligne illustrative pour un tunnel qui porte un résolveur privé et un domaine interne ressemble à ceci.

DNS = 10.24.8.53, lab.internal.example

L’adresse fournit le résolveur. Le domaine fournit un suffixe qui permet au client de saisir un nom court et au système d’ajouter le reste avant de demander. Aucun des deux ne dit quoi que ce soit sur la limitation du résolveur à ce domaine, et c’est précisément la partie que les gens attendent sans l’obtenir. Un seul champ de la plateforme peut exprimer cette restriction, et ce n’est pas celui-ci.

Deux champs Apple, deux tâches différentes

Apple expose la distinction dans son objet de réglages DNS. La liste des domaines de recherche est documentée comme la liste utilisée pour qualifier les noms d’hôte à une seule étiquette : saisissez un nom d’hôte nu et le système peut ajouter chaque suffixe l’un après l’autre. C’est une règle de complétion, pas une règle de routage. Rien dans cette liste ne décide quel serveur est interrogé.

La liste des domaines de correspondance est une autre propriété. Elle décide quels espaces de noms utilisent cet ensemble de réglages DNS, et une entrée vide signifie le domaine par défaut plutôt qu’un suffixe précis. générateur de réglages du tunnel de paquets dans le client Apple suit ce modèle. Il place les suffixes de recherche analysés dans la liste de recherche, et lorsque des serveurs sont présents, il règle la liste de correspondance sur la chaîne vide. Le résultat est un résolveur de tunnel qui répond à tout ce que le système lui envoie, plus un suffixe qui aide pour les noms courts.

Un domaine sur cette ligne n’est donc pas un sélecteur d’espace de noms. En ajouter un autre ne restreint pas les requêtes que le tunnel utilise, et le retirer ne les élargit pas non plus. La seule chose qui change est le nombre de noms courts complétés.

Pourquoi chaque nom atteint quand même le résolveur du tunnel

Avec l’entrée de correspondance vide, le tunnel est un résolveur candidat pour les noms ordinaires, pas seulement pour le domaine de l’entreprise. Dans une configuration de tunnel complet, cela importe généralement peu, car tout le trafic est de toute façon dans le tunnel. Dans un tunnel divisé, cela importe beaucoup. Les noms publics peuvent désormais être résolus par un résolveur qui ne détient qu’une zone privée, et un échec ressemble à un VPN cassé alors qu’il s’agit en réalité d’un résolveur qui ne répond qu’à une partie de l’espace de noms. Le tunnel va bien, les requêtes sortent, et les réponses reviennent vides.

Deux réparations sont possibles et ce sont des décisions différentes. Faites du résolveur du tunnel un résolveur complet qui transmet les noms publics par le chemin approuvé, ou cessez de lui envoyer des noms publics en modifiant la configuration du client plutôt que la liste des domaines. La première garde chaque requête sur le tunnel et fait confiance à l’amont. La seconde garde certaines requêtes en local et accepte que les noms privés cessent d’être résolus tant que le tunnel est arrêté.

Ce qu’un DNS divisé exigerait vraiment

Une politique de résolveur limitée à un espace de noms exige un client qui vous permette de l’exprimer: faire correspondre des domaines sur les plateformes Apple, ou un réglage équivalent dans le produit que vous utilisez. Un champ de configuration qui n’accepte que des serveurs et des suffixes ne peut pas l’exprimer, quelle que soit sa ponctuation. Un profil peut porter la politique parce qu’il décrit une configuration gérée et non un indice au moment de la connexion. Il peut nommer le domaine, les serveurs et ce qui doit se passer lorsque ce domaine est inaccessible. C’est la différence entre un réglage et un contrat.

Sur les appareils Apple gérés, cela passe généralement par un profil de configuration qui porte les réglages DNS propres au domaine. C’est un mécanisme différent du fichier de configuration WireGuard, et les deux ne peuvent coexister que si le client respecte le profil. Vérifiez comment votre client nomme réellement le champ avant de supposer que les deux produits se comportent de la même façon. Un script avec wg-quick sur un Mac et l’application WireGuard sur un iPhone lisent des lignes similaires et les installent à travers des couches différentes.

Lisez les réglages installés, pas le fichier

Sur un Mac, vous pouvez inspecter ce à quoi le système a abouti, ce qui est plus instructif que de relire le fichier que vous avez écrit. La liste des résolveurs montre quels serveurs sont configurés pour quels domaines, et les requêtes délimitées montrent lequel a gagné. Un client qui abîme la ligne le montre ici plutôt que dans le fichier que vous avez écrit. Sur iOS, il n’y a pas de ligne de commande équivalente, donc la preuve y est un résultat : un nom privé qui se résout par le tunnel, et un nom public dont la réponse révèle quel résolveur a répondu.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Ces deux commandes affichent la configuration actuelle du résolveur et les serveurs DNS du service actif. Si le résolveur du tunnel apparaît comme résolveur par défaut sans restriction de domaine, la configuration fait exactement ce que le client a demandé. Corrigez cela en changeant le mécanisme, pas en ajoutant un second suffixe en espérant que le comportement change.