Votre tunnel divisé atteint l’application mais pas son serveur DNS

Router le sous-réseau de l’application est la partie évidente d’un tunnel divisé, et ce n’est pas tout le travail. Le résolveur se trouve souvent à une autre adresse que l’application qu’il sert, si bien qu’un tunnel fonctionnel peut laisser la requête en dehors. Un profil qui porte 10.80.0.0/16 et rien d’autre envoie la requête pour 10.90.0.53 par l’interface locale, où aucune zone privée n’existe. Ajoutez la route du résolveur, puis examinez la seconde moitié du problème : quel serveur le client choisit réellement.

Le mythe : une route couvre tout le service

Un tunnel divisé est une liste de destinations qui passent par la connexion, non la description d’un service. Le sous-réseau de l’application et l’adresse du résolveur sont deux destinations, et un profil peut porter l’une sans l’autre. Quand cela arrive, l’application est joignable par adresse tandis que son nom échoue, ce qui ressemble à une panne DNS plutôt qu’à un trou de routage.

Le sous-réseau autour du résolveur n’est pas couvert automatiquement non plus. Une route d’hôte vers une seule adresse suffit pour ce résolveur et n’ouvre pas ses voisins. C’est tout l’intérêt d’une route d’hôte : étroite par conception, et facile à oublier quand le service suivant apparaît sur le même sous-réseau.

Trois choses doivent être réunies pour que la requête fonctionne : le client route l’adresse du résolveur par le tunnel, la passerelle accepte et transmet cette demande, et le résolveur accepte la source qu’il reçoit. La réponse doit aussi revenir par le chemin convenu. Qu’il en manque une et le symptôme est identique, d’où l’intérêt d’écrire le tableau des adresses avant de toucher à une configuration.

Déterminez quelles adresses le profil doit porter

Listez les destinations dans l’ordre : le réseau de l’application, l’adresse du résolveur et le point de terminaison public qui achève le tunnel lui-même. La troisième ne doit jamais être routée dans le tunnel, car la connexion extérieure a besoin d’un chemin qui existe avant le tunnel.

Incluez UDP et TCP pour le DNS, car les implémentations sont censées prendre en charge TCP en plus d’UDP, et un chemin TCP bloqué produit des échecs lents et partiels plutôt que nets. Si la zone privée est aussi servie par IPv6, l’exception d’hôte équivalente utilise une adresse et un préfixe IPv6 et constitue une entrée distincte.

Notez ce que le profil couvre déjà avant d’ajouter quoi que ce soit. Une route en double est inoffensive, mais une route existante inattendue vous dit que le profil a été conçu pour un plan d’adressage différent de celui qu’on vous a donné.

Ajoutez la route d’hôte via le propriétaire de la connexion

Pour un profil Windows natif géré localement, la route appartient à la connexion et non à la table de routage globale de la machine. Prévisualisez d’abord l’ajout, puis appliquez-le avec la même portée que celle utilisée par le profil.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

La première commande prévisualise la modification sans rien installer, et la seconde liste les routes que le profil porte actuellement. La référence Add-VpnConnectionRoute de Microsoft documente les portées par utilisateur et pour tous les utilisateurs ; un profil pour tous les utilisateurs a besoin de son propre paramètre de portée, et une commande par utilisateur contre un profil pour tous les utilisateurs échoue ou atterrit au mauvais endroit.

Quand le profil est géré ou provient d’un client fournisseur, la modification appartient à ce propriétaire. Empiler une route système permanente sur une stratégie de connexion fonctionne jusqu’à ce que la stratégie soit réappliquée et que la route disparaisse, ce qui arrive généralement lors d’un appel au support plutôt que pendant les tests. Cette panne est silencieuse : la route disparaît, le nom cesse d’être résolu et personne ne relie les deux événements. Placez la modification dans l’enregistrement propre au propriétaire pour que la prochaine réapplication la porte au lieu de l’effacer.

Après l’application, reconnectez le profil au lieu de supposer que la route a pris effet. Les changements de route sur une connexion active ne sont pas toujours pris en compte, et une reconnexion reproduit aussi l’état que vos utilisateurs auront réellement.

Vérifiez quel résolveur le client a réellement utilisé

Une route contrôle les paquets adressés au résolveur. Elle ne décide pas quels noms doivent y être envoyés, et cette sélection est un mécanisme distinct. Sous Windows, les règles effectives d’espace de noms peuvent choisir un résolveur par domaine, tandis que les paramètres DNS du profil fournissent une valeur par défaut. Ces deux couches peuvent diverger sans produire la moindre erreur, d’où le fait qu’une requête directe ne constitue que la moitié de la preuve.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

La première commande imprime la stratégie d’espace de noms en vigueur, et la seconde demande directement au résolveur privé le nom de l’application. Une réponse directe prouve que le chemin et le résolveur fonctionnent ; elle ne prouve pas que la requête propre à l’application a choisi ce serveur. Comparez-la à une requête normale du même nom et à la réponse que reçoit l’application.

Tenez compte des caches et du DNS sécurisé au niveau du navigateur, qui peut contourner entièrement le résolveur du système pour les noms saisis par un utilisateur. Un suffixe de recherche est une autre fausse piste : il étend un nom court en nom pleinement qualifié et n’a rien à voir avec le serveur qui répond.

Terminez en reconnectant et en répétant la requête normale, puis confirmez que la navigation ordinaire suit toujours sa stratégie approuvée. Remplacer le résolveur privé par un résolveur public pour faire résoudre un nom sans rapport n’est pas un correctif, et cela déplace silencieusement les requêtes privées là où elles n’auraient jamais dû aller.