RDP se coupe après l’installation d’un client VPN ? C’est le pare-feu

Quelques minutes après la fin de l’installation d’un client VPN grand public, le portail indique toujours que la VM tourne, l’IP publique n’a pas changé et RDP ne répond pas. On suppose souvent que la VM a planté ou que le groupe de sécurité réseau a changé, et les deux sont généralement faux. Ce qui a changé, c’est le profil du pare-feu Windows dans lequel se trouve la machine, et la règle RDP qui correspondait auparavant ne correspond plus. La réparation commence par obtenir un shell par un chemin qui ne dépend pas de RDP.

La VM tourne ; la règle ne correspond plus

Les règles du pare-feu Windows portent un ensemble de profils, et une règle limitée à Privé ou Domaine n’a aucun effet tant que la machine est sur le profil Public. Les installateurs de VPN ajoutent des adaptateurs et des routes, et plusieurs durcissent le Public comme effet secondaire. L’écouteur reste lié au 3389 et les paquets arrivent toujours, mais l’incohérence de profil les rejette.

L’état d’alimentation et l’accessibilité sont deux faits distincts, et une VM en marche avec un port fermé ressemble de l’extérieur exactement à une VM plantée.

Testez le port avant de modifier quoi que ce soit. Une tentative de connexion au 3389 qui expire alors qu’une commande de l’agent invité renvoie encore une sortie pointe vers le pare-feu de l’hôte. Un port qui répond alors que RDP échoue encore signifie que la panne se situe au-dessus de la couche réseau, et cette réparation n’y touchera pas. Notez lequel des deux cas vous avez vu, car la suite du plan en dépend.

Deux portes se ferment indépendamment

La politique de la plateforme passe d’abord : le groupe de sécurité réseau voit le paquet avant l’invité. Cet ordre rend une entrée NSG parfaite inutile quand l’hôte rejette le paquet, et une règle d’hôte ouverte inutile quand la plateforme la refuse. Traitez-les comme deux portes distinctes et testez chacune séparément.

Lisez les règles effectives du NSG dans le portail ou la CLI, puis comparez-les aux règles propres de l’invité. Ne supposez pas que le dernier changement dont vous vous souvenez soit celui qui a pris effet.

Un client grand public peut aussi installer un pilote de filtre ou un kill switch qui bloque le trafic sous le pare-feu Windows. Si les règles du pare-feu semblent correctes et que le port échoue toujours, cette couche est le suspect suivant.

Utilisez l’agent invité comme chemin de retour

Deux fonctions d’exécution distante, Run Command et la Custom Script Extension, s’exécutent dans l’invité via l’agent de la plateforme. Aucune n’a besoin de RDP, donc l’erreur de pare-feu ne les affecte pas. Toutes deux renvoient la sortie du script, ce qui en fait un canal de diagnostic autant que de réparation.

Lisez le profil actif et la règle RDP avant de modifier l’un ou l’autre :

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

Réactiver les règles entrantes sur ce profil est une mesure temporaire, pas une destination. Utilisez-la pour obtenir une session, puis fermez la brèche correctement :

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Ce commutateur ouvre toutes les règles entrantes du profil, pas seulement RDP. Une fois la session obtenue, remplacez-le par une règle restreinte et rétablissez les paramètres que vous voulez réellement. Si l’agent est aussi indisponible, une console série ou un disque reconstruit est la solution de repli, et c’est la raison pratique de garder l’agent en bonne santé.

Réduisez la brèche avant de fermer la session

Le changement temporaire de profil est une porte tenue ouverte à toutes les règles entrantes de ce profil. Remplacez-le par une règle limitée à votre adresse source et au port RDP, puis confirmez que le profil est revenu à son état prévu. Faites-le pendant que vous avez encore la session, car l’erreur suivante ne sera peut-être pas réversible à distance. Gardez un second chemin d’administration, comme Bastion ou une console série, pendant le changement.

Confirmez le résultat depuis votre poste de travail avec un test de port, et depuis l’intérieur de l’invité avec la liste des règles :

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

Activez la journalisation du pare-feu pendant toute la durée du test. Une seule ligne sur un paquet rejeté qui nomme le 3389 et le profil actif répond à la question plus vite qu’un autre redémarrage.

Empêchez le prochain installateur de recommencer

Si cet hôte n’a aucune raison d’exécuter le client, désinstallez-le. Un client installé est une invitation permanente pour la prochaine mise à jour à réécrire le profil, et la personne suivante déboguera la même panne depuis le portail.

Prenez un instantané du disque avant de laisser quoi que ce soit réécrire les paramètres réseau, et gardez un second chemin d’administration prêt avant d’en avoir besoin.

Notez ce que l’installateur a modifié : adaptateurs, routes, profils de pare-feu, pilotes de filtre et services. Ce relevé transforme le prochain incident en schéma connu plutôt qu’en nouvelle enquête. Quand la VM a besoin d’un tunnel vers exactement un service, mettez le client sur votre poste de travail ou montez une liaison site à site au lieu d’installer sur le serveur un produit pour portables. Les clients grand public visent les portables, et un serveur que vous administrez à distance n’en est pas un.