VPN On-Premise-to-Azure für kleine Unternehmen
IPSEC-VPN mit Bordmitteln einrichten
Fast alle Unternehmen, die eine Cloud-Einführung planen oder vollzogen haben finden sich unabhängig vom IT-Geschäfts-/Betriebsmodell in einem hybriden Szenario wieder. Dabei geht es dem einen primär darum, das eigene Rechenzentrum sicher in die Cloud auszudehnen, um bei Bedarf Compute-Kapazität aus der Cloud zu nutzen, andere zielen primär auf die dauerhafte Nutzung öffentlicher Cloud-Dienste wie M365 oder öffentlich zugänglicher Azure-Services ab, wollen aber nicht von den Unwägbarkeiten einer öffentlichen Internet-Leitung abhängig sein.
Azure bietet zahlreiche Möglichkeiten, eine standardisierte (IPSEC) Standortvernetzung zu realisieren. Ein Blick in den Azure-Markplatz verdeutlicht das, wenn du nach „VPN“ suchst.
Die meisten davon basieren auf virtuellen Maschinen (IaaS), d. h. Nutzer müssten sich dann nicht nur um Updates und Wartung kümmern, sondern auch um eine hochverfügbare Anwendungs-Architektur auf Basis von Azure-VMs und außerdem über die benötigten Lizenzen des Drittanbieters verfügen. Für die ON-Premise-Seite würde natürlich das Gleiche gelten. Damit wir uns hier nicht in unzähligen denkbaren Szenarien verlieren, fassen wir KMUs als Zielgruppe ins Auge, d. h. wir rücken eine möglichst kostengünstige Lösung ins Zentrum unserer Betrachtungen.
Azure-seitig solltest du aber trotzdem nicht auf die Vorteile einer PaaS-Lösung wie „Azure Gateway für virtuelle Netzwerke“ verzichten, kannst dich aber bzgl. der Kosten im Rahmen der angebotenen SKUs (eine vollständige Übersicht findest du in der Dokumentation im Abschnitt https://learn.microsoft.com/de-de/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings Informationen zu VPN Gateway-Einstellungen) für einen kleinen Typ wie z. B. „VpnGw1“ entscheiden. Die SKU „VpnGw1“ bietet z. B. einen Gesamtdurchsatz von 650 MBit/s und unterstützt maximal 30 Site-to-Site, 250 Point-to-Site-Verbindungen mit OpenVPN oder 128 Point-to-Site-Verbindungen mit Microsofts SSTP-Protokoll. Der PaaS-Dienst besteht intern immer aus 2 Knoten und erlaubt so einen Active-/Active- oder Active-/Passive ((Failover)-Betrieb und unterstützt IKEv2 und BGP, womit das verwaltetet VPN-Gateway alle heute relevanten Anforderungen erfüllt. Die Kosten belaufen sich für den Betrieb in Deutschland auf monatlich ca. 129 Euro. Zusätzlich berechnet Microsoft 0,015 €/Stunde für jeden aktiven S2S-Tunnel, sowie 0.010 € für jeden P2S-Tunnel.
Für eine Site-to-Site-Standortvernetzung benötigst du zwei weitere Azure-Ressourcen, ein „Local Network Gateway“, sowie ein Gateway-Subnet. Erstes spiegelt quasi das lokal verwendete Gateway (Checkpoint, Palo Alto, Juniper, Windows Server etc.) in Azure wider und wird mit der öffentlichen IP-Adresse des On-Premise-Gerätes sowie den privaten Adressraum des zu anzuschließenden lokalen Netzwerks konfiguriert.
Microsoft stellt eine https://learn.microsoft.com/de-de/azure/vpn-gateway/vpn-gateway-about-vpn-devices Liste getesteter, also offiziell unterstützter Hersteller von Hard- und Software-Lösungen/Appliances bereit.
Das Gateway-Subnet ist ein spezielles Subnetz, in dem der PaaS-Dienst die zugehörigen Gateway-VMs bereitgestellt und das automatisch mit den erforderlichen VPN-Gateway-Einstellungen konfiguriert wird.
IPSEC-VPN: Bereitstellung-Workflow
Für das Bereitstellen einer Site-to-Site-Standortvernetzung musst du folgende Schritte in der angegebenen Reihenfolge ausführen.
- Bereitstellen des virtuellen Netzwerkwerks in Azure mit Workload-Subnetz und Gateway-Subnetz, ggf auch im Rahmen einer Hub-And-Spoke-Architektur, in der mittels VNet-Peering mehrere Azure-VNets das gleiche Azure-VPN-Gateway verwendenden können.
- Bereitstellen des Azure VPN-Gateways mit der gewünschte SKU und einer neuen öffentlichen IP-Adresse im in 1. erstellten Gateway-Subnetz
- Bereitstellen des Azure Local-Network-Gateways mit der öffentlichen IP-Adresse des lokal bereitstehende VPN-Gateway unter Angabe des lokalen Netzwerks, das mit dem Azure VNet verbunden werden soll
- Initiales Konfigurieren des lokalen VPN-Gateways mit dem für das Azure-VPN-Gateway passenden Einstellungen
- Einrichten einer Site-to-Site-VPN-Verbindung im Azure-VPN-Gateway mit den gewünschten Tunnel/Verschlüsselungs-Parametern, wie z. B. IKEv2 und Preshared Key
- Fertigstellen der Konfiguration des lokalen VPN-Gateways.
Beginne mit der Bereitstellung des VPN-Gateways in Azure. Erstelle dazu zunächst ein virtuelles Netzwerk oder wähle das gewünschte bestehende virtuellen Netzwerk aus und klicke unter „Einstellungen / Subnetze“ auf „+ Gatewaysubnetz“, um ein solches zu erstellen. Für die Größe des Adressraums reichen /27 oder /28 völlig aus, da du nur für jede Knoten-VM eine oder maximal zwei IP-Adressen benötigst. Danach kannst du dein erstes VPN-Gateway in Azure erstellen. Suche dazu im Azure Portal nach „Gateways für virtuelle Netzwerke“.
Zur initialen Bereitstellung wähle dein Azure-Abonnement, eine Ressourcen-Gruppe, die Region, in der sich das „richtige“ virtuelle Netzwerk befindet, in welchem du zuvor deine Gateway-Subnet erstellt hast, den Gateway-Typ „VPN“ und die gewünschte SKU. Außerdem musst du im Abschnitt „Öffentliche IP-Adresse“ eine solche erstellen und kannst dann noch entscheiden, ob du das Gateway um Active-/Active oder Active-/Passive-Betrieb erstellen möchtest und ob Router über das BGP-Protokoll propagiert werden sollen oder nicht. Beachte, dass die Bereitstellung des Gateways bis zu 40 min in Anspruch nehmen kann. Unmittelbar danach kannst du das lokale Netzwerkgateway in der gleichen Region und Ressource Group bereitstellen.
Gib bei „IP-Adress“ die öffentliche IP-Adresse deines lokalen VPN-Gateways an und bei „Adressraum/-räume“ den privaten Adressraum des lokalen Netzwerks, das du mit deinem Azure-Netzwerk verbinden möchtest. Auch diese Bereitstellung nimmt etwas Zeit in Anspruch, dauert aber nicht so lange wie beim VPN Gateway. In der Zwischenzeit kannst du dich der Konfiguration deines On-Premise-Gateway-Gerätes widmen. Diese ist naturgemäß höchst spezifisch für den jeweiligen Hersteller, wenngleich die Begrifflichkeiten und prinzipiellen Konfigurationsmaßnahmen dem versierten Netzwerktechniker vertraut sein sollten. Zudem leistet Microsoft hier Unterstützung durch Verlinkung der jeweiligen Konfigurationshandbücher auf der oben erwähnten Seite „Informationen zu VPN-Geräten und IPsec-/IKE-Parametern für VPN-Gatewayverbindungen zwischen Standorten“. Für dieses Beitrag verwenden wir einen standardmäßigen Windows-Server, der alle erforderlichen Bordwerkzeuge mitbringt, um einen Windows Server zu einem VPN-Gateway auszubauen, insbesondere weil dies im Rahmen unserer angestrebten Zielgruppe die mit Abstand kostengünstigste Lösung ist, sofern du in deinem Unternehmen über eine öffentliche IP-Adresse verfügst.
Windows Server Remote Access einrichten
Es versteht sich von selbst, dass du in der Praxis die Remote Access Dienste auf einem dedizierten Member-Server installierst und keinesfalls auf einem Domain Controller. Im Normalfall sollte ein solcher Server in der DMZ, bzw. Umkreisnetzwerk stehen. Auf die Firewall-Anforderungen zwischen deiner DMS und dem lokalen Netzwerk gehen wir hier nicht weiter ein.
Öffne dann den Server Manager und starte den Assistenten „Add Roles and Features“, wähle bei „Installationstyp“ den Eintrag „rolebased or featurebased Installation“ sowie den gewünschten Zielserver und suche nach dem Feature „Remote Access“.
Wähle im Schritt „Select role service“ den Eintrag „Direct Access and VPN (RAS)“ und klicken auf „Add Features“
Warte nun die Feature-Installation ab und öffne anschießend im Server Manager das Werkzeug „Routing and Remote Access“.
Hier navigiere zum noch nicht konfigurierten Server und wähle im Kontextmenü den Eintrag „Configure and Enable Routing and Remote Access“, um den Assistenten „Routing and Remote Access Server Setup Wizard“ zu starten. Klicke dann auf „Next“ und wähle im Schritt „Configuration“ den Eintrag „Secure Connection between two private networks“.
Im nächsten Schritt „Demand-Dial Conncetions“ belasse den Default-Eintrag „Do you wanr to user demand-dial connections to access remote networks? auf „Yes“ und klicke erneut auf „Next“. Gleiches gilt für den nächsten Schritt „IP Adress Assigment“. Belasse auch hier den Default-Eintrag „Automatically“ und beende den Assistenten mit „Next“ und im nächsten Schritt „Completing the Routing and Remote Acess…:“ auf „Finish“. Dies triggert wiederrum den nächsten Assistenten „Demand-Dial Interface Wizward“.
Hier klicke erneut auf „Next“, vergib im nächsten Schritt „Interface Name“ einen beliebigen Namen für dein IPSEC-Interface, z. B. „AzureS2S“ und klicke auf „Next“. Im nächsten Schritt „Connection Type“ wähle den Eintrag „Connect using virtual private networking (VPN)“ und klicke auf „Next“.
Im nächsten Schritt „VPN-Type“ erfolgt die entscheidende Konfiguration. Hier wähle den Eintrag „IKEv2“, klicke jetzt nicht auf „Next“, weil du erst die entsprechende „Gegenstelle“ passend vorbereiten musst.
VPN-Verbindung einrichten
Pausiere nun die Bereitstellung deines Windows-Server-basierten VPN-Gateways und wechsle wieder ins Azure Portal und dort in dein VPN-Gateway. Erstelle dort unter „Verbindungen“ eine neue „VPN-Verbindung“, wozu du im ersten Tab des Assistenten „Verbindung erstellen“ neben Abonnement und Ressourcen Gruppe den „Verbindungstyp“ „Standort-zu-Standort (VPN)“ auswählst. Lege im zweiten Schritt „Einstellungen“ die beiden Verbindungspartner („Gateway für virtuelle Netzwerke“ und „Lokales Netzwerkgateway“) fest. Beide kannst du in den entsprechenden Drop-Down-Listen auswählen, da du beide zuvor angelegt hast. Bei „Gemeinsam verwendeter Schlüssel (PSK)“ den gewünschten (im echten Leben ausreichend komplexen) Pre-Shared-Key fest und wähle bei „IKE-Protokoll“ die Option „IKEv2“. Die übrigen Optionen kannst du bei den Default-Werten belassen. Auf BGP verzichten wir in diesem Beispiel.
Remote-Access-Server fertigstellen
Nun wechsele zurück zu deinem Windows-Server und setze den „Demand-Dial“-Wizard fort, indem du im Schritt „Destination Adress“ die öffentliche IP-Adresse deines Azure-VPN-Gateway einträgst.
Im nächsten Schritt „Protocols and Security“ belasse die Default-Einstellung bei „Route IP packets on this interface“. Im Folgeschritt „Static Routes für Remote Networks“ musst du mit „Add“ eine statische Route definieren, um das gewünschte Azure-Netzwerk „hinter“ dem Azure-VPN-Gateway zu erreichen. Da die Dialoge dieses Assistenten noch aus NT-Zeiten stammen, kannst du hier keine CIDR-Notion verwenden, sondern musst die Subnetzmaske manuell eintragen, ebenso eine Metric, damit diese Route den entsprechenden Vorrang genießt.
Klicke erneut auf „Next“. Im nächsten Schritt „Dial-Out Credentials“ trage einfach nur bei „User name“ irgendeinen Namen zur Identifikation ein, denn du benötigst keine Dial-Out-Credentials, da du die Verbindung später über IKEv2 und PSK herstellst.
Du kannst dieses Assistenten jetzt beenden und wechsel dann im Tool „Routing and Remote Access“ beim erfolgreich konfigurierten VPN-Server im Knoten „Network Interfaces“ zum eben konfigurierten Interface mit dem von dir konfigurierten Namen, hier „AzureS2S“. Dort wähle im Kontextmenü den Eintrag „Properties“, um die fehlenden Verbindungseinstellungen zu konfigurieren.
Wechsele dort zum Tab „Security“, wähle bei „Type“ den Eintrag „IKEv2“ und unten im Abschnitt „Authentication“ die dritte Option „Use preshared certificates“. Du musst nur noch deinen bei der Azure-VPN-Gateway-Verbindung hinterlegten PSK eintragen und dann auf „OK“ klicken.
Anschließend navigiere erneut zum eben angepassten Interface und klicke im Kontextmenü auf „Connect“, worauf hin die Verbindung in wenigen Sekunden zustande kommen sollte, d. h. der „Connection State“ auf Connected“ wechseln sollte.
Prüfe nun den Erfolg auf der Azure-Seite. Es kann allerdings ca. 5 min dauern, bis der Status in deinem VPN-Gateway bei „Verbindungen“ ebenfalls auf „Verbunden“ wechselt. Du kannst die Azure-Entität „Verbindungen“ übrigens auch direkt im Azure-Portal suchen und musst nicht erst in VPN-Gateway wechseln.
Auch im Blade “Lokale Netzwerkgateways” sollte inzwischen unter „Verbindungen“ eine neue Verbindung im Status „Verbunden“ aufgetaucht sein.
Du kannst jetzt prüfen, ob du z. B. eine Azure-VM über deren private IP-Adresse aus deinem lokalen Netzwerk heraus erreichen kannst, z. B. per „ping“ (ICMP) oder RDP. Beachte aber, dass die gewünschten Layer-3-Protokolle (ICMP) und/oder Layer-4-Zielports (3389 für RDP) auch in der entsprechenden Azure-Security-Group, sowie in der Windows-Firewall des Gastsystems geöffnet sein müssen.
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie