How-To: unterschiedliche virtuelle Netze (VNets) in Azure sogar über Subscriptions hinweg verbinden

How-To: unterschiedliche virtuelle Netze (VNets) in Azure sogar über Subscriptions hinweg verbinden

How-To: unterschiedliche virtuelle Netze (VNets) in Azure sogar über Subscriptions hinweg verbinden

How-To: unterschiedliche virtuelle Netze (VNets) in Azure sogar über Subscriptions hinweg verbinden

How-To: unterschiedliche virtuelle Netze (VNets) in Azure sogar über Subscriptions hinweg verbinden

Site to Site VPN Verbindungen vom On-Premise Standort zur Microsoft Azure Cloud sind seit langem möglich und bekannt. Viele Kunden unterhalten jedoch mehrere virtuelle Netze in Microsoft Azure, um die Maschinen und Netzwerke sauber voneinander zu trennen. Trotzdem ist oftmals eine Kommunikation zwischen den Netzen nötig.

Auch wenn eine Firma für verschiedene Kostenstellen mehrere Subscriptions angelegt hat und in diese Netzwerke hinzugefügt hat, konnten die Maschinen in den verschiedenen Netzwerken nicht miteinander kommunizieren.

Für diese Fälle gibt es nun spannende Neuigkeiten. Laut Microsoft ist eines der meistgewünschten Features bei virtuellen Netzen ab sofort verfügbar. Ab sofort ist es möglich, verschiedene V-Nets miteinander zu verbinden.

Gleichzeitig wird noch eine neue Funktion eingeführt – Multisite VPN Verbindungen. Damit können an einem Azure Gateway ab sofort mehrere Verbindungen enden.

Damit sind folgende Szenarien denkbar:

multisite vnetMultiSite VPN-Verbindungen, bei dem mehrere VNets und On-Premise Seite miteinander verbunden werden (Quelle: TechNet)

VNettoVNet

VNet zu VNet Verbindungen zur Verbindung mehrerer VNets innerhalb einer oder zwischen mehreren Subscriptions (Quelle: TechNet)

 

Welche Kosten entstehen durch VNet Verbindungen?

 

Wichtig ist zunächst zu verstehen, dass “Azure interne” VNet zu VNet Verbindungen eigentlich genauso wie externe Verbindungen gehandhabt werden. Soll also VNet1 mit VNet 2 verbunden werden, wird in beiden VNets ein Gateway angelegt, dessen externe IP-Adresse jeweils im anderen VNet hinterlegt wird. Gleiches gilt für die preshared keys (PSKs) der Verbindungen.

Dies bedeutet jedoch auch, dass für die Verbindungen innerhalb von Azure die gleichen Verbindungskosten anfallen, wie für externe On-Premise Verbindungen berechnet werden. Für die VNets selbst fallen deshalb keine Kosten an, wohl aber für das Gateway, für das Microsoft ca. €0.04 pro Gateway Stunde (also ca. €28/Monat) verrechnet.

Hinzu kommen die Data Transfer rates, wobei eingehender Datenverkehr kostenlos ist.  Bei ausgehendem Datenverkehr sind die ersten 5GB pro Monat umsonst, ab dann laufen in europäischen und amerikanischen Rechenzentren ca. 9ct pro GB an Kosten auf.

Das bedeutet jedoch auch, dass bei Multisite VPN-Verbindungen, bei denen mehrere On-Premise Verbindungen an einem Gateway auflaufen, von den Gateway Kosten her keinen Unterschied besteht, da das Gateway nur einmal bezahlt wird.

 

Wie werden MultiSite und VNet zu VNet Verbindungen aufgebaut?

Eigentlich genauso, wie jede andere VPN-Verbindung auch, was am Folgenden Beispiel deutlich wird. Hilfreich ist lediglich, dass sich der Leser dieses Blogeintrags die grundsätzlichen Überlegungen von Azure Lans versteht.

Wir legen zunächst zwei VNets an. Ob sich diese in unterschiedlichen Subscriptions befinden oder nicht, macht im Vorgehen keinen großen Unterschied aus. Danach verknüpfen wir die beiden VNets über eine VPN-Verbindung und ein Gateway in jedem VNet.

Eine typische Aufteilung könnte z.B. wie folgt aussehen:

