Pourquoi RDP se fige quand l’ordinateur distant se connecte à un VPN

Vous êtes dans la fenêtre RDP, le bureau est à l’écran et vous cliquez sur Connect dans le client VPN qui tourne sur cette machine distante. Quelques secondes plus tard la fenêtre se fige puis se ferme. Le tunnel s’est monté, c’est exactement ce que le journal VPN va rapporter, et c’est le fait le moins utile de tout l’incident. La session est morte parce que la machine à qui vous parliez a changé sa façon de vous répondre, alors examinez le chemin de retour avant de toucher au tunnel.

Notez le point de terminaison que votre session utilise réellement

L’adresse saisie dans votre client RDP n’est pas forcément celle à laquelle l’ordinateur distant répond. Le NAT, une RD Gateway ou un répartiteur de charge devant l’hôte peuvent la réécrire, et le chemin de retour est défini par l’adresse source que la machine distante voit sur la connexion établie. Se tromper ici vous envoie chercher une route qui n’a jamais été impliquée.

Sur l’ordinateur distant, avant que le VPN soit connecté, listez les sessions établies et lisez l’adresse du pair dans la table. Notez-la ensuite quelque part hors de cette machine, car vous ne pourrez plus la lire une fois la session tombée.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Traitez cette adresse comme ce qui doit rester joignable. S’il s’agit d’une adresse privée sur un VLAN de gestion, le tunnel doit laisser ce chemin tranquille. S’il s’agit d’une adresse publique, la réponse doit sortir par la même interface que celle qui a fait entrer la requête.

Lisez la route qui répond à ce point de terminaison

Windows choisit une interface par destination, et Find-NetRoute montre la décision qu’il prendrait maintenant. Exécutez-le sur l’adresse du pair avant de connecter, puis de nouveau avec le tunnel monté, et comparez l’index d’interface et le saut suivant dans les deux réponses. Un changement d’interface, c’est tout le défaut sur une ligne de sortie.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

Un profil de tunnel complet installe une route par défaut à travers le tunnel, comme le guide Windows du routage VPN le décrit, donc chaque réponse sort désormais par le VPN et dépend du fait que l’autre côté route bien vers votre client. Un profil de tunnel fractionné est plus sûr par défaut mais pas immunisé, car une route spécifique couvrant l’adresse du pair peut encore l’emporter sur la route par défaut physique. Quoi qu’il en soit la question est identique : une fois le tunnel monté, l’adresse du pair se résout-elle encore vers l’interface qui a fait entrer la session ?

Si non, la correction appartient au profil ou à une route d’exception explicite approuvée par le propriétaire de la politique VPN. Modifier la table de routage à la main sur un hôte de production pendant un incident, c’est ainsi qu’un contournement temporaire devient une configuration non documentée.

Surveillez le changement de profil du pare-feu

Une nouvelle interface est classée à son apparition, et la classification décide à quel profil de pare-feu son trafic est jugé. Un adaptateur de tunnel qui tombe dans la catégorie Public peut arrêter silencieusement le RDP entrant même si la table de routage semble parfaite. C’est le second mode de défaillance, et il produit un symptôme différent : la route est bonne, les paquets arrivent et l’hôte refuse la connexion.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

Comparez le profil attaché à l’interface du tunnel avec les profils auxquels les règles Remote Desktop sont restreintes. Une règle activée seulement pour Domain et Private ne fait rien pour une interface classée Public, et aucune correction de route n’y change quoi que ce soit. Certains clients VPN restreignent aussi par conception l’accès au sous-réseau local, ce qui produit la même forme de défaillance depuis un autre mécanisme.

Testez la transition depuis un endroit où vous pouvez revenir

Faites toute la séquence depuis une console hors bande ou un second chemin de gestion, dans cet ordre : confirmez la session existante, connectez le VPN, ouvrez une nouvelle session, puis déconnectez le VPN et ouvrez-en une autre. Chaque étape teste une transition différente, et la première qui échoue vous dit quel mécanisme est responsable.

Planifiez le retour arrière avant de commencer, par exemple une tâche planifiée qui exécute rasdial "Work VPN" /disconnect après un intervalle défini. Cela transforme une session perdue en une interruption de cinq minutes au lieu d’une visite sur site, et c’est l’assurance la moins chère de toute la procédure.

Rentrez quand la session a déjà disparu

Si l’hôte est déjà injoignable, arrêtez d’essayer de nouvelles connexions RDP depuis le même client et utilisez le canal de récupération que l’environnement possède déjà : une RD Gateway, une console d’hyperviseur ou une interface de gestion hors bande. Demandez à la personne qui a accès à la console d’exécuter les mêmes commandes Find-NetRoute et Get-NetConnectionProfile, pour que les preuves survivent à la récupération.

Décidez ensuite l’arrangement permanent plutôt que le plus rapide. Soit le chemin de gestion est explicitement préservé par le profil VPN, soit la gestion passe à un canal qui ne dépend pas de la route par défaut de l’hôte. Les deux sont défendables ; une route d’hôte avec une passerelle devinée ne l’est pas. Notez laquelle vous avez choisie et enregistrez l’adresse du pair qui devait survivre.