P2S-Verbindung zwischen Windows 10 und Azure Point-to-Site-VPN mit Microsoft VNET

Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

Eine Point-to-Site- oder kurz P2S-VPN-Verbindung schützt die Kommunikation mit PaaS-Diensten. Wie Developer eine solches VPN zwischen Windows-10-Client und Azure Cloud schnell bereitstellen kann, zeigt folgender Beitrag.

Firma zum Thema

Das „Gatewaysubnetz“ ist ausschließlich für das virtuelle Azure-Gateway bestimmt, das seinerseits ein verwalteter Dienst ist.
Das „Gatewaysubnetz“ ist ausschließlich für das virtuelle Azure-Gateway bestimmt, das seinerseits ein verwalteter Dienst ist.
(Bild: Drilling / Microsoft)

Entwickler und Entwicklerinnen nutzen für Test-Szenarien zunehmend Backend-Dienste in der Cloud, beispielsweise eine relationale Datenbank „as a Service“, um einfache Schnittstellen-Tests durchführen zu können. Doch gerade bei Verbindungen zwischen On-Premises-Servern und Cloud-PaaS ist es oft nicht erwünscht, dass diese wie in der Public Cloud üblich über öffentliche IP-Adressen und das Internet laufen.

Abhilfe schafft eine Point-to-Site-Verbindung (P2S VPN), beispielsweise zwischen einem Windows-10-Client und Microsoft Azure. Derartige Hybrid-Szenarien sind in der Public Cloud häufig anzutreffen und bilden neben der Nutzung von Cloud-Speicher für viele Entwickler den ersten Berührungspunkt mit der Cloud.

Azure Virtual Network Gateway

Azure stellt zu diesem Zweck einen verwalteten Dienst „Gateway für virtuelle Netzwerke“ zur Verfügung mit dem Sie sehr komfortabel IPSEC-basierende Site-to-Site und Client-to-Site-VPNs realisieren können. Die Standortvernetzung richtet sich an Unternehmen, die über ein öffentlich zugängliches Netzwerk und ein vom Site-to-Site-Dienst unterstütztes VPN-Gerät z. B. von Arista, Checkpoint, Cisco, Fortinet, Juniper, Sophos oder Zyxel verfügen. Entwickler können mit dem Dienst aber auch schnell und einfach ein SSL-basiertes P2S-VPN mit Hilfe von Zertifikaten und z. B. Microsofts SSTP-Protokoll einrichten.

VNET in Azure

Dazu müssen Sie in Azure zunächst das gewünschte virtuelle Netzwerk erzeugen. Erstellen Sie dazu in Azure ein virtuelles Netzwerk mit beliebigen Namen mit einem frei wählbaren Adressbereich zwischen /16 und /28, z. B. 10.3.0.0/16 für das VNet. Dieses unterteilen Sie in drei Subnetze …

FrontEnd – 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, sozusagen ihre DMZ in der Cloud.

Oberfläche zum Definieren der Subnetze.
Oberfläche zum Definieren der Subnetze.
(Bild: Microsoft / Drilling)

Die beiden erstgenannten können Sie 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 ist ausschließlich für das virtuelle Netzwerk Gateway von Azure bestimmt, das seinerseits ein verwalteter Dienst ist.

Da dazu die Routen des Default-Gateways für das betreffende (assoziierte) Subnetz angepasst werden müssten, hat Microsoft die Funktion „+Gatewaysubnetz“ in das Menü „Subnetze“ eingebaut. Darüber lässt sich ein passend konfiguriertes Subnetz einschließlich angepasster System-Routen automatisch erstellen, ohne spezielle Routingtabellen oder Netzwerk Security Groups. Fügen Sie 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

Grundeinstellungen für das VPN-Gateway.
Grundeinstellungen für das VPN-Gateway.
(Bild: Microsoft / Drilling)

Anschließend können Sie 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. Wählen Sie dazu 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. Außerdem geben Sie dem Gerät einen Namen, wählen als „Gatewaytyp“ den Eintrag „VPN“ und als „VPN-Typ“ den Eintrag „Routenbasiert“ (beides Default).

