Windows 10 – Hyper-V et NAT
Sommaire
I. Présentation
Si vous utilisez un environnement virtuel pour réaliser vos maquettes, vous avez probablement fait un choix de produit entre Microsoft, Vmware, Virtualbox, ou un autre…
Vous savez probablement aussi que depuis Windows 8, Edition PRO et supérieures, Microsoft propose une déclinaison d'Hyper-V pour les postes clients (inclus dans la licence Windows PRO et Entreprise) .
Habituellement, en tant que formateur Systèmes et réseaux, j'ai plutôt tendance à préconiser Virtualbox, moins "cloisonné", gratuit et donc plus accessible pour des néophytes. Si vous avez quelques euros à dépenser, la solution vmware Workstation est un excellent investissement (pour peu que vous ne soyez pas réfractaire à la langue de Shakespeare)
En fait, historiquement Hyper-V est une solution d'hyperviseur "comparable" au célèbre Vmware ESX pour lequel vous devez assurer vous-même, les services réseaux ou autres fonctions de copier/coller entre les machines virtuelles et le "reste du monde.
Bien, maintenant ce que je souhaitais partager avec vous est une nouvelle capacité apparue sous Windows 10 ≥ 1511-1607, certes via Powershell, dont Hyper-V peut tirer pleinement partie. Il s'agit de déclarer un réseau virtuel de type "NAT", destiné à offrir un accès "Internet" à vos chères machines virtuelles isolées, sans les raccorder directement à un réseau externe, ni partager la connexion.
II. Implémentation et configuration du NAT
Certaines opérations pourraient être réalisées via l'interface graphique, mais nous allons faire l'essentiel en ligne de commande :-D. Donc en premier lieu, ouvrez une console Powershell en mode Administrateur
A. Création d'un nouveau commutateur virtuel Hyper-V
Attention, il y a une petite subtilité syntaxique en Windows 10 - 1511 et l'anniversary update (1607). En effet, le déclaration "-SwitchType NAT ..." n'est plus supportée dans cette nouvelle mouture. Autrement dit, si la commande PowerShell "[Environment]::OSVersion.Version.Build" renvoie "14393" vous êtes dans ce second cas.
1. Sous Windows 10 - 1511 - Entrez la commande suivante :
New-VMSwitch -Name "NAT-VM" -SwitchType NAT -NATSubnetAddress 192.168.10.0/24
2. Sous Windows 10 - 1607 - Entrez les commandes suivantes :
New-VMSwitch -Name "NAT-VM" -SwitchType Internal New-NetIPAddress -IPAddress 192.168.10.1 -PrefixLength 24 -InterfaceAlias "vEthernet (NAT-VM)"
Si vous ouvrez la console de gestion Hyper-V en parallèle, vous constaterez l'apparition d'un nouveau commutateur virtuel de type "Interne"
Pour rappel, ce type de connexion "Réseau interne" permet de relier l'hôte (votre machine physique) aux machines virtuelles qui y sont connectées.
B. Activation de la fonctionnalité de passerelle NAT
Entrez maintenant cette fameuse commande "magique" suivante :
New-NetNat –Name NAT-VM –InternalIPInterfaceAddressPrefix 192.168.10.0/24
Si vous regardez du côté de la configuration réseau, vous pourrez constater que l'interface "vEthernet (NAT-VM)" possède dorénavant une adresse IP (la première du plan d'adressage indiqué)
Facultatif : Pour modifier l'adresse de la passerelle NAT, il est possible d'utiliser la commande suivante :
New-NetIPAddress –IPAddress 192.168.10.1 -PrefixLength 24 -InterfaceAlias "vEthernet (NAT-VM)"
Cette information est visible et modifiable dans les propriétés de l'interface correspondante au commutateur virtuel que nous venons de déclarer
C. Configuration des machines virtuelles
A ce stade, votre routeur NAT est prêt, mais il manque un service DHCP. Ce qui vous oblige à configurer manuellement vos machines virtuelles en stipulant une adresse IP 192.168.10.x / 255.255.255.0 et la passerelle par défaut sur 192.168.10.1 pour chacune d'entre elle
Vérifiez que l'accessibilité Internet est bien disponible.
Alternative : Installation d'un service DHCP sur Windows 10
Microsoft ne propose pas encore de solution pour ses versions clientes mais vous pouvez opter pour la petite application suivante :
http://www.dhcpserver.de/cms/download/
L'installation de ce programme est relativement simple. Pour cela, il suffit de télécharger l'archive et débloquer le fichier .zip :
Ensuite, faites une extraction du contenu vers un dossier quelconque tel que "C:\Outils\DHCP-Server"
Exécutez l'assistant de configuration "dhcpwiz.exe" puis cliquez sur "Suivant"
Les différentes interfaces réseaux sont alors affichées. La colonne "DHCP" indique les réseaux sur lesquels la configuration automatique via DHCP est déjà active.
Sélectionnez l'interface correspondante à votre routeur NAT précédemment configuré puis cliquez sur "Suivant".
Comme mentionné, faites bien attention à ne pas sélectionner une interface sur laquelle un service DHCP serait déjà actif (Enabled) sous peine de perturber une infrastructure de production.
Ce programme assure un service DHCP de base, mais peut également supporter les fonctions de serveur web, TFTP et redirecteur DNS.
Dans un premier temps, nous n'activerons pas ces fonctionnalités (sur lesquelles vous pourrez revenir ultérieurement). Cliquez sur "Suivant".
Toutefois, si vous avez un contrôleur de domaine virtuel, vous pouvez d'ores et déjà entrer son adresse IP dans le champ DNS de cette interface ou le stipuler ultérieurement au niveau des options DHCP.
L'écran suivant est l'un des plus importants pour le sujet qui nous intéresse. A savoir, la configuration de la plage d'adresses et options de ce service DHCP.
A minima, vous n'avez qu'à définir / confirmer la plage désirée sous "IP-Pool". Les autres réglages et les options DHCP sont destinés aux spécialistes.
Pour définir les principales options, cliquez sur le bouton "Advanced…"
A minima, entrez l'adresse de la passerelle par défaut (Option "03 / Router") en stipulant la patte "privée" de votre routeur NAT, soit "192.168.10.1", puis cliquez sur "OK"
On vous propose ensuite de valider ces réglages qui seront inscrits dans un fichier texte de type .ini. (Facilement modifiable par la suite).
Consultez éventuellement les valeurs, cliquez sur "Write INI file" puis cliquez sur "Suivant".
Cliquez sur le bouton "Admin" afin d'élever les privilèges pour l'exécution du service DHCP durant cette phase de configuration.
Cliquez sur "Install" (pour installer ce programme en tant que service permanent)
Puis cliquez sur "Start"
L'état du service "Status" doit alors mentionner "Running"
Cliquez ensuite sur le bouton "Configure" de la zone "Firewall exceptions".
L'état du pare-feu "Status" doit alors mentionner "Configured".
Pour les plus curieux, vous pouvez ouvrir le gestionnaire de pare-feu avancé (wf.msc) et constater que cette action génère des règles sur le programme dchpsrv.exe en TCP/6 et en UDP/17 sur chacun des profils, soit 6 nouvelles règles au total.
Cliquez sur "Exit" pour revenir sur l'assistant.
Cliquez sur "Terminer"
Cliquez sur "Exit"
Cet outil fonctionne en tant que service Windows et vous pouvez agir sur le fichier de configuration .ini en cas de besoin. Toutefois, pour une meilleure convivialité, vous pouvez conserver une icône de contrôle dans la zone de notification.
Vous pouvez dorénavant bénéficier du DHCP dans votre environnement virtuel et tester son fonctionnement. Si votre hôte bénéficie dans d'accès Internet, les VMs doivent pouvoir en bénéficier aussi.
D. Configuration (facultative) des règles du NAT
Vous savez probablement que par défaut, un routeur NAT constitue un "rempart" contre les connexions entrantes. Pour accéder à un service, tel qu'un serveur Web, situé du côté "Privé", (en l'occurrence, une machine virtuelle), il est nécessaire de "publier" un port externe.
Pour cela, nous allons utiliser de nouveau Powershell. Imaginons simplement qu'un serveur Web est installé sur notre machine "192.168.10.10", il suffit d'entrer la commande suivante :
Add-NetNatStaticMapping -NatName "NAT-VM" -Protocol TCP -ExternalIPAddress 0.0.0.0 -InternalIPAddress 192.168.10.10 -InternalPort 80 -ExternalPort 80
Notes :
- 0.0.0.0 - Indique que toutes les adresses externes sont autorisées à emprunter ce port.
- Le port interne et externe, ici 80, peut être différent.
Vous pouvez configurer autant de règles que vous souhaitez mais n'oubliez pas d'activer également les règles entrantes de pare-feu correspondant sur les machines virtuelles concernées :-).
Et voilà, un bel environnement de maquettage s'offre à vous
Bonne continuation à tous.
Christophe
XEN de CITRIX c’est le TOP…
Bonjour Eric,
En fait, l’idée de cet article était de proposer un ‘petit’ environnement de maquettage sur un poste de travail et non de comparer des solutions de virtualisation de type serveur. De ce que je me souviens, XENServer a des contraintes similaires aux autres hyperviseurs. Ici, je parle de la solution Hyper-V sur les postes clients >W8 (non serveur ;-)…
J’ajouterais que cette solution n’a pas ma préférence, car comparativement à Virtualbox (VM compatibles entre Windows/Linux), il faut toujours contourner les contraintes du « presse-papier » via de vraies connexions RDP. (VBox propose les dossiers partagées et/ou le presse-papier bidirectionnel)
Mais l’essentiel c’est que chacun y trouve son compte, non 😀
A+
Hello,
Très intéressé par cet article ! Actuellement, j’ai une machine pfSense qui fait la même chose.. Je voulais essayer cette méthode!
MAIS :
– le SwitchType NAT n’existe pas
– le paramètre -NATSubnetAddress non plus
Du coup… Comment faire ? 🙂
Bonjour,
Ma 1ere impression est que la fonctionnalité Hyper-V n’est pas activée ou qu’il ne s’agit pas d’un Windows 10 Pro. (je n’ai pas testé sur W8)
–> optionalfeatures.exe puis cocher « [X] Hyper-V … [X] Plateforme Hyper-V »
Vérifier que Powershell est en v5 minimum –> « $PSVersion », et que le module Hyper-V est bien chargé –> « get-module »
Quelles sont les valeurs proposées (en appuyant sur TAB) à la suite de la commande « New-VMSwitch -Name « NAT-VM » -SwitchType » ?
A bientôt
Hello,
« Actuellement, j’ai une machine pfSense qui fait la même chose.. », je voulais dire une machine virtuelle justement installée sur Hyper-V, disposant d’une interface « partagée », donnant accès a l’internet a mes autres VM via un DHCP. Mais je dois souvent la reconfigurer suite a mes trop nombreux changements d’IP pour différents TP!
Je peux donc confirmer disposer d’un W10 PRO (anniversary edition), Hyper-V est bien installé et fonctionnel, et PS devrait être en V5 (impossible de tester pour le moment -> boulot..).
Par ailleurs, je vois dans ta réponse au commentaire précédent que pour avoir un « vrai presse papier », il faudrait utiliser des connexions RDP.. Pourrais-je avoir un peu plus d’infos sur ce point ? 🙂
Le glissé/déposé fonctionne parfaitement si on utilise la connexion bureau a distance, non ?
Merci d’avance pour ta future réponse 🙂
Bonjour,
Dans ce cas, il me faudrait une réponse à la dernière question, Quelles sont les valeurs proposées (en appuyant sur TAB) à la suite de la commande « New-VMSwitch -Name « NAT-VM » -SwitchType » ? (Normalement, External, Internal et NAT).
C’est peut être aussi lié au fait que l’interface a été partagée avant de passer cette commande.
Essayer get-VMSwitch histoire d’afficher l’existant.
Concernant le presse-papier, c’est une « particularité Hyper-V » qui limite les consoles des VM (vmconnect.exe) en comparaison à une connexion à distance classique (mstsc.exe). Microsoft a amélioré cette limitation du presse-papier mais le host ET la VM doivent être sous Windows 8.1 ou +. D’où mon conseil d’utiliser plutot mstsc qui n’a pas les limitations du client vmconnect.
Bonne continuation
Hello,
Désolé du délai. Je n’ai pas « Nat » dans les options proposées. Uniquement Internal, External et Private.
Get-VMSwitch :
Name SwitchType NetAdapterInterfaceDescription
—- ———- ——————————
Eth External External Realtek PCIe GBE Family Controller
WiFi External External Ralink RT3290 802.11bgn Wi-Fi Adapter
Internal Internal
Internal (shared) Internal
Merci pour le temps que tu prends 🙂
Diminou
Effectivement, l’option -SwitchType NAT n’est disponible que sur Windows 10 – 1511. Je viens de corriger l’article pour l’adapter au cas des Windows 10 – 1607 (anniversary update)
Merci pour vos retours
A bientôt
Hehe!
Merci a toi pour cet article et sa mise a jour 🙂
Bonne continuation,
A bientôt!
Diminou
Bonjour,
Je tente désespérément de mettre en place cette connexion NAT entre ma VM sur Hyper-V et mon host et je n’arrive pas à avoir accès à Internet dans ma VM.
J’arrive à faire un ping de ma VM vers ma carte virtuel (ping 192.168.10.10 et ping 192.168.10.1) et aussi un ping vers mon IP de ma carte WI-FI physique.
J’ai l’impression que la dernière mise à jour de Windows 10 Creators Update (1703) ne supporte plus cette configuration.
Merci pour votre avis.
Bonjour Olivier,
J’étais un peu en retard sur ma maquette des tests 🙁 Je viens d’appliquer la mise à jour 1703 Creators Update et le NAT Hyper-V fonctionne sans souci particulier (Ma config est toutefois en filaire). Est-ce que le plan d’adressage du wifi est correct ? Que renvoie une commande du genre « tracert 8.8.8.8 » coté VM (et coté Host) ?
Que renvoient les commandes Get-NetIPAddress, get-NetNat ? Est-ce qu’une connexion de VM sur un switch externe (associé au WiFi) donne l’accès Internet pour la VM ?
Il est vrai que je n’ai pas encore tenté une reconfiguration en repartant de zéro mais je ne pense pas que ce symptôme provienne de la mise à jour (bien qu’il y ai eu des petits ajustements Hyper-V dans cette version)
Bon courage
Bonsoir Christophe,
Tout d’abord merci pour le retour !
Mon Wifi est en 192.168.0.x avec une passerelle en 192.168.0.254 (une Freebox).
Le tracert sur mon PC donne ceci:
PS C:\WINDOWS\system32> tracert 8.8.8.8
Détermination de l’itinéraire vers google-public-dns-a.google.com [8.8.8.8]
avec un maximum de 30 sauts :
1 * * * Délai d’attente de la demande dépassé.
2 * * * Délai d’attente de la demande dépassé.
3 * * * Délai d’attente de la demande dépassé.
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 * * * Délai d’attente de la demande dépassé.
7 2 ms 2 ms 2 ms google-public-dns-a.google.com [8.8.8.8]
Sur la VM, les 30 sauts sont en « Délai d’attente de la demande dépassé. »
PS C:\WINDOWS\system32> Get-NetIPAddress
IPAddress : fe80::99a0:85ef:cc29:b78%8
InterfaceIndex : 8
InterfaceAlias : Ethernet 3
AddressFamily : IPv6
Type : Unicast
PrefixLength : 64
PrefixOrigin : WellKnown
SuffixOrigin : Link
AddressState : Deprecated
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
IPAddress : fe80::ffff:ffff:fffe%16
InterfaceIndex : 16
InterfaceAlias : Teredo Tunneling Pseudo-Interface
AddressFamily : IPv6
Type : Unicast
PrefixLength : 64
PrefixOrigin : WellKnown
SuffixOrigin : Link
AddressState : Deprecated
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
IPAddress : ::1
InterfaceIndex : 1
InterfaceAlias : Loopback Pseudo-Interface 1
AddressFamily : IPv6
Type : Unicast
PrefixLength : 128
PrefixOrigin : WellKnown
SuffixOrigin : WellKnown
AddressState : Preferred
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
IPAddress : fe80::c1bc:7706:f458:a381%11
InterfaceIndex : 11
InterfaceAlias : Connexion au réseau local* 2
AddressFamily : IPv6
Type : Unicast
PrefixLength : 64
PrefixOrigin : WellKnown
SuffixOrigin : Link
AddressState : Deprecated
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
IPAddress : 192.168.10.1
InterfaceIndex : 23
InterfaceAlias : vEthernet (NAT-VM)
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Manual
SuffixOrigin : Manual
AddressState : Preferred
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
IPAddress : 127.0.0.1
InterfaceIndex : 1
InterfaceAlias : Loopback Pseudo-Interface 1
AddressFamily : IPv4
Type : Unicast
PrefixLength : 8
PrefixOrigin : WellKnown
SuffixOrigin : WellKnown
AddressState : Preferred
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
IPAddress : 169.254.163.129
InterfaceIndex : 11
InterfaceAlias : Connexion au réseau local* 2
AddressFamily : IPv4
Type : Unicast
PrefixLength : 16
PrefixOrigin : WellKnown
SuffixOrigin : Link
AddressState : Tentative
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
IPAddress : 192.168.0.42
InterfaceIndex : 14
InterfaceAlias : Wi-Fi
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Dhcp
SuffixOrigin : Dhcp
AddressState : Preferred
ValidLifetime : 11:26:00
PreferredLifetime : 11:26:00
SkipAsSource : False
PolicyStore : ActiveStore
PS C:\WINDOWS\system32> get-NetNat
Name : NAT-VM
ExternalIPInterfaceAddressPrefix :
InternalIPInterfaceAddressPrefix : 192.168.10.0/24
IcmpQueryTimeout : 30
TcpEstablishedConnectionTimeout : 1800
TcpTransientConnectionTimeout : 120
TcpFilteringBehavior : AddressDependentFiltering
UdpFilteringBehavior : AddressDependentFiltering
UdpIdleSessionTimeout : 120
UdpInboundRefresh : False
Store : Local
Active : True
Oui, via un switch externe j’ai accès à Internet sur la VM après avoir reconfiguré la carte réseau.
Merci pour votre avis
Bonjour,
Bizarre ce résultat du tracert sur le WiFi. Cela ressemble à un problème de routes.
Chez moi, avec le même adressage, le tracert à partir de ma vm me renvoie bien l’itinéraire, dont la patte interne du NAT en premier (192.168.10.1) suivi de l’adresse de la freebox (192.168.0.254) puis les autres routeurs Internet….
Est-ce que les passerelles sont bien configurées, sur le bon réseau. Il faudrait vérifier les tables de routage (route print), vérifier qu’il n’y a pas plusieurs routes par défaut (0.0.0.0) et/ou essayer de désactiver la carte LAN (qui est en APIPA 169.254…). Ou à l’inverse, essayer de passer par le LAN plutôt que le WiFi (Peut être un souci dans la conf. du driver ou l’outillage associé ?) – A vérifier s’il n’y a pas aussi un pare-feu/antivirus/proxy ou un autre équipement réseau qui pourrait interférer dans le routage vers Internet.
A noter qu’il est possible de configurer plusieurs switches virtuels, typiquement « Externes » et les associer distinctement à chaque interface (ie « SW HV Ext LAN » et « SW HV Ext WiFi »).
Bon courage
Bonsoir,
Oui effectivement bizarre ….
Donc en partant sur le principe que ce problème était isolé à mon environnement, j’ai fini par trouver la cause de mon problème…
Je n’ai pas vraiment l’explication … mais j’ai un conflit avec le client Stonesoft VPN Client 6.0 installé sur mon host.
Donc pour le moment j’arrive à avoir quelque chose qui fonctionne en désactivant ce client VPN, donc mon problème est partiellement réglé.
Je vais maintenant chercher si il y a une possibilité de faire cohabiter ces 2 process.
Merci pour ce très bon article !