Le DNS du VPN capte chaque requête : corrigez dns-priority dans NetworkManager

Connectez le VPN du bureau et soudain chaque requête de nom part vers le résolveur d’entreprise. Les noms publics se résolvent encore, donc rien ne semble cassé jusqu’à ce qu’un nom d’imprimante locale échoue ou qu’un enregistrement split-horizon renvoie l’adresse du bureau. Sur certaines installations Fedora, c’est l’inverse : le résolveur du fournisseur continue de répondre une fois le tunnel monté. Les deux cas posent une seule question — quel résolveur possède cette requête — et sur les systèmes NetworkManager la réponse vit dans les propriétés DNS de chaque connexion.

Deux connexions, un seul résolveur gagnant

Chaque connexion déclare une priorité DNS. Les connexions ordinaires valent 50 par défaut et les connexions VPN 0, et la valeur la plus basse l’emporte. C’est précisément ce défaut qui fait qu’une connexion VPN dépasse silencieusement la liaison filaire pour chaque domaine qu’elle revendique : zéro bat cinquante sans que personne l’ait choisi.

La priorité ordonne les candidats. Elle ne limite pas ce qu’on demande au gagnant. Une connexion VPN sans domaine de recherche revendique tout, donc la préférer envoie aussi les requêtes publiques dans le tunnel et, dans une conception à tunnel fractionné, là où le résolveur d’entreprise relaie.

La priorité décide de l’ordre, la liste de recherche décide de la propriété

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

La liste de recherche est la déclaration de propriété. Un domaine nu comme corp.example devient un suffixe de recherche et un domaine de routage. La forme réservée au routage ~corp.example envoie les requêtes sous ce suffixe vers cette connexion sans ajouter le domaine aux noms courts. Ce tilde est la différence entre « interroge ce serveur » et « interroge ce serveur et termine ma saisie ».

Utilisez les deux formes quand les utilisateurs tapent des noms d’hôte courts et que les enregistrements sont aussi adressés par des noms pleinement qualifiés. Utilisez uniquement la forme de routage quand vous voulez la séparation sans changer la façon dont le résolveur complète un nom nu.

Rendez ensuite la préférence explicite et réactivez :

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Une priorité négative est la manière documentée de dire « préfère cette connexion », et définir les deux familles d’adresses garde le comportement cohérent sur un hôte disposant d’une connectivité IPv6. Changer la propriété sans réactiver la connexion ne change rien à ce qui tourne actuellement, c’est pourquoi la séquence se termine par un up explicite.

Laissez systemd-resolved porter la séparation

Le greffon dnsmasq par défaut canalise les requêtes vers un seul résolveur local, donc la séparation par liaison reste grossière. systemd-resolved expose la séparation par liaison, et resolvectl query nomme la liaison qui a répondu.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Ensuite, la liaison d’entreprise porte corp.example et un résolveur public sert le reste. Quand une requête atteint la mauvaise liaison, la commande nomme la liaison qui y a répondu, et le savoir vaut mieux que connaître l’adresse seule.

Adaptez la conception DNS au type de tunnel

Les conceptions de confidentialité qui font tout passer par le tunnel ne devraient pas porter de liste de séparation, car elle rendrait les noms publics au résolveur local et annulerait l’intention. Les conceptions à tunnel fractionné en ont besoin : sans elle, le résolveur d’entreprise voit chaque requête publique, et la configuration casse à l’instant où le tunnel tombe.

Vient ensuite le kill switch qui bloque le DNS hors du tunnel. Les noms se résolvent pour les zones du tunnel et échouent partout ailleurs alors que la connexion est parfaitement saine. Les réponses praticables sont une autorisation explicite pour le résolveur du réseau local ou un cache local qui ne relaie que la zone d’entreprise, et l’une comme l’autre est une exception avec un propriétaire, pas un défaut du tunnel.

Un profil qui réécrit la configuration du résolveur au démarrage de l’interface se comporte presque de la même façon : une fois le résolveur local injoignable, seuls les noms connus du tunnel se résoudront. Quel que soit le mécanisme applicable, notez quels noms sont censés fonctionner dans chaque état, et remettez cette liste à qui traite les signalements.

Vérifiez par liaison, puis de nouveau après reconnexion

Interrogez un nom interne et un nom public, et regardez où va réellement la requête. Une page de contrôle de fuites vous dit quel résolveur a répondu, pas quelle liaison le système a choisie, donc elle ne dit rien de l’ordre que vous venez de configurer.

Relancez les deux requêtes après une déconnexion et une reconnexion. Les priorités sont réappliquées lorsqu’une connexion s’active, et un ancien lien symbolique peut survivre à une mise à niveau dont personne ne se souvient. Ce que vous voulez consigner à la fin, c’est quel résolveur possède quel suffixe, plus un contrôle qui tient encore demain.