Schließlich benötigen Sie eine SKU (Stock Keeping Unit). Wir verwenden für diese Demo die preiswertestes SKU für Routen-basierende Typen „VpnGw1“ mit „Generation 1“. Diese kostet in Deutschland (Frankfurt) 0,1603 Euro/Stunde für den generellen Betrieb und 0,0009 Euro/Stunde für jedem aktiv genutzten VPN-Tunnel (Verbindung). Die maximal erzielbare Bandbreite liegt dann bei 650 Megabit pro Sekunde (Mbit/s). Alle bisher erstellen Netzwerk-Ressourcen kosten dagegen nichts.

Bei „Virtuelles Netzwerk“ wählen Sie das oben erstellte Netzwerk aus. Bei „Öffentliche IP-Adresse“ nehmen Sie „neu erstellen“, vergeben einen passenden Namen (Alias) für die öffentliche IP-Adresse und belassen die übrigen Werte auf Default. Sind alle Angaben korrekt, klicken Sie auf „Überprüfen und Erstellen“. Der Vorgang kann durchaus bis zu 30 Minuten in Anspruch nehmen. Bevor Sie das Gerät im nächsten Schritt konfigurieren können, nutzen Sie die Wartezeit bis zu dessen finaler Erstellung, um die für ein Client-to-Site-VPN benötigten SSL-Zertifikate unter Windows zu generieren.

Generieren von Zertifikaten

Azure kann bei P2S-VPNs u. a. eine native Azure-Zertifikatauthentifizierung nutzen. Ebenfalls möglich sind eine Authentifizierung mittels Azure AD oder Radius) für die Authentifizierung der Clients, die eine Verbindung mit einem VNet über eine Point-to-Site-VPN-Verbindung herstellen möchten.

Dazu müssen Sie entsprechende Informationen zum öffentlichen Schlüssel des Stammzertifikates – in Form der zum Stammzertifikat gehörigen CER-Datei (öffentliche Schlüssel) – in das Azure VPN-Gateway hochladen. Diese Datei findet sich auf dem Client, der die Verbindung zu Azure initiiert. 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 generieren Sie aus dem vertrauenswürdigen Stammzertifikat und installieren es auf dem betreffenden Client-PCs. Das Client-Zertifikat authentifiziert dann den Client, sobald dieser eine Verbindung mit dem VNet initiiert.

Wenn Sie wie im folgenden Beispiel ein selbstsigniertes Stammzertifikat auf einem Windows-10-PC erzeugen und Diesen ebenfalls als Client für die Verbindung zu Azure nutzen, wird das Client-Zertifikat auf diesem automatisch installiert. In ausschließlich diesem Fall müssen Sie das Client-Zertifikat also nicht erst exportieren, um es auf dem betreffenden Client zu installieren.

Stamm-CA- und Client-Zertifikat können Sie (neben anderen Methoden wie Easy-RSA) ganz einfach von Windows aus mit folgenden PowerShhell-Commandlets erzeugen und über die Zertifikatsverwaltung (certmgr.msc) exportieren. Der folgende Befehl generiert ein selbstsigniertes Stammzertifikat mit dem Namen P2SRootCert. Dieses wird dabei automatisch in „Certificates-Current User\Personal\Certificates“ installiert.

$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 können Sie 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")

Export des Root-Zertifikats über den Cert-Manager.
Export des Root-Zertifikats über den Cert-Manager.
(Bild: Microsoft / Drilling)

Wenn Sie den gleichen PC auch tatsächlich als Client nutzen, sind Sie fast fertig, denn das Client-Zertifikat wird automatisch auf diesem installiert. „Sehen“ können Sie beide im Cert-Manager. Sie finden das grafische Windows-Tool unter C:\Windows\System32\de-DE\certmgr.msc. Navigieren Sie dort zum Ast „Eigene Zertifikate / Zertifikate“. Jetzt müssen Sie nur noch den öffentlichen-Schlüssel des Stammzertifikats (nicht den Privaten) exportieren. Dies erledigen Sie bei markiertem Stamm-Zertifikat (hier „PSRootCert“) im Kontextmenü „Alle Aufgaben / Exportieren.

