Point-2-Site-VPN-Verbindung von Windows-10-Workstation in Azure VNet
Du hast virtuelle Maschinen in der Azure Cloud und möchtest ohne öffentlichen IP-Adressen zu verwenden mit diesen kommunizieren? Kein Problem. Auch hier ist ein VPN die Lösung. In der Tat gehören solchen Hybrid-Szenarien zu den häufigsten Einsatzbeispielen von Public Cloud Computing und bilden neben Cloud-Speicher oft den ersten Berührungspunkt, den kleine und mittlere Unternehmen mit der Cloud haben.
Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!
Angenommen du brauchst kurzfristig im eigenen Unternehmen Compute-Kapazität, virtuelle Maschinen also, weil du z. B. ein Maschine-Learning-Modell trainierst oder allgemein einen HPC-Workload testest? Warum die dazu benötigten Server kaufen, wenn sie nicht dauerhaft benötigt werden. Das bindet Kapital. OK, virtuelle Maschinen sind auch im eigenen Rechenzentrum schnell bereitgestellt, aber letztendlich muss die physische Kapazität dazu auch gekauft werden. Wie auch immer, Use-Cases für VPNs in ein Azure vNet sind viele denkbar. Ein virtuelles Netzwerk in Azure kann nämlich auch rein auf die Cloud beschränkt bleiben, muss also keine Route zum öffentlichen Internet haben. So kannst du nach Belieben Server in der Cloud platzieren, ohne dass diese aus dem Internet erreichbar wären.
Azure Virtual Network Gateway
Azure stellt zu diesem Zweck den verwalteten Dienst „Gateway für virtuelle Netzwerke“ zur Verfügung mit dem du sehr komfortabel IPSEC-basierende Site2Site und Client2Site-VPNs realisieren kannst. Die Standortvernetzung ist dabei eher für Unternehmen von Interesse, die über ein öffentlich zugängliches Netzwerk und ein vom Site2Site-Dienst unterstütztes VPN-Gerät z. B. von Arista, Checkpoint, Cisco, Fortinet, Juniper, Sophos oder Zyxel verfügen. Hier implementierst du dann eine vollständige IPSEC-Verbindung je nach verendeten Gerätetyp in eigenen Unternehmen ein Richtlinien-basiertes oder Routen-basiertes VPN. Als Privat-Nutzer kannst du mit dem VPN-Dienst von Microsoft aber sehr einfach ein SSL-basiertes P2S-VPN mit Hilfe von Zertifikaten und z. B. Microsofts SSTP-Protokoll herstellen. Dazu gehst du wie folgt vor:
VNET in Azure
Zunächst musst du in Azure das gewünschte virtuelle Netzwerk erzeugen. Wir erstellen dazu in Azure ein virtuelles Netzwerk mit beliebigen Namen (hier „ditdevpnvnet“) mit einem frei wählbaren Adressbereich zwischen /16 und /28. Wir verwenden hier 10.3.0.0/16 für das VNet. Dieses unterteilen wir in drei Subnetze „FronEnd“ (für aus dem Internet erreichbaren virtuelle Server), „BackEnd“ (für die virtuellen Server, die nur via VPN erreichbar sein sollen) und „GatewaySubnet“ für das virtuelle Gateway-Geräte, quasi unsere DMZ. Die beiden Erstgenannten kannst du entweder direkt beim Anlegen des VNets definieren oder später bei bereits erstelltem VNet in der Konsole für den Dienst „Virtuelle Netzwerke“ im Menü „Subnetz“ mit „+Subetz“ manuell anlegen:
Dem „Gatewaysubnetz“ kommt eine besondere Bedeutung zu. Es nimmt letztendlich „virtuell“, bzw. Routing-technisch das virtuelle Netzwerk Gateway von Azure auf, welches letztendlich ein verwalteter Dienst ist. Da dazu die Routen des Default-Gateways für das betreffende (assoziierte) Subnetz angepasst werden müssten, hat Microsoft extra zu diesem Zweck die Funktion „+Gatewaysubnetz“ in das Menü „Subnetze“ eingebaut, das ein passend konfiguriertes Subnetz einschließlich angepasster System-Routen automatisch erstellt, ohne dass du dazu Routingtabellen oder Netzwerk Security Groups erstellen, bzw. anfassen musst. Füge einfach das Gateway-Subnetz mit entsprechend kleinen Host-Anteil (wir verwenden /27) hinzu. Das reicht immer noch für 32 IP-Adressen.
Gateway für virtuell Netzwerke erstellen
Anschließend können wir im Azure Marketplace nach „Gateways für virtuelle Netzwerke“ suchen und ein Solches mit „Hinzufügen“ erstellen. Im Dialog „Gateway für virtuelle Netzwerke“ bedarf es nicht vieler Angaben.
Wie üblich wählt man zunächst das zu verwendende Abonnement und dann die gewünschte Ressource-Gruppe aus, die auch das oben erstellte Subnetz enthält, bzw. in der gleichen Region ist, wie die Subnetze. Dies ergibt sich hier aber indirekt, wenn du die passende Region und dann weiter unten das gewünschte virtuelle Netzwerk auswählst. Dann gibt man dem Gerät einen Namen, wählt als „Gatewaytyp“ den Eintrag „VPN“ und als „VPN-Typ“ den Eintrag „Routenbasiert“ (beides Default).
Schließlich benötigst du eine SKU. Wir verwenden für diese Demo die preiswertestes SKU für Routen-basierende Typen „VpnGw1“ mit „Generation 1“. Diese schlägt in Deutschland (Frankfurt) mit 0,1603 €/Stunde für den generellen Betrieb und 0,0009 €/Stunde mit jedem aktiv genutzten VPN-Tunnel (Verbindung) zu Buche. Die maximal erzielbare Bandbreite ist dann 650 Mbit/s. Alle bisher erstellen Netzwerk-Ressourcen kosten dagegen nichts.
Bei „Virtuelles Netzwerk“ wählt man das oben erstellte Netzwerk aus. Bei „Öffentliche IP-Adresse“ wählst du „neu erstellen“, wähle einen passenden Namen (Alias) für die öffentliche IP-Adresse und belasse die übrigen Werte auf Default. Stimmen alle Angaben klicke auf „Überprüfen und Erstellen“. Achtung: Der Vorgang kann durchaus bis zu 15 min in Anspruch nehmen. Verfolgen kannst du die bei Azure immer Template-basierende Bereitstellung, wenn du im Azure-Portal rechts oben auf die Glocke klickst.
Das Virtual Network Gateway ist damit wie fast jeder andere Dienst in Azure schnell bereitgestellt; „aufregender“ wird es erst bei der Konfiguration. Bevor du dies allerdings tun kannst, musst du die für ein Client-to-Site-VPN benötigten SSL-Zertifikate generieren.
Erzeugen von Zertifikaten
Azure nutzt bei P2S-VPNs Zertifikate für die Authentifizierung der Clients, die eine Verbindung mit einem VNet über eine Point-to-Site-VPN-Verbindung herstellen möchten. Dazu musst du allerdings entsprechende Informationen zum öffentlichen Schlüssel des Stammzertifikates, welches das Client-Zertifikat ausgestellt hat, das auf dem Client installiert ist, der die Verbindung zu Azure initiiert, in Form der zum Stammzertifikat gehörigen CER-Datei (öffentliche Schlüssel) nach Azure hochladen. Dadurch wird das entsprechende Stammzertifikat von Azure als „vertrauenswürdig“ für die Verbindung mit dem virtuellen Netzwerk über eine P2S-Verbindung eingestuft. Das passende Client-Zertifikat generierst du aus dem vertrauenswürdigen Stammzertifikat und installierst es auf dem betreffenden Client-PCs., d. h. das Client-Zertifikat authentifiziert dann den Client, sobald dieser eine Verbindung mit dem VNet initiiert.
Wenn du im folgenden Beispiel ein selbstsigniertes Stammzertifikat auf einem Windows-10-PC erzeugst und diesen auch als Client für die Verbindung zu Azure nutzt, wird das Client-Zertifikat auf diesem auch automatisch installiert. In diesem Fall musst du das Client-Zertifikat nicht erst exportieren, um es auf dem betreffenden Client zu installieren.
Entscheidest du dich wie im Beispiel für ein selbst signierten Stammzertifikates auf einem Windows-PC, kannst du ein solches einfach wie im Folgenden gezeigt via PowerShell erzeugen und exportieren. Der folgende Befehl generiert ein selbstsigniertes Stammzertifikat mit dem Namen P2SRootCert. Dieses wird dabei automatisch in „Certificates-Current User\Personal\Certificates“ installiert. Er setzt aber voraus, dass das Azure-Modul für Power-CLI installiert ist und du mit
Connect-AzAccount
mit deinem Azure-Konto verbunden bist. Dann gib Folgendes ein:
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject „CN=P2SRootCert“ \
-KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation \ „Cert:\CurrentUser\My“ -KeyUsageProperty Sign -KeyUsage CertSign
Danach kannst du wie folgt ein Client(Child)-Zertifikat erzeugen:
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature \
-Subject „CN=P2SChildCert“ -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 \
-CertStoreLocation „Cert:\CurrentUser\My“ -Signer $cert -TextExtension \ @(„2.5.29.37={text}1.3.6.1.5.5.7.3.2“)
Sofern du den gleichen PC auch tatsächlich als Client nutzt, bist du schon fertig, denn das Client-Zertifikat wird automatisch auf diesem installiert. „Sehen“ kannst du dann beide im Cert-Manager (certmgr.msc). Du findest das grafische Windows-Tool unter C:\Windows\System32\de-DE\certmgr.msc. Navigiere dort um Ast „Eigene Zertifikate / Zertifikate.
Jetzt musst du nur noch den öffentlichen-Schlüssel des Stamm-Zertifikats (nicht den Privaten) exportieren. Dies erledige bei markiertem Stamm-Zertifikat (hier „PSRootCert“) im Kontextmenü „Alle Aufgaben / Exportieren.
Klicke dort auf „Weiter“ und dann unbedingt auf „Nein, privaten Schlüssel nicht exportieren2. Nun wähle im Zertifikatexport-Assistent den Eintrag „Base-64-codiert X.500“.
Wähle dann einen gewünschten Speicherort und speichere den Schlüssel und einem beliebigen Namen ab z. B. „rootcertificate.cer“.
Virtual Network Gateway konfigurieren
Nun kannst du das Virtual Network Gateway konfigurieren. Wechsle dazu im Azure Portal im oben erstellten Gateway zum Abschnitt „Einstellungen / Punkt-zu-Standort-Konfiguration“ und klicke auf „Jetzt konfigurieren“. Nun gib bei „Adresspool“ einen Adress-Pool ein, aus dem die anfragenden Clients mit eine IP-Adresse versorgt werden. Dieser muss uns sollte auch nichts mit dem IP-Adress-Bereich eines der Subnetze zu tun haben. Wir wählen „172.16.30.0/24“. Jetzt müssen wir nur noch bei „Stammzertifikate“ den Namen des Stammzertifikates angeben und dann den Inhalt (Wert) des vorhin exportierten Zertifikats mit Hilfe der Zwischenablage in das Feld „Daten des öffentlichen Zertifikats“ einfügen. Im Feld bei „Tunneltyp“ wähle im Falle eines Windows-Clients am besten „SSTP (SSL)“, weil das die Installation samt Konfiguration des VPN-Clients extrem vereinfacht.
Klicke nun auf „Speichern“ und danach rechts oben auf „VPN-Client herunterladen“.
Je nach gewählten Tunneltyp kannst, bzw. musst du hier eine Client-Software (z.B. Open-VPN) einschließlich Konfiguration oder nur eine Konfiguration (wenn Sie eine eigene Client-Software verwenden) herunterladen. Im Falle SSTP genügt es, das heruntergeladene ZIP-Archiv mit dem Namen des Gateways (hier „ditdevpngw1.zip“) in einem beliebigen Ordner abzuspeichern und zu entpacken.
Im Archiv findet sich ein Unterordner für jede Plattform. Hier wähle z. B. „WindowsAMD64“. Darin findet sich eine Datei „VpnClientSetupAmd64.exe“, die du einfach nur doppelklicken musst. Öffnet sich dabei der Dialog „Der Computer wurde durch Windows geschützt“ klick rechts oben auf das „X“ für Schließen. Ist das geschehen findest du bei Windows 1o im „Netzwerk- und Interneteinstellungen öffnen“-Systray unter „VPN“ eine fertig eingerichtete neue VPN-Verbindung mit dem von dir gewählten Namen.
Klicke diese an und dann auf „Verbinden“, öffnet sich der „Windows Azure Virtual Client“. Klicke auch hier auf „Verbinden“ baut Windows-10 eine SSL-gesicherte Verbindung via SSTP in Ihre Azure-VNet auf.
Zur Kontrolle gib in der CMD „ipconfig“ ein. Du wirst feststellen, dass der Windows-PC einen PPP-Adapter mit einer IP-Adresse aus dem oben gewählten Adresspool erhalten hat. Hättest du nun virtuelle Maschinen in deinem Azure-FrontEnd- oder BackEnd-Subnetz, könntest du diese direkt auf deiner jeweiligen privaten IP-Adresse erreichen.
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie