Le DNS Azure P2S échoue quand le résolveur est dans un VNet appairé

Un client peut joindre son propre réseau virtuel et échouer malgré tout à résoudre des noms dans un réseau appairé. L'appairage n'est pas le transit de passerelle tant que les deux côtés ne le disent pas.

Faites un ping vers la VM et elle répond ; demandez son nom et le client déclare que l'hôte est inconnu. Quand le résolveur se trouve dans un réseau virtuel appairé plutôt que dans celui qui contient la passerelle VPN, ce couple de résultats est attendu, et aucun dépannage du résolveur n'y change rien. Ce qui manque est un contrat de routage que l'appairage retient par défaut. Deux topologies semblent presque identiques sur le papier, et l'écart entre fonctionnel et cassé tient à une paire de commutateurs d'appairage réglés dans le bon sens.

Imaginez un portable qui tunnelise vers une passerelle dans VNet2, le contrôleur de domaine qui sert le DNS siégeant dans VNet1.

Deux topologies, une différence

Placez le résolveur dans le réseau virtuel de la passerelle elle-même et le nom se résout dès que le tunnel monte. Aucun réglage d'appairage ne participe à cette résolution.

Déplacez le même résolveur de l'autre côté d'un appairage et le client reçoit toujours une réponse de la VM tandis que le nom reste inconnu. Certificat, tunnel et client sont inchangés. La seule chose qui a bougé est l'endroit où vit le résolveur. L'appairage lui a donné une route vers cette adresse, pas l'autorité à la passerelle d'y porter le trafic.

Côté A : autorisez le transit de passerelle chez le propriétaire de la passerelle

Un appairage joint deux réseaux virtuels, mais la jonction n'est pas transitive pour le trafic qui arrive par une passerelle, et une demande point à site arrive exactement ainsi. La passerelle de VNet2 n'a donc pas qualité pour remettre la résolution à VNet1 tant que la conception ne l'accorde pas. L'autorisation est un commutateur sur l'appairage détenu par le réseau qui contient la passerelle.

Réglez Allow gateway transit sur l'appairage de VNet2 vers VNet1. La propriété appartient à l'objet d'appairage, pas à la ressource de passerelle, aussi la lit-on et la modifie-t-on dans le panneau d'appairage. C'est tout le côté A.

Côté B : utilisez les passerelles distantes sur le pair

L'autre moitié est l'image miroir : sur l'appairage de VNet1 vers VNet2, activez Use remote gateways. Activer le même indicateur aux deux extrémités, ou à une seule, laisse un chemin à moitié construit et le symptôme d'origine intact. Seul le réseau doté de la passerelle VPN autorise le transit, et le pair est le côté qui l'utilise.

Lisez les deux propriétés sur les deux réseaux au lieu de faire confiance au panneau du portail ouvert en dernier.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Voir la paire côte à côte est le moyen le plus rapide de repérer un réglage inversé. Un appairage qui signale AllowGatewayTransit false du côté de la passerelle explique toute la panne sans capture de paquets.

Ce que le client doit encore recevoir

Le routage est nécessaire et non suffisant, car le profil point à site doit aussi remettre au client une adresse DNS qui répond une fois le transit en place. Le résolveur de la plateforme n'est pas cette adresse : il répond pour les zones Azure Private DNS liées au réseau virtuel, mais rien pour une zone hébergée sur vos propres serveurs d'annuaire, et c'est ce que ce déploiement utilise. Pointez un client dessus et les noms publics se résolvent allègrement tandis que l'hôte interne reste inconnu.

Interrogez le résolveur depuis le portable connecté avant de changer quoi que ce soit d'autre.

nslookup dc01.corp.example 10.1.0.4

Un délai d'attente dit que le chemin manque encore. Une réponse faisant autorité renvoie le problème au client, souvent un suffixe qui n'est jamais ajouté, si bien que les noms courts partent vers un résolveur public qui les fait échouer allègrement.

Comparez le même contrat côté site à site

Rien de tout cela n'appartient en propre aux portables. Remplacez le client par une agence en site à site et l'exigence bilatérale revient : l'agence arrive directement dans le réseau de la passerelle, et un service à deux réseaux de distance reste derrière l'appairage.

Le transit doit être accordé sur les deux appairages, et le commutateur qui l'accorde vit sur l'appairage et non sur le type de client.

Avant d'accuser la passerelle

Windows tient une liste de résolveurs par adaptateur, alors confirmez ce que l'interface du tunnel a réellement reçu avant d'accuser la passerelle.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Une réponse négative survit à la correction du routage dans le cache, et une liste de suffixes périmée continue d'envoyer des requêtes là où la zone n'a jamais été hébergée. Videz, redemandez, et notez quel serveur répond.

Deux conditions plus petites décident si le chemin tient : les espaces d'adressage ne doivent pas se chevaucher, et le groupe de sécurité réseau du sous-réseau du résolveur doit admettre le pool de clients, qui n'est qu'une autre plage de sources. Prouvez-le par une vérification des routes effectives côté VM plus une requête directe depuis le client, afin qu'un problème de zone, un problème de suffixe ou un filtre ne soient jamais pris pour un transit manquant.

Articles similaires