Votre domaine VPN dans dnsmasq n'est pas un transfert de zone

Vous cherchez la zone d'entreprise dans la configuration dnsmasq du client, vous ne la trouvez pas et vous concluez que le VPN n'a pas poussé son domaine. Ce qui a été poussé est un indice de routage, pas une zone. Le client enregistre le domaine et le résolveur qui doit y répondre, et le backend géré transforme cela en redirection conditionnelle. Chercher au mauvais endroit produit un diagnostic assuré et entièrement faux.

Ce que le client a accepté n'est pas ce que la passerelle a proposé

Une passerelle peut proposer un résolveur, un domaine et la route nécessaire pour joindre ce résolveur, et le client peut accepter les trois ou aucun. Un profil importé, un script auxiliaire ou une politique qui ignore les options poussées peuvent laisser l'ensemble accepté vide alors que le côté serveur semble correct. Partez de l'état enregistré du client plutôt que de la configuration du serveur, car cet état est ce que le résolveur reçoit réellement. Si le domaine accepté manque, rien en aval n'aura d'importance. Vérifiez les propriétés DNS de la connexion avant d'inspecter un cache.

Cette distinction explique la plupart des signalements d'un domaine qui n'est jamais arrivé. Il a été proposé, et il n'a pas été appliqué.

Deux types d'entrée de domaine

Une connexion peut porter des domaines de recherche ordinaires et des domaines de routage uniquement, et le second type commence par un tilde. Un domaine de recherche achemine les requêtes et permet d'étendre les noms courts, ce qui est pratique sur un poste de travail et surprenant sur un serveur. Un domaine de routage uniquement indique que les requêtes pour ce suffixe doivent aller à des serveurs précis sans changer la façon dont les noms courts se résolvent. Écrire le même domaine des deux manières n'est pas redondant, car les deux entrées font des tâches différentes.

Pour un espace de noms privé, la forme de routage uniquement est généralement celle que vous voulez. Elle garde le suffixe d'entreprise pointé vers le résolveur d'entreprise et laisse tout le reste tranquille.

localhost dans resolv.conf n'est pas un bogue

Lorsqu'un résolveur local de cache est utilisé, le fichier système pointe vers l'adresse de bouclage et rien d'autre. Cette entrée désigne l'écouteur local, pas les serveurs amont que le gestionnaire lui a remis. L'adresse d'entreprise sera légitimement absente du fichier.

Remplacer cette entrée par un résolveur public est le correctif erroné classique. Il rétablit la résolution de noms publique et écarte la politique conditionnelle dans la même modification.

Ne confondez pas les backends

Une instance dnsmasq gérée et un résolveur système sont des programmes différents avec une configuration différente et des vues d'état différentes. Une commande d'état pour l'un ne dit rien d'utile sur l'autre.

Déterminez quel backend le gestionnaire est configuré pour utiliser, puis lisez la configuration générée de ce backend plutôt qu'un fichier propre à la distribution qui se trouve exister. Le gestionnaire écrit sa propre configuration d'instance et prend en charge des options personnalisées pour cette instance, si bien que modifier un fichier global sans rapport ne change rien et ressemble à une modification sans effet. Lancer un second démon sur le port 53 est pire qu'inutile, car désormais deux programmes ne sont pas d'accord sur le propriétaire du port. Établissez d'abord le propriétaire, puis modifiez là où ce propriétaire lit.

Testez l'espace de noms, pas seulement la réponse

Interrogez un nom privé autorisé et un nom de contrôle public par le chemin normal de l'application. Une requête directe au serveur d'entreprise prouve que l'enregistrement existe ; elle ne prouve pas que le client a choisi ce serveur. La seconde requête est celle qui teste la politique.

Répétez ensuite après une reconnexion et après une déconnexion. L'association doit suivre le cycle de vie de la connexion, et les noms privés doivent cesser de se résoudre lorsque le tunnel disparaît, au lieu de retomber sur un résolveur public qui répond au même suffixe. S'ils retombent, vous avez trouvé une fuite, qui est un défaut différent d'une recherche cassée. Notez quel backend s'exécutait, quels domaines ont été appliqués et ce que chaque requête a renvoyé.