Site-to-Site VPN zwischen Clouds

(this article is also available in english)

Nachdem Microsoft Azure Deutschland ja eine separate Instanz der Azure Cloud ist, mit unterschiedlichen Subscriptions, Rechenzentren, und auch ohne Verbindung zum Backbone, stellt sich die Frage, ob und wie man eine Azure Umgebung netztechnisch mit Azure Deutschland verknüpfen kann. Und genau das soll Thema dieses Blogposts sein.

Um Netze nach und in Azure zu koppeln gibt es grundsätzlich mal 4 Verfahren:

  • VNet Peering
  • VNet-to-VNet (V2V)
  • Site-to-Site (S2S)
  • ExpressRoute(s) (nur der Vollständigkeit halber hier, würde aber zu weit führen)

Schauen wir uns also die Möglichkeiten mal an...

VNet-Peering

Eine Voraussetzung für VNet-Peering ist, dass sich beide VNets in derselben Region befinden. Da dies bei AZure und AZure Deutschland offensichtlich nicht der Fall ist, müssen wir das hier auch nicht weiter betrachten. Wen VNet-Peering trotzdem interessiert, der findet hier einen tollen Artikel dazu.

VNet-to VNet (V2V)

VNet-toVnet (V2V) ähnelt dem im folgenden Abschnitt beschriebenen S2S, nur liegen hier beide VNets mit ihren Endpunkten in Azure. Man kann also V2V zum Beispiel verwenden, um Netze in unterschiedlichen Azure-Regionen verbinden zu können, selbst wenn diese in unterschiedlichen Subscriptions angelegt sind (dann halt nur via PowerShell, aber wen stört das schon...). Das Aufsetzen ist super einfach und hier prima beschrieben, aber leider müssen für V2V beide Subscriptions innerhalb der gleichen Azure Umgebung liegen, also beide in Azure oder beide in Azure Deutschland. Damit scheidet V2V für unsere geplanten Zwecke auch aus...

Site-to-Site (S2S)

Normalerweise verwendet man S2S, um zwischen Azure und der lokalen (on-premise) Netzwerkumgebung einen verschlüsselten Tunnel herzustellen. Man vereint beide Netzwerke also zu einem, indem man jeweils ein Gateway definiert und beide mit den Infos versorgt, wo sich der andere Endpunkt befindet und wie man miteinander redet (IPSec Parameter, Adressen etc). Auch hier gibt es eine einfach nachzuvollziehende Anleitung, von der wir hier nur in Stichworten die Reihenfolge der notwendigen Schritte betrachten:

  1. Virtuelles Netzwerk erstellen
  2. Adressraum definieren
  3. Subnetze erstellen
  4. Gateway-Subnetz erstellen
  5. Gateway für VNet erstellen
  6. Gateway für lokales Netz erstellen (quasi der Platzhalter für ihr lokales Gerät)
  7. lokales VPN-Gerät konfigurieren
  8. Verbindung herstellen

Um VNets zwischen Azure und Azure Deutschland zu koppeln, bereitet man in beiden Umgebungen alles vor (Schritt 1-5 aus obiger Liste), um das VNet mit einem normalen VPN-Gerät zu verbinden, und gibt dann einfach die beiden Gateways bei der jeweils anderen Konfiguration als Partner an (Schritt 6). Oder anders ausgedrückt: Statt Schritt 7 wird einfach nochmal Schritt 1-6 in der anderen Umgebung durchgeführt. Man tut also quasi so, als ob der andere Endpunkt ein on-premise Gateway ist. Nachdem beide angelegt sind, führt man Schritt 6 in Azure aus und gibt als Adresse die öffentliche IP des Gateways in Azure Deutschland an, und noch einmal Schritt 6 in Azure Deutschland mit Angabe der öffentlichen IP des Azure-Gateways. Und dann direkt noch Schritt 8, und das war's. ALles klar? Nein? ok, dann hier nochmal:

  • Schritt 1-5 für Azure durchführen
  • Schritt 1-5 für Azure Deutschland durchführen
  • Schritt 6 in Azure mit Eingabe der öffentlichen IP des Gateways in Azure Deutschland (aus dem vorherigen Schritt)
  • Schritt 6 in Azure Deutschland mit Eingabe der öffentlichen IP Adresse des Gateways in Azure
  • verbinden mit Schritt 8 (und Schritt 7 entfällt)

Ab sofort können dann VMs, die man in einem der beiden VNets anlegt, über den IPSec-Tunnel mit ihren IP-Adressen miteinander kommunizieren.

Caveat

Zwischen V2V und S2S gibt es Unterschiede bei den Preisen für Netzwerkverkehr. Bitte unbedingt vorher nachlesen!

Der Tunnel selbst führt über das normale Internet, daher sind Ausfälle oder schwankende Bandbreiten nicht auszuschließen, also genau wie bei S2S-Verbindungen zwischen Azure und on-premise.