Windows Server 2016 und Windows 10: NAT-Switch für Hyper-V
Achtung: Der Inhalt dieses Artikels bezieht sich auf ältere Versionen von Windows Server 2016 bzw. Windows 10 und ist überholt. Eine aktualisierte Fassung dieses Artikels finden Sie hier.
Der Windows Server 2016 und auch die aktuellen 64-Bit Versionen von Windows 10 Pro bringen im Hyper-V neben den bisherigen virtuellen Netzwerk-Switches external, internal und private einen neuen Switchtyp NAT mit. Damit ist es möglich, ohne zusätzliche Komponenten VMs, die mit einem internal Netz verbunden sind, auch mit der Außenwelt bzw. dem Internet kommunizieren zu lassen.
Okay, bei VMware Workstation oder auch VirtualBox gab es diese Funktionalität schon immer. Bei Hyper-V musste man sich jedoch bisher damit behelfen, eine VM als Router zwischen dem internal Netz und einem external Netzwerkadapter des Hyper-V Hosts zu konfigurieren (z.B. über Routing und RAS eines Windows Servers oder über das Internet Connection Sharing). Diesen Aufwand kann man sich jetzt mit dem NAT-Switch sparen.
Leider versteckt sich die Beschreibung dieser Neuigkeit ganz tief in der Technet Library und auch in den Microsoft-Veröffentlichungen zu den jeweiligen Betriebssystemen sucht man vergebens danach. Ich will hier deshalb mal näher beschreiben, wie man damit umgeht.
Voraussetzungen
Der NAT-Switch steht in folgenden Hyper-V Umgebungen zur Verfügung:
- Windows Server 2016 TP4
- Windows 10 pro 64 Bit ab Version 1511 (November 2015 Update, also mindestens Build 10586
Die Hyper-V Rolle muss bereits installiert sein.
Konfiguration nur über PowerShell
Wer nun voller Euphorie im Hyper-V Manager den Manager für virtuelle Switches aufruft, wird enttäuscht feststellen, dass dort von der Neuheit NAT-Switch nichts zu sehen ist.
Die Konfiguration eines NAT-Switch muss nämlich über die PowerShell erfolgen. Hierzu steht jetzt im Cmdlet New-VMSwitch, mit dem schon immer Hyper-V Switches erzeugt werden konnten, beim Parameter –SwitchType zusätzlich die Option NAT zur Verfügung. Bei Auswahl dieser Option muss dann außer dem Namen des Switch noch ein IP-Adressbereich angegeben werden, für den der NAT-Switch Datenpakete nach extern übersetzen / weitergeben soll. Dieser IP-Bereich muss über den Parameter –NATSubnetAddress in CIDR-Form (also xx.xx.xx.xx/mask) angegeben werden.
Beispiel: Für das interne IP-Netz 192.168.80.0 mit Netzmaske 255.255.255.0 (in CIDR Form 192.168.80.0/24) soll ein NAT-Switch mit dem Namen NatSwitch erzeugt werden:
New-VMSwitch -SwitchType NAT -Name NatSwitch -NATSubnetAddress 192.168.80.0/24
Eine Übersicht über die vorhandenen Hyper-V Switches kann man sich anschließend mit dem Cmdlet Get-VMSwitch anzeigen lassen
und man sieht, dass NatSwitch mit SwitchType NAT angelegt ist.
Ruft man wieder den Manager für virtuelle Switches auf, so sieht man den angelegten Switch – allerdings nur als internen Switch.
Ich vermute mal, dass Microsoft in der GUI die Neuheit NAT-Switch einfach noch nicht implementiert hat und dies in einem zukünftigen Release noch ergänzen wird.
Das Cmdlet New-VWSwitch hat – wie für interne Switches üblich – auch einen virtuellen Netzwerkadapter (vNIC) im Hyper-V Host erzeugt und diesem die erste IP-Adresse aus dem bei NATSubnetAddress angegebenen Adressbereich zugewiesen, im Beispiel also 192.168.80.1. Überprüft werden kann dies in den Netzwerkadapter-Einstellungen:
Diese IP-Adresse kann später bei den VMs, die mit dem NAT-Switch verbunden werden, als IPv4-Standardgateway verwendet werden.
Jetzt haben wir also einen neuen virtuellen Switch im Hyper-V angelegt. Aber damit Datenpakete auch übersetzt und weitergeleitet werden können, muss noch eine NAT-Regel in einem NAT-Objekt definiert werden. Hierzu dient das Cmdlet New-NetNat. Es erwartet folgende Parameter:
- Name: Der Name des NAT-Objekts als String. Er kann beliebig gewählt werden.
- InternalIPInterfaceAddressPrefix: Hier ist der IP-Adressbereich anzugeben, für den Datenpakete übersetzt und weitergeleitet werden sollen. Hier muss also die beim Erzeugen des NAT-Switch definierte NATSubnetAddress wieder in CIDR-Form angegeben werden.
- ExternalIPInterfaceAddressPrefix (optional): Hier kann man festlegen, an welche IP-Adresse im Hyper-V Host die Datenpakete weitergeleitet werden sollen. Sofern nur ein physischer Adapter im Host existiert, kann man diese Angabe auch weglassen.
Unser Beispiel würde also wie folgt aussehen:
New-NetNat -Name NAT -InternalIPInterfaceAddressPrefix 192.168.80.0/24
IP-Konfiguration der mit dem NAT-Switch verbundenen VMs
Nachdem wir jetzt einen virtuellen NAT-Switch einschließlich einer NAT-Regel erzeugt haben, können wir im Hyper-V VMs anlegen und diese mit dem NAT-Switch verbinden. Dabei stellt sich die Frage, wie diese VMs ihre IP-Adressen erhalten. Der Hyper-V NAT-Switch enthält nämlich keinen DHCP-Server (wie man dies von anderen Virtualisierungsprogrammen kennt). Wir müssen also die IP-Konfiguration entweder manuell durchführen oder in einer der VMs einen DHCP-Server installieren.
IP-Konfiguration per GUI
Die manuelle IP-Konfiguration können wir wie üblich über die GUI in der VM durchführen. Wichtig dabei ist, eine freie IP-Adresse aus dem Subnetz-Bereich des NAT-Switch zu wählen (im Beispiel 192.168.80.201) und als Standardgateway die IP-Adresse des für den NAT-Switch erzeugten virtuellen Netzwerkadapter im Host anzugeben (im Beispiel 192.168.80.1).
IP-Konfiguration per Powershell Direct
Nachdem unser Host ja unter einem aktuellen Windows 10 oder Windows Server 2016 (siehe Voraussetzungen) läuft, können wir die IP-Konfiguration unserer VMs auch per PowerShell Direct durchführen, vorausgesetzt dass auch in ihnen eine dieser aktuellen Windows Versionen läuft.
Besonders hilfreich ist dies, wenn in der VM kein GUI verfügbar ist wie z.B. bei einer Core Server oder Nano Server Installation.
Um Powershell Direct nutzen zu können, müssen wir die Powershell auf dem Hyper-V Host, auf dem die zu konfigurierende VM läuft, als Administrator starten. Dann können wir eine interaktive Powershell-Sitzung mit dem folgenden Kommando starten:
Enter-PSSession –VMName <VMName>
wobei <VMName> der Name der zu bearbeitenden VM ist, wie er im Hyper-V Manager angezeigt wird. Wichtig: Der interne Computername derVM kann davon abweichen; er lässt sich allerdings in der Poweershell Direct Sitzung ändern!
Der VM können wir jetzt eine IP-Adresse mi dem folgenden Kommando zuzuweisen – bleiben wir bei unserem Beispiel:
New-NetIPAddress -InterfaceAlias „Ethernet“ -AddressFamily IPv4 -IPAddress 192.168.80.20
-PrefixLength 24 -DefaultGateway 192.168.80.1
Praxis-Erfahrungen
Der neue NAT-Switchtyp ist sehr hilfreich und hat tadellos in meiner Testumgebung funktioniert. Damit kann man neu erzeugten VMs ohne großen Aufwand einen Zugriff aufs Internet ermöglichen.
Eine Unschönheit ist mir allerdings aufgefallen:
Hat man einmal einen NAT-Switch für ein internes Subnetz mit New-VMSwitch erzeugt, kann man ihn später wieder entfernen mit dem Cmdlet Remove-VMSwitch. Versucht man anschließend nochmals für das gleiche Subnetz einen VMSwitch mit NAT zu erzeugen, erhält man die folgende Fehlermeldung:
New-VMSwitch -Name NatSwitch80 -SwitchType NAT –NATSubnetAddress …
New-VMSwitch : Failed while adding virtual Ethernet switch connections.
At line:1 char:1
+ New-VMSwitch -Name NatSwitch80 -SwitchType NAT -NATSubnetAddress 192. …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [New-VMSwitch], VirtualizationException
+ FullyQualifiedErrorId : InvalidState,Microsoft.HyperV.PowerShell.Commands.NewVMSwitch
Damit ist dieses Subnetz für weitere NAT-Switches “verloren”. Die Ursache für dieses Fehlverhalten habe ich noch nicht gefunden. Es sieht danach aus, dass das Cmdlet Remove-VMSwitch nicht ganz sauber aufräumt und irgendwo im System noch “Leichen” der ursprünglichen Switch Definition hinterlässt. Eine Anfrage bei Microsoft im Windows 10 Virtualisierungsforum hat zumindest Hinweise für einen Workaround ergeben.
Zunächst sollte man sich die aktuellen IPV4 Interface Definitionen mit dem netsh Kommando anzeigen lassen:
netsh interface ipv4 dump
Man sieht einen Eintrag add address mit der IP-Adresse des gelöschten NAT-Switch. Dieser Eintrag verhindert offensichtlich die Neuanlage eines NAT-Switch für das gleiche IP-Subnetz. Man beachte auch den Namen ethernet_32771. Dieser Name wurde vom System bei Remove-VMSwitch erzeugt (die Ziffern 32771 können auch anders lauten).
Den add address Eintrag kann man jetzt per netsh löschen:
netsh interface ipv4 delete address name=“ethernet_32771″ address=192.168.80.1
Lässt man sich jetzt nochmals die aktuellen IPV4 Interface Definitionen mit netsh interface ipv4 dump anzeigen. sieht man, dass der veraltete Address-Eintrag verschwunden ist. Dem neuen Erzeugen eines NAT-Switch für das “verlorene” Subnetz steht jetzt nichts mehr im Weg.