VNet NameNET IP-Bereichlokaler IP-Bereich DNS-Server IP
 net-ac-1 10.1.1.0/24 192.168.10.0/24 10.1.1.4
 net-ac-2 192.168.10.0/24 10.1.1.0/24 10.1.1.4

Falls unterschiedliche Subscriptions verbunden werden sollen, sollte zunächst für das Testszenario eine Affinity Group pro Abo, ein Speicheraccount und ein DNS-Server angelegt werden. Der DNS-Server ist zwar nicht für die Netzwerkfunktionalität wichtig, wohl jedoch, wenn später in einem der Netzwerke z.B. ein DNS-Server mit AD DC betrieben wird. Für die beiden Netze wird dann jeweils der gleiche DNS-Server angegeben, also z.B. 10.1.1.4. Auch bei gleichen Subscriptions würde dieses Vorgehen nicht schaden und die Trennung schärfen.

Hinweis: Zur Einrichtung von VPN-Verbindungen zwischen unterschiedlichen Netzwerken und zum nachverfolgen der nachstehenden Schritte sind unbedingt die aktuellen Windows Azure cmdlets (Veröffentlichungsdatum 12. Mai 2014) erforderlich. Falls Sie diese noch nicht installiert haben, laden Sie diese zunächst über Microsoft Web PI unter https://azure.microsoft.com/de-de/downloads/ im Bereich Befehlszeilentools – Windows PowerShell herunter und installieren Sie diese.

Die folgenden Schritte werden jeweils für das Netz net-ac-1 gezeigt. Sie sind analog für das Netz net-ac-2 auszuführen, nur dass darin die jeweils anderen Netzwerkbereiche und Keys verwendet werden. Da wir nur einen DNS-Server verwenden wollen, bleibt dieser jedoch gleich!

 

1. Schritt: Zunächst legen wir einen zentralen DNS-Server an. Klicken Sie dazu auf Neu–>Netzwerke und DNS-Server registrieren. Der DNS-Server sollte die erste Server IP-Adresse in einem der beiden Subnets sein, in diesem Beispiel also 10.1.1.4. Achten Sie in dieser Stelle auch auf das richtige Abonnement, damit Ihnen keine unvorhergesehenen Kosten entstehen.

dns-1

2. Schritt: Nun legen Sie das erste Netz mit dem Namen net-ac-1 ein. Klicken Sie dazu wieder auf Neu–> Netzwerk und Benutzerkonfiguriert erstellen. Falls Sie keine vorhandene Affinitätsgruppe verwenden möchten, erstellen Sie an dieser Stelle eine neue. In diese sollten später auch die Server in diesem Netz hinzugefügt werden. Das zweite Netz und die zugehörigen Server bekommen dann eine andere Affinitätsgruppe, um bei Ausfällen unabhängig zu bleiben.

vnet-1

3. Schritt: Wählen Sie nun den in Schritt 1 erstellten DNS-Server aus. Setzen Sie insbesondere den Haken bei ein “Site-to-Site VPN konfigurieren”, um später eine Verbindung zum anderen Netz herstellen zu können. Wählen Sie außerdem aus, dass Sie ein neues lokales Netzwerk erstellen möchten.

vnet-2

4. Schritt: Hier erstellen wir das lokale Netz (das bei uns in Wirklichkeit ein Azure Netz ist). Wir nennen es net-ac-2 und geben den oben dargestellten IP-Adressraum ein. In die IP-Adresse des VPN-Geräts müssen Sie eigentlich die IP des VPN-Endpunktes schreiben. Da wir das Azure Gateway im anderen Netz jedoch noch nicht erstellt haben, geben Sie eine fiktive Adresse ein. Geben Sie jedoch acht, diese später noch einmal zu ändern.

vnet-3

5. Schritt: Im letzten Schritt geben Sie die Adressräume des neuen Netzes net-ac-1 an. Dies können mehrere Subnetze sein. Klicken Sie zuletzt auf Gatewaysubnetz hinzufügen, welches im Anschluss automatisch erstellt wird. Dieses wird für das spätere Gateway (VPN-Endpunkt) dieses virtuellen Netzes verwendet. Nach einem Klick auf den Haken ist die Konfiguration abgeschlossen.

vnet-4

