Im letzten Blogeintrag haben wir uns angesehen, man den route Befehl aus der CMD Shell mit der PowerShell ablösen kann, um Netzwerk Routing Tabellen auszulesen oder hinzuzufügen.
In diesem Blogeintrag schauen wir uns an, wie man unter Windows 10 ein NAT Gateway mit der PowerShell erstellen kann.
NAT ist die Kurzform von Network Address Translation und dient dem Umschreiben der IP Adresse in IP Paketen. Mit dem Windows NAT (genauer ein Source NAT) wird die Adresse des verbindungsaufbauenden Computers umgeschrieben.
Dadurch ist es mit Windows 10 und Hyper-V möglich, dass alle virtuelle Maschinen über das gerade aktive Client Netzwerkinterface das Internet erreichen. Dies ist eine deutliche Erleichterung, wenn man unter Hyper-V eine virtuelle Testumgebung mit einem eigenen Netzwerksegment einrichten möchte. Jede virtuelle Instanz erreicht das Internet (der Windows 10 Client mit Hyper-V schreibt die IP Adresse auf seine eigene um = NAT) und kann so z.B. Microsoft Updates herunterladen oder eine Hybridstellung zu Office 365 etablieren.
Mit passenden FritzBox Portweiterleitungen konnte ich dadurch auf meinem Notebook eine funktionstüchtige Exchange Hybrid Testumgebung einrichten.
Für die "mich interessieren nur die nackten PowerShell Befehle" zuerst alle Befehle in Kurzform - wer es genauer verstehen will, kann dann den restlichen Artikel lesen.
# NetNat für 192.168.222.0/24 - Gateway 192.168.222.254
New-VMSwitch -SwitchName Testlab_222 -SwitchType Internal
Get-NetAdapter | where {$_.name –like “*Testlab_222*”} # IfIndex herausfinden
New-NetIPAddress –IPAddress 192.168.222.254 –PrefixLength 24 –InterfaceIndex 41
New-NetNat –Name NetNat –InternalIPInterfaceAddressPrefix 192.168.222.0/24
Alles noch einmal detailliert:
Zuerst sucht man sich ein freies, privates Netzwerksegment für die VMs aus. Da Router gerne die 192.168.0.0/24 bzw. 192.168.178.0/24 nutzen habe ich mich für das Segment 192.168.222.0/24 entschieden. Als Gateway für die VMs nehme ich die 192.168.222.254.
Danach legt man einen neuen, internen virtuellen Hyper-V Switch mit passenden Namen an. Ich nenne meinen TestLab_222
New-VMSwitch -SwitchName Testlab_222 -SwitchType Internal
New-VMSwitch -SwitchName Testlab_222 -SwitchType Internal Name SwitchType NetAdapterInterfaceDescription ---- ---------- ------------------------------ Testlab_222 Internal
Um schon bestehende VMs auf diesen Switch umzustellen, nutze ich folgenden PowerShell Befehl:
Get-VM | Get-VMNetworkAdapter | Connect-VMNetworkAdapter -SwitchName "Testlab_222"
Get-VM | Get-VMNetworkAdapter | Connect-VMNetworkAdapter -SwitchName "Testlab_222"
Die einzelnen VMs benötigen jetzt jeweils eine freie Adresse auf dem 192.188.222.0/24 Bereich. Als Nameserver nutzte ich die IPs von den Testlab Domain Controllern. Als Gateway wird die 192.168.222.254 eingetragen.
Mit der PowerShell kann man schnell überprüfen, ob alles richtig konfiguriert ist:
Get-VM | Where {$_.state -eq "Running"} | Get-VMNetworkAdapter | FT VMName,SwitchName,IPAddresses -a
Get-VM | Where {$_.state -eq "Running"} | Get-VMNetworkAdapter | FT VMName,SwitchName,IPAddresses -a
VMName SwitchName IPAddresses
------ ---------- -----------
AADC16 Testlab_222 {192.168.222.15, fe80::f9fa:3e61:3d6d:c625}
EX16DAG01 Testlab_222 {192.168.222.11, fe80::d8b7:1d38:3336:427f}
EX16DAG02 Testlab_222 {192.168.222.12, fe80::4962:dfa3:8fb7:f1ac}
SUBTESTDC03_SUB Testlab_222 {192.168.222.3, fe80::e17a:936:399c:de45}
TESTDC01_BBTEST Testlab_222 {192.168.222.1, fe80::845b:48d1:eb28:b9e7}
TESTDC02_BBTEST Testlab_222 {192.168.222.2, fe80::9ced:823a:62ec:fe78}
Als nächstes bekommt die virtuelle Netzwerkkarte von meinem Switch TestLab_222 die Gateway Adresse 192.168.222.254.
Dafür muss ich die Interface Nummer herausfinden:
Get-NetAdapter | where {$_.name -like "*Testlab_222*"}
Get-NetAdapter | where {$_.name -like "*Testlab_222*"}
Name InterfaceDescription ifIndex Status MacAddress
---- -------------------- ------- ------ ----------
vEthernet (Testlab_222) Hyper-V Virtual Ethernet Adapter #2 41 Up 00-15-5D-AA-FA-01
O.K. das Interface hat den Index 41.
Jetzt füge ich diesem Interface die GatewayAdresse 192.168.222.254 hinzu.
New-NetIPAddress -IPAddress 192.168.222.254 -PrefixLength 24 -InterfaceIndex 41
New-NetIPAddress -IPAddress 192.168.222.254 -PrefixLength 24 -InterfaceIndex 41 IPAddress : 192.168.222.254 InterfaceIndex : 41 InterfaceAlias : vEthernet (Testlab_222) AddressFamily : IPv4 Type : Unicast PrefixLength : 24 PrefixOrigin : Manual SuffixOrigin : Manual AddressState : Tentative ValidLifetime : Infinite ([TimeSpan]::MaxValue) PreferredLifetime : Infinite ([TimeSpan]::MaxValue) SkipAsSource : False PolicyStore : ActiveStore IPAddress : 192.168.222.254 InterfaceIndex : 41 InterfaceAlias : vEthernet (Testlab_222) AddressFamily : IPv4 Type : Unicast PrefixLength : 24 PrefixOrigin : Manual SuffixOrigin : Manual AddressState : Invalid ValidLifetime : Infinite ([TimeSpan]::MaxValue) PreferredLifetime : Infinite ([TimeSpan]::MaxValue) SkipAsSource : False PolicyStore : PersistentStore
Als letztes wird das NAT auf dem Client eingerichtet, damit die Datenpakete, die die virtuellen Instanzen aus dem 192.168.220.0/24 Netz an das Gateway schicken, auf die Client-IP umgeschrieben und dann weitergeleitet werden.
New-NetNat -Name NetNat -InternalIPInterfaceAddressPrefix 192.168.222.0/24
New-NetNat -Name NetNat -InternalIPInterfaceAddressPrefix 192.168.222.0/24 Name : NetNat ExternalIPInterfaceAddressPrefix : InternalIPInterfaceAddressPrefix : 192.168.222.0/24 IcmpQueryTimeout : 30 TcpEstablishedConnectionTimeout : 1800 TcpTransientConnectionTimeout : 120 TcpFilteringBehavior : AddressDependentFiltering UdpFilteringBehavior : AddressDependentFiltering UdpIdleSessionTimeout : 120 UdpInboundRefresh : False Store : Local Active : True
Als Test öffne ich auf einer VM eine externe Webseite:
Eh voilà - es funktioniert wie es soll ...
Was denken Sie?