Wie benötigen das Zertifikat als .CER-Datei.
Wie benötigen das Zertifikat als .CER-Datei.
(Bild: Microsoft / Drilling)

Klicken Sie dort auf „Weiter“ und dann unbedingt auf „Nein, privaten Schlüssel nicht exportieren“. Danach wählen Sie im Zertifikatexport-Assistent den Eintrag „Base-64-codiert X.500“. Wählen Sie anschließend den gewünschten Speicherort und speichern den Schlüssel und einem beliebigen Namen ab z. B. „rootcertificate.cer“.

Virtual Network Gateway konfigurieren

Jetzt können Sie das Virtual Network Gateway konfigurieren. Öffnen Sie das das Azure Portal jetzt von Ihren Windows-Client aus und navigieren zum oben erstellten Gateway zum Abschnitt „Einstellungen / Punkt-zu-Standort-Konfiguration“. Hier klicken auf „Jetzt konfigurieren“.

Während der P2S-Konfiguration ist das Stammzertifikat zu hinterlegen.
Während der P2S-Konfiguration ist das Stammzertifikat zu hinterlegen.
(Bild: Microsoft / Drilling)

Geben Sie bei „Adresspool“ einen Pool ein, aus dem die anfragenden Clients mit eine IP-Adresse für da sz generierte PPP-Device versorgt werden. Dieser muss uns sollte auch nichts mit dem IP-Adress-Bereich eines der Subnetze zu tun haben, z. B. „172.16.30.0/24“.

Anschließend müssen Sie unter „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ählen Sie im Falle eines Windows-Clients „SSTP (SSL)“, weil das die Installation samt Konfiguration des VPN-Clients extrem vereinfacht. Klicken Sie auf „Speichern“ und danach rechts oben auf „VPN-Client herunterladen“.

Je nach gewählten Tunneltyp können, bzw. müssen Sie dann 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.

Der VPN-Client muss manuell zur Ausführung berechtigt werden.
Der VPN-Client muss manuell zur Ausführung berechtigt werden.
(Bild: Microsoft / Drilling)

Im Archiv steckt ein Unterordner für jede Plattform. Hier wählen Sie z. B. „WindowsAMD64“. Darin findet sich eine Datei „VpnClientSetupAmd64.exe“, die Sie einfach nur doppelklicken müssen. Öffnet sich dabei der Dialog „Der Computer wurde durch Windows geschützt“ klicken Sie rechts oben auf das „X“ für Schließen. Ist das geschehen, finden Sie bei Windows 10 im „Netzwerk- und Interneteinstellungen öffnen“-Systray unter „VPN“ eine fertig eingerichtete neue VPN-Verbindung mit dem von Ihnen gewählten Namen.

Der VPN-Client nach dem Start.
Der VPN-Client nach dem Start.
(Bild: Microsoft / Drilling)

Kicken Sie darauf und danach auf „Verbinden“, öffnet sich der „Windows Azure Virtual Client“. Klicken Sie auch hier auf „Verbinden“ baut Windows-10 eine SSL-gesicherte Verbindung via SSTP in Ihre Azure-VNet auf.

Ein Blick in die Kommandozeile per ipconfig zeigt, dass die VPN-Verbindung funktioniert.
Ein Blick in die Kommandozeile per ipconfig zeigt, dass die VPN-Verbindung funktioniert.
(Bild: Microsoft / Drilling)

Zur Kontrolle geben Sie in der CMD „ipconfig“ ein. Sie werden feststellen, dass der Windows-PC einen PPP-Adapter mit einer IP-Adresse aus dem oben gewählten Adresspool erhalten hat. Hätten Sie nun virtuelle Maschinen in ihrem Azure-FrontEnd- oder BackEnd-Subnetz, könnten Sie diese direkt auf ihrer jeweiligen privaten IP-Adresse erreichen.

Im nächsten Teil werden wie die erstellte Verbindung nutzen, um über VPN und private IP-Adressen eine Verbindung zu einer auf einem Azure-Container-Host bereitgestellten Datenbank herzustellen. Dass das mit nur wenigen Schritten binnen Minuten funktioniert, wird besonders Entwickler erfreuen.

(ID:47559223)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist