Mit Windows Server 2012 R2 führt Microsoft ein built-in NVGRE Gateway ein. Dieses NVGRE Gateway ermöglicht verschiedene Zugriffsszenarien der VMs beziehungsweise auf die VMs. Man hat die Möglichkeit zwischen S2S VPN, NAT oder Direct Routing zu wählen.
Die zentrale Komponente im Zusammenhang mit der Network Virtualization stellt der Virtual Machine Manager dar. Dieser übernimmt das komplette Management, sei es das Policy Management für die Customer Routes, die Lookup Records, die Customer Addresses, die Provider Adresses oder die Einrichtung der VM Networks und Einbindung der NVGRE Gateways.
In diesem Blogartikel werde ich mich mit der Einrichtung und Konfiguration eines Windows Server 2012 R2 NVGRE Gateways mit Direct Routing im SC 2012 R2 VMM befassen. Welche Komponenten werden von Windows Server 2012 R2 und VMM für das hier dargestellte Szenario benötigt?
- Ein Logical Network welches das Erstellen von VM Networks über die Network Virtualization erlaubt. Dazu zählt dann auch ein IP Pool für den Provider Address Space.
- Ein VM Network welches auf dem Logical Network basiert. Dazu zählt dann auch ein IP Pool für den Customer Address Space.
- Einen dedizierten Hyper-V Host, der das NVGRE Gateway hostet.
- Einen Standalone Hyper-V Host oder einen Hyper-V Cluster, der die VMs hostet.
- Eine Windows Server 2012 R2 VM, die als NVGRE Gateway dient. Am besten als Service Template in der VMM Library.
Im ersten Schritt wechselt man in der VMM Konsole in den Bereich Fabric und legt dort ein neues Logical Network an.
In meinem Beispiel habe ich das Logical Network mit dem Namen NVGRE-PAS versehen. Die Network Site wurde ebenfalls als NVGRE-PAS bezeichnet und mit VLAN 0 sowie dem Subnet 192.168.0.0/16 angelegt. Die Network Site Zuweisung bezieht sich dabei auf All Hosts. Danach wird der NVGRE-PAS-EK IP Pool angelegt. Hier muss nur der IP-Adressbereich angegeben werden. Mehr wird nicht benötigt.
Entsprechend muss dieses Logical Network dann auf den NICs der Hosts, ob dedizierter Hyper-V Host für das NVGRE Gateway oder der Hyper-V Cluster für die VMs, aktiviert werden. Verwendet man den Logical Switch im VMM für die Hyper-V Hosts, so braucht man nur die entsprechenden Uplink Port Profiles anzupassen.
Nun wird in den Bereich VMs and Services gewechselt und ein neues VM Network NVGRE-CAS-Direct-EKangelegt, welches auf dem Logical Network NVGRE-PASbasiert. Als Isolation wählt man Hyper-V Network Virtualization IPv4 aus und als VM Subnet habe ich 10.0.2.0/24 mit dem Namen NVGRE-CAS-Direct-EK gewählt. In diesem Schritt wird noch nicht das NVGRE Gateway mit dem VM Network verbunden. Stattdessen erfolgt das Anlegen des Tenant_Direct IP Pools. Hier wird der IP-Adressbereich von 10.0.2.2-10.0.2.254 festgelegt, ebenso das Gateway mit 10.0.2.1. Jetzt folgt die Besonderheit die DNS Server mit den IP-Adressen 10.0.0.1 und 10.0.0.2 befinden sich in meinem Infrastructure Logical Network und sind ohne NVGRE Gateway also nicht aus dem VM Network zu erreichen.
Nachdem die Infrastruktur und grundlegende Komponenten konfiguriert sind, erfolgt nun das Erstellen und Konfigurieren des NVGRE Gateways. Hierbei habe ich mich für ein Service Template mit Windows Server 2012 R2 Datacenter als OS entschieden.
Dieses beinhaltet die allgemeinen Hardwareeinstellungen sowie die Einstellungen für das Betriebssystem wie z.B. Zugangsdaten für den Beitritt in die Domain, Product Key, etc.. Wie in der Grafik zusehen ist, hat das NVGRE Gateway zwei Verbindungen zum VM Network Infrastructure-EK. Normalerweise wird NIC 1 mit dem Management Netzwerk und NIC 2 mit dem externen Netzwerk verbunden. Da beides bei mir aber ein Netzwerk ist, sind die beiden NICs mit demselben VM Network verbunden. NIC 3 wird nicht verbunden, dazu dann später mehr.
Wieso ich mich für ein Service Template und kein VM Template entschieden habe ist schnell erklärt. Mit den Service Templates können direkt Rollen und Features beim Deployment mit installiert werden, so dass hier die benötigten Komponenten wie DirectAccess and VPN (RAS) und Routing ausgewählt sind.
Bevor man jetzt das Deployment des NVGRE Gateways startet, muss noch der dedizierte Hyper-V Host als dedizierter NVGRE Gateway Host deklariert werden. Dies wird über einen PowerShell Cmdlet aus dem VMM PowerShell Module erledigt.
Set-SCVMHost -VMHost gwhv-1.neumanndaniel.local -IsDedicatedToWNVGateway $true
Oder alternativ dazu über die Eigenschaften des Hyper-V Hosts unter dem Reiter Host Access.
Danach kann das Deployment auf diesen Hyper-V Host beginnen. Ist dieses vollständig beendet und ohne Fehler verlaufen, erfolgt die Anmeldung auf dem NVGRE Gateway selber. Hier wechselt man in das Netzwerk- und Freigabecenter und in die Adaptereinstellungen.
Um später das entsprechende Front End und Back End Network leichter einstellen zu können, sollte man die beiden verbundenen NICs umbenennen und entsprechend ihren Aufgaben den passenden Namen vergeben. In diesem Beispiel External und Management. Die bisher nicht verbundene NIC erhält den Namen Tenant. Danach Abmelden und wieder zurück in die VMM Konsole wechseln. Dort geht man in die Eigenschaften der NVGRE Gateway VM unter Hardware Configuration und wählt die nicht verbundene NIC aus.
Ein Klick auf Connected to a VM network und anschließend Browse. Dann unbedingt auf Clear Selection klicken und mit OK bestätigen. Damit ist die NIC mit dem vSwitch aber keinem konkreten VM Network verbunden. Dies erfolgt später in den Einstellungen des VM Network.
Zum Schluss die NVGRE Gateway VM herunterfahren, der NIC eine statische MAC Adresse zuweisen und die VM wieder starten. Dann erfolgt der Wechsel zurück in den Bereich Fabric und unter Network Service fügt man dann das NVGRE Gateway dem VMM hinzu.
Unter Credentials wird entweder ein RunAs Account mit Domain Admin Rechten oder lokalen Adminrechten auf der VM ausgewählt. Dann erfolgt die Eingabe des Connection String.
Der Connection String für ein NVGRE Gateway, welches für Direct Routing verwendet wird, unterscheidet sich von einem NVGRE Gateway für NAT. Für NAT reichen die Parameter VMHost und GatewayVM aus. Für Direct Routing benötigt man noch BackendSwitch, DirectRoutingMode und FrondEndServerAddress.
VMHost=gwhv-1.neumanndaniel.local;GatewayVM=VMGW-1.neumanndaniel.local;BackendSwitch=NVGRE;DirectRoutingMode=True;FrontEndServerAddress=10.0.0.47
Beim Parameter BackendSwitch wird der Logical Switch angegeben, mit dem NIC 3 verbunden ist. In diesem Falle NVGRE. Der Parameter DirectRoutingMode legt fest, ob das Gateway als Forwarding Gateway (Direct Routing) verwendet wird oder nicht. Erfolgt keine Angabe dieses Parameters ist die Standardeinstellung False. Als IP-Adresse für den Parameter FrontEndServerAddress wird bei einem Standalone NVGRE Gateway die IP-Adresse der NIC angegeben, die die Bezeichnung External trägt. Bei einem HA NVGRE Gateway die IP-Adresse des Clusters.
Eine Übersicht der Connection String Parameter habe ich hier zusammengestellt.
-> https://www.danielstechblog.io/sc2012-r2-vmm-connection-string-optionen-nvgre-gateway/
Ein Zertifikat wird in diesem Beispiel nicht benötigt und kann somit übersprungen werden. Unter dem Punkt Provider klickt man auf Test. Hier dürfen keine Fehler auftauchen.
Als Host Group habe ich Cluster ausgewählt. Hierunter befinden sich bei mir alle Hyper-V Cluster. Zum Abschluss den Wizard beenden und das NVGRE Gateway sollte unter Network Service auftauchen. Ist dies der Fall geht man in die Eigenschaften unter Connectivity.
Als Front End Network wird der Adapter External und die Network Site Engelskirchen (Infrastructure) definiert. Für das Backend Network der Adapter Tenant und die Network Site Engelskirchen (NVGRE-PAS). Mit einem Klick auf OK werden die Einstellungen vorgenommen. Im nächsten Schritt wird wieder in den Bereich VMs and Services gewechselt und die Eigenschaften des VM Network NVGRE-CAS-Direct-EK aufgerufen.
Unter Connectivity wird Connect directly to an additional logical network, Direct routing und das so eben verbundene NVGRE Gateway angegeben. Ist die Konnektivität hergestellt, kann eine VM auf dem Hyper-V Cluster, die mit dem VM Network NVGRE-CAS-Direct-EK verbunden ist, bereitgestellt werden. Die bereitgestelle VM erhält automatisch über den IP Pool Tenant_Direct eine IP-Adresse (10.0.2.12) und alle weiteren IP-Konfigurationen.
Damit das Direct Routing auch in beide Richtungen funktioniert, muss auf dem Gateway im Unternehmensnetz eine statische Route für das Subnetz 10.0.2.0/24 auf die Front End Server Adresse des NVGRE Gateways (10.0.0.47) eingerichtet werden.
Sonderfall FRITZ!Box
Hier kommt jetzt der kurze Abstecher in meinen Sonderfall mit einer FRITZ!Box 7330 SL. Dort hatte ich entsprechend die statische Route auf das NVGRE Gateway eingerichtet, aber die Verbindung aus dem isolierten VM Network ins Unternehmensnetz/Internet funktionierte nicht, genauso wenig der andere Weg ins isolierte VM Network. Nach einiger Zeit des Troubleshooting bin ich dem Problem auf die Schliche gekommen. Anscheinend kann die FRITZ!Box nicht direkt mit den Paketen des NVGRE Gateways umgehen, so dass dort ein Windows Server 2012 R2 als LAN Routing Gateway dazwischen geschaltet werden muss. Bisher hatten alle Hyper-V Hosts und VMs die FRITZ!Box (10.0.0.254) als Standard Gateway eingetragen. Genauso der dedizierte Hyper-V Host und das NVGRE Gateway. Mit dem zusätzlichen LAN Routing Gateway (10.0.0.253) habe ich dann das Standard Gateway auf dem NVGRE Gateway angepasst und auf die 10.0.0.253 geändert. Das LAN Routing Gateway hat wie alle anderen Komponenten die FRITZ!Box als Standard Gateway eingetragen. Zum Abschluss fehlten nur noch die Anpassungen an den statischen Routen. Auf der FRITZ!Box wurde die statische Route für das Subnetz 10.0.2.0/24 auf die 10.0.0.253 umkonfiguriert und auf dem LAN Routing Gateway für das Subnetz 10.0.2.0/24 die statische Route zum NVGRE Gateway eingetragen. Danach funktionierte das Direct Routing.
Wie man in dem Screenshot des Test-NetConnection Cmdlet sehen kann wird als erstes das Gateway (10.0.2.1) im isolierten VM Network angesprochen. Danach erfolgt das für die Network Virtualization typische Standard Gateway (10.254.254.2) im Back End. Dann als nächstes das LAN Routing Gateway (10.0.0.253) und zum Schluss die FRITZ!Box (10.0.0.254).
Die Aufnahme in die Domain sowie der anschließende Zugriff auf Ressourcen im Unternehmensnetz erfolgen reibungslos. Somit kann man mittels Direct Routing ohne Einschränkungen im Unternehmensnetz die Vorteile der Network Virtualization nutzen. Dabei sollte man aber beachten das für das Direct Routing Verfahren die Zuordnung von VM Network und NVGRE Gateway 1:1 ist. Das heißt pro VM Network wird für das Direct Routing ein eigenes NVGRE Gateway benötigt.
Abshcließend einige Links zu dem Thema Network Virtualization / NVGRE.
-> Whitepaper Hybrid Cloud with NVGRE (Cloud OS)
http://gallery.technet.microsoft.com/Hybrid-Cloud-with-NVGRE-aa6e1e9a
-> Whitepaper Hybrid Cloud with NVGRE (Cloud OS) Deutsch
http://gallery.technet.microsoft.com/Hybrid-Cloud-with-NVGRE-e56011f4
-> http://technet.microsoft.com/en-us/library/dn282658.aspx#BKMKOptions
-> https://www.danielstechblog.io/windows-server-2012-r2-nvgre-gateway-mit-nat-in-sc2012-r2-vmm/