L'ordinateur portable se connecte, le tunnel se déclare actif, et le compte de stockage refuse toujours chaque requête. Le point de terminaison privé existe, la route vers son sous-réseau existe, et le nom soit répond avec une adresse publique, soit ne se résout pas. Rien ne cloche dans le tunnel : on n'a jamais dit au client quel serveur devait répondre pour ce nom. Suivez la requête vers l'extérieur et l'écart devient évident.

Commencez par le résolveur du client

Demandez au client quel serveur il interroge pendant que le tunnel est actif. Un profil point à site fournit cette adresse, et un profil qui ne fournit rien laisse le système d'exploitation se rabattre sur les valeurs par défaut de la carte réseau.

Les résolveurs publics n'ont aucune vue d'une zone privée, ils répondent donc depuis Internet, ce qui est exactement leur travail. Le premier contrôle est donc l'adresse du résolveur utilisée, pas le tunnel et pas le point de terminaison.

Lisez ce qu'est réellement la réponse

Résolvez le nom du service et lisez l'adresse qui revient. Une réponse publique signifie que la requête a atteint un serveur qui ne peut pas voir la zone. Aucune réponse signifie que le nom n'existe que de façon privée et que rien de joignable par le client ne le détient.

Ces deux issues produisent des erreurs applicatives similaires et appartiennent à des propriétaires différents. L'une est un problème de choix de résolveur, l'autre est un lien de zone manquant.

Une entrée hosts prouve le chemin, puis ment

Mettre l'adresse du point de terminaison dans le fichier hosts local est le moyen le plus rapide de prouver que le tunnel et le pare-feu du service fonctionnent déjà. Si la requête réussit avec cette entrée, seule la résolution de noms est cassée. C'est aussi une modification par machine qui couvre exactement un nom.

Elle n'aide pas le deuxième compte, le deuxième point de terminaison ni un collègue, et elle casse sans avertissement lorsque le point de terminaison est recréé à une nouvelle adresse.

Pire, elle fait que votre machine se comporte différemment de celle de tout le monde, et c'est ainsi qu'une panne de résolveur survit à une semaine d'enquête. Utilisez-la pour confirmer le chemin, puis retirez-la et corrigez la cause.

Liez la zone et distribuez un résolveur

Deux conditions doivent être réunies en même temps. La zone privée doit être liée au réseau virtuel où vit le point de terminaison, et le client doit envoyer ses requêtes à un serveur qui peut lire cette zone. Un point de terminaison entrant DNS Private Resolver fournit une telle adresse à l'intérieur du réseau et répond aux requêtes qui arrivent par le tunnel. Placez cette adresse dans le profil VPN et ajoutez le suffixe privé que le client doit appliquer.

Un résolveur local déjà en place peut atteindre le même résultat via un redirecteur conditionnel dirigé vers la zone.

Les règles réseau du résolveur comptent autant que le routage. Si la règle entrante exclut la plage des clients VPN, les requêtes expirent au lieu de renvoyer une mauvaise réponse. C'est ce délai qui renvoie les gens vers une table de routage où rien ne cloche.

Vérifiez le nom, le port et l'identité dans l'ordre

Travaillez dans l'ordre : résolvez le nom, confirmez que la réponse est privée, ouvrez le port, puis faites une requête authentifiée. Chaque étape a son propre propriétaire et sa propre signature d'échec.

Une réponse privée suivie d'un délai d'attente pointe vers une route ou un pare-feu. Une réponse publique pointe vers le résolveur. Une connexion terminée qui renvoie une erreur d'identité appartient au service.

Un autre échec appartient à cette liste. Un pare-feu de service qui autorise une adresse de client cesse de correspondre lorsque le pool attribue cette adresse à une autre session après une reconnexion. Lisez l'adresse de l'appelant que le service a enregistrée, pas celle que le client croit avoir. Les deux sont en désaccord plus souvent qu'on ne l'attend. Le guide Azure DNS Private Resolver couvre le lien de zone et l'agencement du transfert.

Articles similaires