Wenn Sie in der Übersicht auf das neu erstellte Netz net-ac-1 und Dashboard klicken, sehen Sie graphisch die beiden Netzwerke, zwischen denen noch keine VPN-Verbindung eingerichtet wurde.

vnet-5

6. Schritt: Im neuen Netzwerk benötigen wir nun ein Gateway (Achtung, dieses verursacht bereits stündliche Kosten, auch wenn kein Datenverkehr erzeugt wird). Klicken Sie im unteren Bereich des Dashboards auf “Gateway erstellen” und “Dynamisches Routing”. Statisches Routing (oder auch policy based Routing) wird für Site-2-Site Tunnel zwischen Azure Gateways derzeit nicht unterstützt.

vnet-6

Die Erstellung des Gateways dauert ca. 15-20 Minuten.

vnet-7Nachdem das Gateway erstellt wurde, wird dessen IP-Adresse angezeigt. Notieren Sie sich diese, da sie im net-ac-2 als VPN-Endpunkt eingetragen werden muss.

vnet-8

7. Schritt: Notieren Sie sich den PreSharedKey des Gateways, indem Sie im Dashboard des Netzes auf Schlüssel Verwalten klicken.

vnet-9

8. Schritt: Wiederholen Sie obenstehende Schritte mit den (gekreuzten) Daten für net-ac-2 innerhalb der gleichen oder einer anderen Azure Subscription oder Azure Account.

9. Schritt: Sobald die IP des zweiten Azure VPN Gateways bekannt ist und Sie dieses erstellt haben, wechseln Sie im Bereich Netzwerke zu lokale Netze, wählen Sie das lokale Netz net-ac-2 und klicken Sie auf “Bearbeiten”. Geben Sie dann die IP-Adresse des Gateways von net-ac-1 an. Wiederholsen Sie diesen Schritt für das lokale Netz net-ac-1.

vnet-1110. Schritt: Abschließend müssen wir die jeweiligen PreShared Keys den Azure Gateways mitteilen. Dies funktioniert nur über die Azure PowerShell. Installieren Sie dazu die neueste Version, wie vor Schritt 1 dargestellt, da sonst z.B. das Set-AzureVNetGatewayKey cmdlet nicht zur Verfügung steht.

10.1 Starten Sie die Windows Azure PowerShell und verbinden Sie sich zu Azure mit “Add-AzureAccount”. Sie werden gebeten Ihre Zugangsdaten für das Azure Portal einzugeben.

10.2 Falls Sie mehrere Subscriptions besitzen, wechseln Sie zunächst mit “Set-AzureSubscription -SubscriptionName <Name der Subscription>”  zur richtigen Subscription. Falls Sie nicht wissen, wie Ihre Subscriptions heißen, führen Sie zunächst “Get-AzureSubscription” aus.

10.3 Fügen Sie nun mit dem Befehl “Set-AzureVNetGatewayKey -VNetname net-ac-1 -LocalNetworkSiteName net-ac-2 -SharedKey <SharedKey von Gateway des net-ac-2>” den PSK von net-ac-2 zum Gateway von net-ac-1 hinzu.

10.4 Wiederholen Sie 10.3 für net-ac-2.

vnet-10Damit ist die Konfiguration abgeschlossen. Klicken Sie auf dem Dashboard von einem der beiden Netze auf “Verbinden”.

Die Verbindung wird in etwa wie folgt dargestellt:

vnet-12Fügen Sie nun zum testen Maschinen in die beiden Netze hinzu und überprüfen Sie, ob sich diese gegenseitig pingen können und beispielsweise DNS funktioniert.

Viel Spaß beim Netzwerke bauen!

Sie suchen weiteren Informationen zu Microsoft Azure? Schauen Sie auf unserer Produktseite vorbei und kontaktieren Sie uns!

 

Über den Autor

Stefan Zenkel

Stefan Zenkel

Stefan Zenkel hat in vielen Jahren als Microsoft Expert Student Partner umfangreiche Cloud und Infrastruktur Zertifizierungen bis zum Certified Solutions Expert und Certified Trainer absolviert. Heute ist er ein vielgefragter Experte im Microsoft Cloud und Infrastruktur Umfeld, spricht auf namhaften Konferenzen und steht in direktem Kontakt zur Azure Product Group. Im Jahr 2011 gründete er die aConTech Enterprise IT-Solutions GmbH.