Bureau à distance via un VPN : dans quelle panne êtes-vous ?

Votre tunnel est actif, le wiki interne se charge, et le bureau à distance refuse toujours de se connecter. Cette combinaison est normale, car le VPN fournit une route vers l'hôte tandis que le service de bureau doit écouter, être autorisé par son propre pare-feu et vouloir authentifier le compte. Quatre étapes de panne séparent un tunnel opérationnel d'une session utilisable, et chacune échoue avec un message différent. Lisez d'abord le message, car il nomme l'étape.

Quatre pannes qui n'en font qu'une

Les étapes sont ordonnées : le nom se résout vers l'adresse privée prévue par la conception, le port répond à une poignée de main TCP, l'hôte accepte la connexion selon sa propre politique et la connexion à la session réussit. Chaque étape rend la suivante intestable, ce qui explique pourquoi modifier les paramètres RDP avant que le réseau soit réglé ne produit que du bruit. Le symptôme semble identique du point de vue de l'utilisateur dans les quatre cas. Seul le message du client les distingue.

Un site interne qui fonctionne ne prouve aucune des quatre choses. Il prouve qu'un hôte du même réseau a répondu sur un autre port avec un autre service. Prenez-le comme une preuve sur le routage et rien de plus.

Testez dans l'ordre et notez le résultat. Sauter à l'écran de connexion parce que le port a répondu, c'est la façon de passer un après-midi sur un problème de pare-feu que la première étape a déjà localisé.

Quelque chose écoute-t-il sur le port 3389 ?

Commencez par le nom, car un nom qui se résout vers la mauvaise adresse invalide tous les tests suivants. Demandez au résolveur du tunnel ce que signifie le nom, puis comparez la réponse à l'adresse privée prévue par la conception, et non à une réponse réussie. Un nom qui se résout vers une adresse publique est tout le problème, et aucun changement RDP ne le corrigera :

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Testez ensuite le port plutôt que l'hôte. Une poignée de main TCP terminée sur 3389 sépare la joignabilité de tout ce qui se trouve au-dessus :

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Exécutez ce test depuis le LAN et depuis le tunnel, car une différence entre les deux résultats localise la panne sur le chemin VPN. Deux pare-feux se trouvent sur le chemin et il est facile de les confondre : le réseau doit autoriser l'adresse de tunnel du client à atteindre l'hôte, et le pare-feu de l'hôte doit autoriser cette même source sur le port d'écoute. Une règle limitée au sous-réseau LAN ne couvre pas le pool de clients VPN, et c'est la cause la plus fréquente d'un délai d'attente que seuls les utilisateurs distants signalent. Vérifiez la portée, pas l'existence de la règle.

Le chemin de retour mérite la même vérification. Les réponses ont besoin d'une route de retour vers le pool de clients et non vers le LAN, et une traduction devant l'hôte modifie la source que votre journal affichera. Si le port répond dans un sens mais pas dans l'autre, la moitié manquante est généralement le chemin de retour.

Lisez le message avant de lire la configuration

La troisième étape est l'hôte qui refuse la connexion selon sa propre politique, ce qui ressemble souvent à un port qui s'ouvre et se ferme immédiatement. Quelque chose a répondu, et c'est une information utile plutôt qu'un silence. Si la poignée de main s'est terminée et que la session est morte aussitôt, le réseau va bien et l'hôte décide. Regardez les autorisations du bureau à distance avant de retoucher au réseau.

La fonction peut être activée pour la machine tandis que l'accès est limité à des groupes précis, et l'écouteur peut être lié de manière à exclure l'adresse depuis laquelle vous êtes arrivé. L'authentification au niveau du réseau ajoute une porte qui échoue avant le chargement du bureau, et son texte d'erreur diffère de celui d'un mot de passe erroné. Comparez le message du client au journal des événements de l'hôte, car le message nomme la porte et le journal nomme le compte.

La connexion à la session est sa propre frontière

L'authentification appartient au service de bureau, pas au VPN. L'identité du tunnel et le compte du bureau sont des identifiants distincts avec des politiques de verrouillage distinctes, donc un tunnel qui fonctionne prouve seulement que le tunnel vous a accepté. Verrouiller le compte du bureau ne perturbe pas le tunnel, et l'inverse est vrai aussi.

Gardez les deux intacts. Quand la route privée manque, réparez la route, car publier l'écouteur sur internet échange un défaut de joignabilité contre un bureau exposé. N'affaiblissez pas non plus les contrôles d'identité de la session pour passer un avertissement de certificat apparu en même temps. Un certificat auto-signé sur un écouteur RDP produit un avertissement par conception, donc l'accepter est une décision et non une étape.

Comptez les tentatives avant de réessayer. Les seuils de verrouillage du bureau comptent les connexions échouées séparément des échecs VPN, et un client qui réessaie sur minuterie peut franchir le seuil pendant que vous modifiez encore une règle. C'est le même mécanisme de tentatives parallèles qui verrouille les comptes après un changement de mot de passe.

Ce que la session peut déplacer, et où cela reste

Apprenez le flux de déconnexion approuvé avant d'en avoir besoin. Fermer la fenêtre peut seulement déconnecter la vue tandis que la session continue de fonctionner selon sa politique configurée, ce qui compte sur un hôte partagé ou audité. Déconnectez-vous depuis l'intérieur de la session quand la politique l'attend.

Décidez ensuite ce que la session peut transporter, car le presse-papiers, les lecteurs redirigés, la redirection d'imprimante et le transfert de fichiers déplacent des données entre les systèmes local et distant là où la politique l'autorise. Une application publiée qui s'exécute de l'autre côté n'est pas automatiquement une frontière sans téléchargement, et une session qui semble en lecture seule peut encore transporter un presse-papiers. Testez la tâche réelle plutôt que la connexion : ouvrez le fichier, utilisez l'application et confirmez la redirection dont vous avez besoin. Les recommandations Microsoft pour joindre un bureau à distance depuis l'extérieur décrivent les options d'exposition prises en charge, et elles sont une meilleure référence qu'un écouteur public ajouté sous la pression.