Après promotion en contrôleur de domaine, une VM Windows Server 2019 sur Hyper‑V devient injoignable (ping/RDP) depuis l’hôte Windows 10. Voici une méthode rapide et fiable pour diagnostiquer et corriger le problème (profil Domaine du pare‑feu, vSwitch externe, règles ICMP/RDP).
Contexte et symptômes observés
Cas réel : un poste Windows 10 Pro (Dell OptiPlex 7040) exécute Hyper‑V avec une VM Windows Server 2019 promue en contrôleur de domaine (DC1.local). Au départ, tout fonctionne (ping + RDP depuis l’hôte). Après un redémarrage, l’hôte ne joint plus la VM alors que :
- La VM atteint sa passerelle et Internet.
- Une autre VM (RHEL/Xen) sur le même réseau pingue et se connecte au serveur.
- La console locale via Hyper‑V Manager reste accessible.
| Test | Depuis | Vers | Résultat | Interprétation |
|---|---|---|---|---|
| Ping | Hôte Win10 | VM Server 2019 | Échec | Blocage probable inbound côté VM ou isolation de l’hôte |
| RDP 3389/TCP | Hôte Win10 | VM Server 2019 | Échec | Règles RDP non actives/filtrées sur profil Domaine |
| Ping | VM RHEL/Xen | VM Server 2019 | OK | Empilement virtuel OK, routage OK |
| Ping | VM Server 2019 | Passerelle/Internet | OK | Carte VM et vSwitch fonctionnels |
| Console Hyper‑V | Hôte Win10 | VM Server 2019 | OK | La VM répond, problème purement réseau |
Architecture réseau minimale (schéma)
[Internet]
|
[Passerelle]
|
┌──────┴──────────┐
| VLAN X |
| Réseau LAN |
└──────┬──────────┘
|
[NIC physique hôte]
|
[vSwitch Hyper‑V Externe]
/ \
[Hôte Win10] [VM Server 2019 - DC1]
(mgmt OS) (Profil pare-feu = Domaine)
\
\-- [VM RHEL/Xen]
Analyse des causes probables
Commutateur virtuel externe Hyper‑V
Si l’option « Autoriser le système d’exploitation de gestion à partager cet adaptateur » n’est pas cochée, l’hôte perd l’accès réseau via l’adaptateur utilisé par le vSwitch. Après un redémarrage ou une modification, ce paramètre peut avoir été désactivé, ce qui isole le Management OS.
Changement de profil du pare‑feu Windows (Domaine)
La promotion en contrôleur de domaine fait basculer l’interface réseau de la VM sur le profil Domaine. Dans ce profil :
- Les requêtes ICMP (ping) sont désactivées par défaut.
- Le RDP (3389/TCP) n’est autorisé que s’il a été explicitement activé (ou si une GPO l’autorise). Selon les règles, il peut être limité au sous‑réseau local, à des adresses distantes précises ou aux membres du domaine.
Conséquence : un hôte Windows 10 non joint au domaine peut se voir refuser ICMP et/ou RDP par la VM, alors qu’une autre VM sur le même vSwitch (selon son adressage et son statut) peut passer.
Procédure de diagnostic express (10 minutes)
- Vérifier le vSwitch (côté hôte) :
Hyper‑V Manager > Gestionnaire de commutateurs virtuels > Externe > Vérifier que « Autoriser le système d’exploitation de gestion à partager cet adaptateur » est coché. - Confirmer le profil réseau actif (côté VM) :
PowerShell Get‑NetConnectionProfileLeNetworkCategorydoit êtreDomainAuthenticated(profil Domaine). - Tester la couche 3 et le port RDP (depuis l’hôte) :
cmd ping -4 -n 4 DC1.local PowerShell Test‑NetConnection DC1.local -CommonTCPPort RDP # ou Test‑NetConnection DC1.local -Port 3389 -InformationLevel Detailed - Tester l’hypothèse “pare‑feu” (temporaire, < 1 minute) :
PowerShell (dans la VM) Set‑NetFirewallProfile -Name Domain -Enabled False # Refaire ping/RDP depuis l’hôte, puis RÉACTIVER : Set‑NetFirewallProfile -Name Domain -Enabled TrueSi tout redevient joignable pare‑feu désactivé, le diagnostic est confirmé. - Contrôler les règles RDP/ICMP (côté VM) :
PowerShell # Ouvrir les règles RDP Enable‑NetFirewallRule -DisplayGroup "Remote Desktop" # Autoriser l’ICMPv4 (Echo) sur le profil Domaine New‑NetFirewallRule -DisplayName "ICMPv4‑In‑Domain" -Protocol ICMPv4 -Profile Domain -Enabled True -Action Allow
Solutions testées et validées
| Étape | Action | Résultat |
|---|---|---|
| 1 | Vérifier/activer le partage de l’adaptateur physique dans le commutateur virtuel externe. | Déjà actif : pas de changement. |
| 2 | Désactiver temporairement le pare‑feu Domaine sur la VM. | L’hôte redevient joignable (ping + RDP) → problème lié au pare‑feu. |
| 3 | Joindre l’hôte Windows 10 au domaine DC1.local ou créer des règles ICMP/RDP dans le profil Domaine du pare‑feu de la VM. | Accès rétabli de façon permanente. |
Correctifs pérennes et recommandations
Option A — Joindre l’hôte Windows 10 au domaine
- Configurer le DNS de l’hôte en pointant sur
DC1(pas sur un DNS internet). - Ouvrir Système > Informations système > Paramètres système avancés > Nom de l’ordinateur > Modifier > Domaine.
- Entrer
DC1.localet des identifiants du domaine. - Redémarrer l’hôte. Le trafic RDP/ICMP sera alors autorisé par les règles du profil Domaine, selon GPO.
Option B — Conserver l’hôte en Workgroup, ouvrir finement RDP + ICMP sur la VM
Pour limiter la surface d’exposition, autorisez uniquement l’adresse IP de l’hôte Windows 10 :
PowerShell (dans la VM)
$HostIP = "192.168.10.25" # <-- adresse de l’hôte Win10
Enable‑NetFirewallRule -DisplayGroup "Remote Desktop"
# Restreindre RDP au seul hôte
Set‑NetFirewallRule -DisplayGroup "Remote Desktop" -Profile Domain -Direction Inbound -Enabled True -Action Allow
Set‑NetFirewallRule -DisplayGroup "Remote Desktop" -Profile Domain -Direction Inbound -RemoteAddress $HostIP
# Autoriser l’écho ICMPv4 depuis l’hôte
New‑NetFirewallRule -DisplayName "ICMPv4‑In‑HostWin10" -Protocol ICMPv4 -Profile Domain -Direction Inbound -RemoteAddress $HostIP -Action Allow
Vous pouvez également autoriser ICMPv6 si l’IPv6 est actif :
PowerShell
New‑NetFirewallRule -DisplayName "ICMPv6‑In‑HostWin10" -Protocol ICMPv6 -Profile Domain -Direction Inbound -RemoteAddress $HostIP -Action Allow
Option C — Isoler le lab avec un vSwitch Interne ou NAT
Pour éviter d’exposer un DC sur le LAN de production, placez l’hôte et les VMs de test sur un commutateur Interne ou NAT. L’hôte retrouvera l’accès aux VMs via son interface vEthernet (Interne) sans dépendre des règles du LAN.
Commandes utiles de vérification
- Profil réseau actif :
PowerShell Get‑NetConnectionProfile - État des profils de pare‑feu :
PowerShell Get‑NetFirewallProfile | Format‑Table Name, Enabled, DefaultInboundAction, DefaultOutboundAction - Règles RDP :
PowerShell Get‑NetFirewallRule -DisplayGroup "Remote Desktop" | Format‑Table DisplayName, Enabled, Profile, Direction, Action - Activer RDP et ICMP sur le profil Domaine :
PowerShell Enable‑NetFirewallRule -DisplayGroup "Remote Desktop" New‑NetFirewallRule -DisplayName "ICMPv4‑In‑Domain" -Protocol ICMPv4 -Profile Domain -Enabled True -Action Allow - VLAN et IP de la VM :
cmd ipconfig /all - État du commutateur Hyper‑V :
PowerShell (sur l’hôte) Get‑VMSwitch | Select Name, SwitchType, AllowManagementOS
Tableau comparatif des types de commutateurs Hyper‑V
| Type | Connectivité VM → LAN | Accès hôte aux VMs | Cas d’usage |
|---|---|---|---|
| Externe | Oui (via NIC physique) | Oui si AllowManagementOS = True | Lab connecté au réseau d’entreprise, accès Internet |
| Interne | Non (VMs <→ hôte uniquement) | Oui (interface vEthernet interne) | Lab isolé, tests AD sans exposition |
| Privé | Non | Non | Sandbox totalement isolée |
Tableau des ouvertures minimales recommandées
| Service | Protocole/Port | Profil | Plage distante | Remarques |
|---|---|---|---|---|
| Ping | ICMPv4 Echo‑In | Domaine | IP de l’hôte ou LocalSubnet | Diagnostic uniquement |
| RDP | TCP 3389 | Domaine | IP de l’hôte | Activer Remote Desktop et NLA |
| WinRM (optionnel) | TCP 5985/5986 | Domaine | IP de l’hôte | Pour PowerShell Remoting |
Procédures pas à pas
Activer le partage de l’adaptateur sur un vSwitch externe
- Ouvrir Gestionnaire de commutateurs virtuels dans Hyper‑V Manager.
- Sélectionner le commutateur externe utilisé par la VM.
- Cocher « Autoriser le système d’exploitation de gestion à partager cet adaptateur réseau ».
- Valider, puis vérifier l’IP de l’hôte (
ipconfig).
Autoriser RDP et ICMP depuis l’interface graphique
- Sur la VM : Pare‑feu Windows Defender avec fonctions avancées.
- Règles entrantes > Groupe Remote Desktop > Activer les règles TCP‑In pour le profil Domaine.
- Règles entrantes > Partage de fichiers et d’imprimantes (requête écho ICMPv4‑In) > Activer (profil Domaine).
- Au besoin, modifier l’onglet Portée pour limiter aux adresses IP autorisées.
Cas particuliers et pièges fréquents
- NLA et comptes : si « Autoriser uniquement les connexions avec NLA » est activé, utilisez un compte du domaine (
DC1\Administrateur) ou un compte local de la VM autorisé au RDP. - GPO durcies : une stratégie peut ré‑désactiver RDP ou interdire ICMP. Vérifiez via
gpresult /ret l’Observateur d’événements (journal Firewall). - IPv6 : si l’hôte tente d’abord en IPv6, l’ICMPv6 doit être ouvert, sinon le ping échouera malgré l’ouverture ICMPv4.
- VLAN : un VLAN ID erroné sur la carte VM l’isole d’une partie du LAN tout en gardant l’accès Internet (via un routage particulier). Confirmez avec
ipconfig /allet les paramètres de la carte Hyper‑V. - Métriques d’interface (hôte) : une métrique mal priorisée peut envoyer le trafic vers une mauvaise interface. Vérifiez avec
Get‑NetIPInterfaceet ajustezInterfaceMetricsi nécessaire. - Outils de sécurité : certaines suites ajoutent des règles bloquantes. Testez en mode sans échec réseau ou désactivez temporairement le composant pare‑feu tiers.
Script “tout‑en‑un” pour autoriser un poste spécifique
Ce script, à exécuter dans la VM, ouvre RDP et ICMP uniquement pour l’IP de l’hôte, puis valide la connectivité :
PowerShell
param(
[Parameter(Mandatory=$true)]
[string]$HostIP
)
Write‑Host "Autorisation RDP/ICMP pour $HostIP sur le profil Domaine..."
# Vérifier le profil actif
$profile = Get‑NetConnectionProfile
if ($profile.NetworkCategory -ne 'DomainAuthenticated') {
Write‑Warning "Profil actif = $($profile.NetworkCategory). Continuer tout de même."
}
# Ouvrir RDP et restreindre l’adresse distante
Enable‑NetFirewallRule -DisplayGroup "Remote Desktop" | Out‑Null
Set‑NetFirewallRule -DisplayGroup "Remote Desktop" -Profile Domain -Direction Inbound -Enabled True -Action Allow | Out‑Null
Set‑NetFirewallRule -DisplayGroup "Remote Desktop" -Profile Domain -Direction Inbound -RemoteAddress $HostIP | Out‑Null
# ICMPv4/ICMPv6 depuis l’hôte
$rules = @(
@{Name="ICMPv4‑In‑Host"; Proto="ICMPv4"},
@{Name="ICMPv6‑In‑Host"; Proto="ICMPv6"}
)
foreach ($r in $rules) {
if (-not (Get‑NetFirewallRule -DisplayName $r.Name -ErrorAction SilentlyContinue)) {
New‑NetFirewallRule -DisplayName $r.Name -Protocol $r.Proto -Profile Domain -Direction Inbound -RemoteAddress $HostIP -Action Allow | Out‑Null
} else {
Set‑NetFirewallRule -DisplayName $r.Name -Enabled True | Out‑Null
}
}
# Validation basique
Write‑Host "Validation :"
Get‑NetFirewallRule -DisplayGroup "Remote Desktop" |
Select DisplayName, Enabled, Profile, @{n="RemoteAddress";e={(Get‑NetFirewallAddressFilter -AssociatedNetFirewallRule $_).RemoteAddress}} |
Format‑Table -AutoSize </code></pre>
<h2>Vérifications finales</h2>
<ol>
<li>Depuis l’hôte Windows 10 :
<pre><code>PowerShell
Test‑NetConnection DC1.local -CommonTCPPort RDP
Test‑NetConnection DC1.local -Port 3389
ping -4 DC1.local
Sur la VM :
PowerShell
Get‑NetFirewallLogSetting
# Vérifier que le journal du pare‑feu est activé pour les paquets rejetés
Event Viewer (VM) : Applications and Services Logs > Microsoft > Windows > Windows Firewall With Advanced Security et TerminalServices‑LocalSessionManager.
FAQ
Q : Pourquoi une autre VM peut‑elle joindre le serveur alors que l’hôte ne peut pas ?
R : Elle est peut‑être sur le même vSwitch avec une IP incluse dans la portée LocalSubnet autorisée par une règle, alors que l’hôte est filtré (règle restreinte, mauvais vSwitch côté hôte, ou hôte non domaine).
Q : Est‑il sûr de désactiver le pare‑feu pour tester ?
R : Oui quelques secondes pour lever le doute, mais réactivez‑le immédiatement et mettez en place des règles ciblées.
Q : Faut‑il ouvrir des ports AD supplémentaires ?
R : Non pour RDP/ping. Les ports AD (LDAP, Kerberos…) concernent la communication entre membres du domaine et contrôleurs, pas le simple accès d’administration depuis un hôte de lab.
Résumé opérationnel
- Confirmer AllowManagementOS = True sur le vSwitch externe.
- Identifier le profil actif (
Get‑NetConnectionProfile). - Activer Remote Desktop et créer une règle ICMP sur le profil Domaine, idéalement restreinte à l’IP de l’hôte.
- Envisager la jointure de l’hôte au domaine ou l’usage d’un vSwitch Interne/NAT pour les labs.
Annexes pratiques
Réinitialiser les règles de pare‑feu (à utiliser en dernier recours)
cmd
netsh advfirewall reset
Réappliquez ensuite les ouvertures RDP/ICMP nécessaires.
Activer RDP côté serveur par PowerShell (si non actif)
PowerShell
# Activer le service RDP et ouvrir les règles de base
Set‑ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 0
Enable‑NetFirewallRule -DisplayGroup "Remote Desktop"
Bonnes pratiques
- Limiter la portée des règles à des adresses IP précises plutôt qu’à Any.
- Consigner les paquets rejetés pour accélérer les diagnostics futurs.
- Documenter le plan d’adressage des vSwitchs (Externe/Interne/NAT) et les VLAN.
Avec ces vérifications et correctifs, vous rendez de nouveau accessible votre VM Windows Server 2019 (DC) depuis l’hôte Hyper‑V après redémarrage, sans affaiblir la sécurité. Le cœur du problème vient presque toujours de l’activation du profil Domaine et de règles pare‑feu insuffisamment ouvertes (ICMP/RDP), parfois combinées à un paramétrage inadapté du commutateur virtuel externe.