14.4 VPNs mit Windows Server 2012 R2

Wie ich bereits mehrfach erwähnt habe, gehört die Anbindung von Niederlassungen und mobilen Mitarbeitern zu den wichtigsten Funktionen, die eine moderne Unternehmens-IT gewährleisten muss. Dabei gilt es, mehrere Aspekte zu berücksichtigen:

• Sicherheit
• Performance
• Verwaltbarkeit
• Integrierbarkeit in das Gesamtkonzept
• Kosten

Nun gibt es mit DirectAccess eine äußerst elegante Möglichkeit, mobile Computer einzubinden. Da DirectAccess aber verschiedene Dinge voraussetzt, die nicht immer erfüllbar sein werden, spielt das »normale« VPN weiterhin eine wichtige Rolle.

Windows Server 2012 R2 ist ein recht universeller VPN-Server, er unterstützt folgende Tunneling-Protokolle:

• PPTP
• L2TP
• SSTP
• IKEv2

Das Gegenstück, also der Client, kann beispielsweise Windows 7 oder Windows 8/8.1 laufen. Das »alte« Windows Vista unterstützt allerdings kein IKEv2. Auch XP-Clients können verwendet werden, dann allerdings nur mit PPTP und L2TP.

Die Tunneling-Protokolle sind als WAN-Miniport-Treiber installiert. Sie können das erkennen, wenn Sie im Gerätemanager auch die ausgeblendeten Geräte anzeigen lassen; Abbildung 14.102 zeigt einen Blick in den Gerätemanager eines Windows-Clients.

In diesem Abschnitt möchte ich Ihnen die Fähigkeiten des Windows Server 2012 R2 als VPN-Server vorstellen. Microsofts aktuelles Serverbetriebssystem ist ein recht flexibler und einfach zu handhabender VPN-Server. Er kann nahtlos durch recht anspruchsvolle Technologien wie Network Access Protection (NAP; siehe Abschnitt 14.1) ergänzt werden. Windows-Administratoren werden sich ohnehin freuen, dass sie sich in einer letztendlich bekannten und vollintegrierten Umgebung befinden.

Darüber hinaus ist diese Variante recht günstig in der Anschaffung, da Sie die Client-Zugriffslizenzen (CALs) ja vermutlich ohnehin beschafft haben werden.

Abbildung 14.102 Es sind vier WAN-Miniport-Treiber für den Aufbau von VPN-Verbindungen vorhanden.

14.4.1 Gateway-Architektur

Zunächst stellt sich die Frage, wie Sie den VPN-Server in Ihre Gateway-Architektur einpassen. Hier gibt es verschiedene Möglichkeiten; insbesondere ist die Frage zu beantworten, ob die VPN-Benutzer direkt im Innenbereich des LANs landen sollen oder noch durch eine Firewall müssen:

• Wenn Sie sich dafür entscheiden, dass die VPN-Benutzer direkten Zugriff auf das LAN erhalten sollen, kommt ein Aufbau wie in Abbildung 14.103 infrage.

  

  Abbildung 14.103 Möglicher Aufbau einer VPN-Umgebung

• Sofern der Innenbereich des Netzes mit einer Firewall von den VPN-Benutzern abgetrennt werden soll, könnte man so wie auf Abbildung 14.104 vorgehen: Dort werden das externe und interne LAN des VPN-Servers in zwei unterschiedlichen DMZs einer Firewall angeschlossen. Alternativ könnte man natürlich auch mit zwei Firewalls arbeiten.

Die zweite Variante vermittelt eine irgendwie gefühlte höhere Sicherheit – das ist auch nicht von der Hand zu weisen. Ich möchte allerdings zu bedenken geben, dass ich etliche Unternehmen und Organisationen kenne, die zwar die auf Abbildung 14.103 gezeigte Variante implementiert haben, die Firewall zwischen VPN-Server und dem Innenbereich dann aber vollständig geöffnet haben. Meistens bekomme ich dann zu hören: »Ja, wieso? Uli, du weißt doch, dass unsere VPN-Benutzer auf alles Zugriff haben sollen!« Das ist in Ordnung, dann kann man aber auch gleich das Szenario von Abbildung 14.104 wählen.

Abbildung 14.104 Alternativer Aufbau der VPN-Umgebung

14.4.2 Grundkonfiguration des VPN-Servers

Wenn Sie mit der Einrichtung des VPN-Servers beginnen, sollte dieser über zwei Netzwerkanschlüsse verfügen. Der eine nimmt den Verkehr aus dem Internet entgegen, der andere kommuniziert mit dem internen LAN.

Die VPN-Serverfunktionalität ist ein Bestandteil der Rolle Remotezugriff , folglich muss dem Server diese Rolle hinzugefügt werden (Abbildung 14.105).

Abbildung 14.105 Wenn Sie aus einem Windows Server 2012 (R2) einen VPN-Server machen möchten, müssen Sie die Rolle »Remotezugriff« installieren.

Der Installationsassistent wird Sie auf der nächsten Seite fragen, welche Rollendienste installiert werden sollen (Abbildung 14.106). Für die Erstellung eines VPN-Servers benötigen Sie prinzipiell nur den Rollendienst DirectAccess und VPN. Sofern Sie die zugreifenden Clients auf Einhaltung bestimmter Richtlinien (z. B. alle Patches installiert, aktueller Virenscanner und so weiter) prüfen möchten, benötigen Sie zusätzlich den Netzwerkrichtlinienserver (siehe Abschnitt 14.1.2).

Abbildung 14.106 Sie benötigen mindestens den Rollendienst VPN.

Die Installation der Rolle erfordert ansonsten keine weiteren Eingaben. Nach Abschluss erhalten Sie allerdings im Server-Manager den Hinweis, dass der Assistent für erste Schritte ausgeführt werden muss (Abbildung 14.107).

Abbildung 14.107 Der Assistent für erste Schritte hilft Ihnen bei der Basiskonfiguration.

Der Assistent wird Sie zunächst fragen, ob Sie DirectAccess und/oder VPN bereitstellen möchten. In diesem Beispiel wählen wir »nur« die VPN-Funktionalität (Abbildung 14.108). Damit verlässt der Assistent uns auch schon wieder und leitet zu dem altbekannten Routing und RAS-Konfigurationswerkzeug weiter. Dort gibt es einen Menüpunkt zum Konfigurieren und Aktivieren (Abbildung 14.109).

Abbildung 14.108 Für dieses Beispiel wird nur VPN bereitgestellt.

Abbildung 14.109 Sie gelangen zu dem prinzipiell aus den Vorgängerversionen bekannten Snap-In.

Der Assistent vom Routing und RAS-Werkzeug möchte zunächst wissen, was für eine Konfiguration denn nun erstellt werden soll. Für die »normale« VPN-Einwahl wählen Sie die oberste Option (Abbildung 14.110). Die übrigen Möglichkeiten sind im Dialog recht aussagekräftig erklärt.

Abbildung 14.110 Der Installationsassistent kann bereits eine Konfiguration vorbereiten, Sie können diese Arbeiten aber auch komplett »zu Fuß« ausführen.

In diesem Beispiel lasse ich mir vom Assistenten helfen und erstelle eine normale VPN-Konfiguration. Dabei führt er Sie durch folgende Entscheidungen:

• Zunächst können Sie festlegen, ob Sie den Server für VPN und/oder RAS verwenden möchten. Ja, die Remoteeinwahl per Modem wird auch noch immer unterstützt (Abbildung 14.111).

  

  Abbildung 14.111 Entscheiden Sie sich zunächst für die Unterstützung von VPN-Verbindungen.

  

  Abbildung 14.112 Anschließend müssen Sie die internetseitige Netzwerkschnittstelle auswählen. Es ist hilfreich, die Netzwerkkarten sinnvoll zu benennen.

• Im nächsten Schritt müssen Sie die internetseitige Netzwerkkarte auswählen – auch unproblematisch (Abbildung 14.112). Wie Sie sehen, ist es hilfreich, die Netzwerkkarten sinnvoll zu benennen.
• Im nun folgenden Dialog wird definiert, wie die IP-Adressen für die sich verbindenden Remoteclients ermittelt werden. Im Allgemeinen ist die beste Möglichkeit die Verwendung von DHCP, alternativ kann der VPN-Server auch die Zuweisung von Adressen vornehmen (Abbildung 14.113).

  

  Abbildung 14.113 In diesen Dialogen wird konfiguriert, wie die Adresszuweisung erfolgen soll.

• Im letzten Dialog des Assistenten können Sie entscheiden, ob die Authentifizierung durch den VPN-Server erfolgen oder ob ein nachgelagerter RADIUS-Server zur Authentifizierung verwendet werden soll. Soll der VPN-Server die Authentifizierung durchführen, muss er Domänenmitglied sein, oder es können sich nur lokal angelegte Benutzer anmelden (Abbildung 14.114).

Abbildung 14.114 In diesem Fall nutzen wir keinen separaten RADIUS-Server für die Authentifizierung

14.4.3 VPN einrichten (allgemein)

Die Einrichtung einer VPN-Verbindung in einem Windows-Betriebssystem ist nicht weiter kompliziert. Ich zeige Ihnen dies exemplarisch mit Windows 8.1, auf den älteren Clients funktioniert es ähnlich.

Sie beginnen im Netzwerk- und Freigabecenter, genauer gesagt mit dem Menüpunkt Neue Verbindung oder neues Netzwerk einrichten (Abbildung 14.115).

Es startet ein Assistent, der neben einer VPN-Verbindung auch eine Verbindung zum Internet aufbauen kann (Abbildung 14.116).

Abbildung 14.115 Die Einrichtung einer neuen VPN-Verbindung startet im »Netzwerk- und Freigabecenter«.

Abbildung 14.116 Ein VPN wird mit dieser Option eingerichtet.

Der nächste Dialog des Assistenten ist ebenfalls leicht zu bearbeiten. Es geht um die Frage, ob Sie ein VPN oder eine Einwahlverbindung einrichten möchten (Abbildung 14.117).

In den nächsten beiden Dialogen werden nun die technischen Daten für die neue VPN-Verbindung erfasst:

• Zunächst geht es um die Internetadresse des VPN-Servers (Abbildung 14.118). Hier kann eine IP-Adresse oder ein Name eingetragen werden.

  Es könnte unter Umständen empfehlenswert sein, die Checkbox Jetzt nicht verbinden ... zu aktivieren. Dies ist immer dann ratsam, wenn Sie nach dem Durchlauf des Assistenten noch ein wenig »Feintuning« vornehmen möchten.

  

  Abbildung 14.117 Sie können ein VPN erstellen oder eine Direktwahlverbindung einrichten.

  

  Abbildung 14.118 Zunächst werden die Verbindungsdaten erfasst.

• Im nächsten Dialog (Abbildung 14.119) werden Benutzername, Kennwort und optional die Domäne erfasst. Beim Verbindungsaufbau zum Windows-Netz ist das zumindest empfehlenswert.

Abbildung 14.119 Hier werden die Benutzerdaten eingegeben.

Das Verwalten der VPN-Einträge und das Verbinden funktionieren unter Windows 7/8/8.1 übrigens anders als bei Windows Vista. Wenn Sie auf das Netzwerksymbol in der Taskleiste (das ist der kleine graue Monitor mit dem dicken Netzwerkkabel und dem überdimensionalen Stecker) klicken oder aber im Netzwerk- und Freigabecenter den Link Verbindung mit einem Netzwerk herstellen wählen, erscheint die Leiste aus Abbildung 14.120. Dort wird einerseits gezeigt, mit welchen Netzwerken derzeit eine Verbindung besteht, andererseits werden die eingerichteten Verbindungen gezeigt – nebst Kontextmenüpunkten für das Verbinden und Bearbeiten der Eigenschaften.

Abbildung 14.120 Wenn Sie auf das Netzwerksymbol klicken, erscheint die Liste der konfigurierten VPN-Netzwerke.

14.4.4 Einwahlberechtigung

Nicht jeder Benutzer muss unbedingt Einwahlberechtigungen haben. Die Steuerung der Berechtigung erfolgt über ein Active Directory-Attribut. Sie konfigurieren es in den Eigenschaften des Benutzers auf der Registerkarte Einwählen (Abbildung 14.121). Sie haben hier drei Möglichkeiten:

• Zugriff gestatten
• Zugriff verweigern
• Zugriff über NPS-Netzwerkrichtlinien steuern; NPS ist der Network Policy Server (Netzwerkrichtlinienserver), Sie haben ihn in Abschnitt 14.1.2 bereits kennengelernt.

Abbildung 14.121 In den Eigenschaften des Kontos werden die Einwahlberechtigungen konfiguriert.

Wenn ein Benutzer versucht, sich einzuwählen, aber keine Berechtigungen hat, erscheint die Fehlermeldung aus Abbildung 14.122.

Abbildung 14.122 Diese Meldung sehen Sie, wenn eine Verbindung nicht möglich ist, weil Sie keine Einwahlberechtigung haben.

Abbildung 14.123 In den Netzwerkverbindungen werden die VPN-Verbindungen konfiguriert.

14.4.5 PPTP-VPN

In den Eigenschaften der VPN-Verbindung können Sie festlegen, welcher VPN-Typ verwendet werden soll. Etwas genauer ausgedrückt, wählen Sie das zu verwendende Tunneling-Protokoll (Abbildung 14.124).

Das vermutlich in der Anwendung einfachste Tunneling-Protokoll ist PPTP, das Point-to-Point-Tunneling-Protokoll. Es kann unterschiedliche Protokolle (TCP/IP, NetBEUI, IPX) tunneln und benötigt keine weiteren Voraussetzungen, wie beispielsweise Zertifikate zur Authentifizierung und Verschlüsselung.

PPTP ist unter Sicherheitsaspekten nicht optimal, da die Verschlüsselungsstärke von der Länge des verwendeten Kennworts abhängig ist. Etwas salopp gesagt, würde ich es so ausdrücken: Für den »normalen« Gebrauch dürfte die Verwendung von PPTP akzeptabel sein. Sofern Sie mit einer realistischen (!) Bedrohung durch Industriespionage rechnen müssen, sollten Sie ein anderes Tunneling-Protokoll als Basis für Ihre VPN-Verbindungen wählen.

Die Konfiguration von PPTP ist schnell abgehandelt. Auf Abbildung 14.124 sehen Sie die Registerkarte Sicherheit des Eigenschaftendialogs der VPN-Verbindung. Hier bestimmen Sie den VPN-Typ und nehmen gegebenenfalls weitere Einstellungen vor. Bei der Auswahl von PPTP ist die Schaltfläche Erweiterte Einstellungen allerdings deaktiviert – es gibt zum PPTP-Protokoll nichts einzustellen.

Sie sollten darauf achten, dass Datenverschlüsselung als Erforderlich konfiguriert ist. Das PPTP-Protokoll selbst beinhaltet keine Verschlüsselungsverfahren; auf höheren Protokollschichten kann selbstverständlich eine Verschlüsselung durchgeführt werden.

Abbildung 14.124 Beim Point-to-Point-Tunneling-Protokoll gibt es nicht viel einzustellen.

Die zu verwendende Authentifizierungsmethode hängt von dem VPN-Server ab, mit dem der Client eine Verbindung aufbaut. Sie haben zwei Möglichkeiten:

• Sie verwenden eine EAP-basierte Authentifizierung. EAP steht für Extensible Authentication Protocol. Es handelt sich dabei um ein erweiterbares Protokoll, das mit unterschiedlichen Verfahren arbeiten kann. Sofern Sie sich in einen Microsoft VPN-Server einwählen, ist eines der EAP-Protokolle die beste Wahl. Zur Verfügung stehen drei Microsoft-Authentifizierungsverfahren, die jeweils mehr oder weniger umfangreich konfigurierbare Eigenschaften besitzen. Auf Abbildung 14.125 sehen Sie die Konfiguration von EAP-MSCHAP v2, bei dem eingestellt werden kann, dass die aktuellen Anmeldeinformationen des Benutzers verwendet werden. Ist dies so konfiguriert, braucht der Anwender keine zusätzlichen Anmeldeinformationen einzugeben.
• Wenn Sie nicht EAP verwenden möchten oder können, lässt sich unter der Option Folgende Protokolle zulassen bestimmen, welche Authentifizierungsprotokolle verwendet werden können. PAP, bei dem das unverschlüsselte Kennwort übertragen wird, ist sicherlich keine gute Wahl. Bei der Verwendung von MS-CHAP kann die Verwendung der aktuellen Windows-Anmeldeinformationen konfiguriert werden – eine zusätzliche Passworteingabe ist dann beim Verbindungsaufbau nicht erforderlich.

Abbildung 14.125 Hier legen Sie fest, welches Authentifizierungsprotokoll verwendet werden soll. Hilfreich ist auch die automatische Übermittlung der Windows-Anmeldeinformationen.

14.4.6 L2TP-VPN

Die komplette Bezeichnung dieser VPN-Variante ist L2TP/IPSec. Das beschreibt eigentlich schon ziemlich genau, wie das Verfahren funktioniert:

• Der VPN-Tunnel wird über das L2TP-Protokoll aufgebaut. Wie bei PPTP ist im L2TP keine Verschlüsselung der übertragenen Daten enthalten.
• Die verschlüsselte Datenübertragung erfolgt über IPSec.

Bei der Verwendung von L2TP/IPSec fallen vielen Administratoren zunächst Stichwörter wie Zertifikate und vorinstallierter Schlüssel (PSK, Pre-Shared Key) ein. Beides gehört zu dem Verfahren, allerdings nicht zu L2TP, sondern zu IPSec. Die Authentifizierung bei L2TP erfolgt über ein Authentifizierungs-Protokoll, das Sie festlegen müssen, beispielsweise EAP (mit Erweiterung) oder CHAP. IPSec hingegen basiert prinzipiell auf einer zertifikatsbasierten Authentifizierung, das heißt, sowohl der Client als auch der Server müssen über ein entsprechendes Zertifikat verfügen. Das ist so weit auch alles bestens, nur was passiert, wenn ein Unternehmen oder eine Organisation (noch) keine eigene PKI implementiert hat und folglich nicht über Zertifikate verfügt?

In diesem Fall kann ein vorinstallierter Schlüssel – vermutlich besser bekannt unter dem englischen Begriff Pre-Shared Key (PSK) – verwendet werden.

In den erweiterten Einstellungen für L2TP/IPSec ist nun auch genau das auswählbar: Sie können festlegen, ob mit einem vorinstallierten Schlüssel oder mit Zertifikaten gearbeitet werden soll (Abbildung 14.126). Der Konfigurationsdialog Erweiterte Einstellungen ist übrigens etwas missverständlich, denn es geht hier eigentlich nicht um die L2TP-, sondern um die IPSec-Authentifizierung.

Abbildung 14.126 L2TP kann entweder mit einem vorinstallierten Schlüssel (PSK, Pre-Shared Key) oder mit Zertifikaten arbeiten.

Falls Sie mit vorinstallierten Schlüsseln arbeiten, müssen Sie diese auch auf dem VPN-Server eintragen. Sie können den Schlüssel im Verwaltungswerkzeug Routing und RAS in den Servereigenschaften konfigurieren (Abbildung 14.127, siehe Pfeil). Der vorinstallierte Schlüssel ist übrigens eine beliebige Zeichenkette, die Sie sich selbst ausdenken können.

Abbildung 14.127 Möglich, aber nicht zu empfehlen: die Verwendung eines vorinstallierten Schlüssels (siehe Pfeil)

Abbildung 14.128 zeigt den Auszug einer L2TP/IPSec-Kommunikation im Netzwerkmonitor:

• Zunächst wird die IPSec-Authentifizierung ausgehandelt (zu sehen in den Paketen 12 bis 23). Zur Sicherung des Tunnels wird IPSec verwendet, folglich muss zunächst die IPSec-Authentifizierung nebst Schlüsselaustausch stattfinden. Hierzu wird das Protokoll IKE (Internet Key Exchange) verwendet.
• Nach Abschluss der Authentifizierungsphase erfolgt die gesicherte Kommunikation über IPSec. Diese erkennen Sie an den ESP-Paketen (Encapsulating Security Payload).

Bei Betrachtung der Netzwerkpakete wird dann auch klar, warum es »L2TP over IPSec« heißt: Zunächst wird die IPSec-Verbindung aufgebaut, darüber wird der L2TP-Tunnel geführt.

Abbildung 14.128 L2TP/IPSec im Netzwerkmonitor: Zunächst erfolgt die Authentifizierung (IKE-Pakete), dann die Kommunikation über IPSec (ESP-Pakete).

14.4.7 SSTP

Die beiden zuvor gezeigten Tunneling-Protokolle, also PPTP und L2TP, gibt es für IT-Zeitbegriffe schon ewig. SSTP, das Secure Socket Tunneling Protocol, ist vergleichsweise neu und tauchte zuerst im Windows Vista SP1 und in Windows Server 2008 auf. Es ist natürlich auch in Windows Server 2012/R2 und Windows 7/8/8.1 enthalten. Für ältere Betriebssysteme gibt es keinen SSTP-Client.

Wenn Anwender sich mit ihren Notebooks in fremden Netzen, beispielsweise beim Kunden, befinden, scheitert der Aufbau der VPN-Verbindung häufig daran, dass die Firewall des Netzes keinen PPTP- oder L2TP/IPSec-Verkehr zulässt. Auch von WLAN-Hotspots in Flughafen-Lounges und dergleichen ist schon berichtet worden, dass »nur« HTTP- oder HTTPS-Zugriffe über die Firewall gestattet waren.

Der naheliegende Gedanke ist also, die so gut wie überall zulässigen SSL-Pakete zum Aufbau des VPN-Tunnels zu verwenden – genau das passiert bei einer SSTP-Verbindung.

Auf dem Client muss lediglich der VPN-Typ ausgewählt werden, Erweiterte Einstellungen sind für SSTP nicht vorhanden (Abbildung 14.129).

Auf dem Server ist, wie bei allen SSL-Verbindungen, ein Zertifikat erforderlich, das die drei bekannten Bedingungen erfüllen muss:

• Das Zertifikat muss zeitlich gültig sein.
• Der Client muss dem Zertifikat vertrauen. Das geschieht dadurch, dass er der zertifikatausgebenden Stelle vertraut, was wiederum dadurch gewährleistet wird, dass der öffentliche Teil des Zertifikats der Stammzertifizierungsstelle an der entsprechenden Stelle des Zertifikatsspeichers des Clients vorhanden ist.
• Das Zertifikat muss dem Namen entsprechen, den der Client aufgerufen hat. Wenn der Client sich mit vpn2.boddenberg-technik.de verbinden möchte, darf nicht ein auf den internen Namen des Servers ausgestelltes Zertifikat (z. B. ubinfmobiserv02.ubinf.intra) präsentiert werden.

Es sollte einfach sein, für die zeitliche Gültigkeit des Zertifikats zu sorgen. Wenn das Zertifikat von einer eigenen Active Directory-integrierten Zertifizierungsstelle herausgegeben worden ist, befindet sich deren Stammzertifikat im Speicher für vertrauenswürdige Stammzertifizierungsstellen – also auch kein Problem.

Abbildung 14.129 Beim SSTP-Protokoll gibt es nichts in den »Erweiterten Einstellungen« zu konfigurieren.

Der dritte Aspekt ist meistens der fehleranfälligste – obwohl er eigentlich wirklich kein Problem ist:

• Erzeugen Sie ein Zertifikat für den Namen, den der im Internet befindliche Client zum Verbinden mit dem VPN-Server aufrufen wird (etwa vpn10.boddenberg.de).
• Importieren Sie das Zertifikat in den lokalen Zertifikatsspeicher des Computers.
• In den Eigenschaften des VPN-Servers im Werkzeug Routing und RAS können Sie im Abschnitt SSL-Zertifikatbindung das Zertifikat auswählen (Abbildung 14.130).

Abbildung 14.130 Bei der serverseitigen Vorbereitung von SSTP ist es extrem wichtig, dass das »passende« Zertifikat ausgewählt wird.

Es könnte jetzt sein, dass Ihnen die Fehlermeldung aus Abbildung 14.131 präsentiert wird, die Sie, so leid es mir tut, nicht mit einem grafischen Konfigurationswerkzeug aus dem Weg räumen können.

Diese Fehlermeldung tritt beispielsweise dann auf, wenn bereits ein anderes Zertifikat zur Serverauthentifizierung auf dem Computer installiert worden ist. In meiner Beispielkonfiguration werden Computerzertifikate per Auto Enrollment automatisch auf allen Systemen installiert. Das auf Abbildung 14.130 in der Dropdown-Liste gezeigte Zertifikat UBINFMOBISERV02.ubinf.intra ist auf diesem Weg auf die Maschine gekommen. Dieses Zertifikat ist an HTTP.sys gebunden worden, was dazu führt, dass Sie nicht das benötigte Zertifikat für SSTP auswählen können.

Abbildung 14.131 Diese Fehlermeldung erscheint, wenn »HTTP.sys« bereits an ein anderes Zertifikat gebunden ist.

Die Lösung für das Problem besteht darin, die Bindung des Zertifikats an HTTP.sys aufzuheben. Auf Abbildung 14.132 ist zu sehen, wie’s gemacht wird:

• Mit dem Befehl netsh http show sslcert können Sie die aktuellen Bindungen anschauen. Sie sehen, dass an 0.0.0.0:443 (alle IP-Adressen des Computers, Port 443) ein Zertifikat mit dem Hash-Wert e235b [...] gebunden ist. Für IPv6 ergibt sich dasselbe Bild.
• Mit netsh http delete sslcert ipport=0.0.0.0:443 können Sie diese Bindung aufheben. Der entsprechende Befehl für IPv6 lautet netsh http delete sslcert ipport=[::]:443.

Nun sollten Sie das Zertifikat für den externen Namen auswählen können (Abbildung 14.133).

Abbildung 14.132 Die Bindung eines Zertifikats an »HTTP.sys« wird aufgehoben.

Nun wird der Verbindungsaufbau per SSTP möglich sein. Die Kontrolle im Netzwerkmonitor zeigt, dass die Verbindung in der Tat über das SSL-Protokoll erfolgt. Somit sollte eine Verwendung über Router und Firewall hinweg möglich sein (Abbildung 14.133).

Abbildung 14.133 Wie erwartet läuft der Verkehr komplett über den SSL-Port 443.

Troubleshooting – typische Probleme

SSTP ist zwar grundsätzlich unproblematisch in Konfiguration und Anwendung, trotzdem treten hin und wieder Probleme auf – wie immer. Die meiner Erfahrung nach häufigsten zwei Probleme bespreche ich in diesem Abschnitt.

Oft tritt das Problem auf, dass der Name des für SSTP ausgewählten Zertifikats (siehe Abbildung 14.130) nicht zu dem vom Client aufgerufenen Namen passt. Es erscheint dann die Fehlermeldung aus Abbildung 14.134.

Abbildung 14.134 Einer der häufigsten Fehler ist ein Zertifikat, das für den falschen Namen ausgestellt ist.

Dazu zwei Hinweise:

• Wenn die Clients vpn1.boddenberg-technik.de aufrufen, muss das Zertifikat genau (!) auf diesen Namen ausgestellt sein.
• Wenn die Clients den VPN-Server über dessen IP-Adresse ansprechen, muss das Zertifikat auf die IP-Adresse ausgestellt sein.

Das zweite wirklich häufige Problem ist auf Abbildung 14.135 zu sehen. Hinter dieser wenig prägnanten Beschreibung steckt die Ursache, dass die Zertifikatsperrliste nicht erreichbar ist, der SSTP-Client also nicht überprüfen kann, ob das Zertifikat gesperrt wurde, mit dem der VPN-Server abgesichert ist.

Das Problem lässt sich wie folgt lösen:

• Definieren Sie in den Eigenschaften der Zertifizierungsstelle eine zusätzliche externe URL für die Sperrliste.
• Kopieren Sie die Sperrliste in diese URL.

Abbildung 14.135 Ein weiteres häufiges Problem ist eine nicht vorhandene Zertifikatsperrliste.

Falls Sie keinen externen Verteilungspunkt für die Zertifikatsperrlisten einrichten können, lässt sich die Überprüfung der Sperrliste ausschalten:

• Navigieren Sie im Registry-Editor zum Abschnitt HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\parameters.
• Legen Sie ein neues DWORD namens NoCertRevocationCheck an, und setzen Sie den Wert auf 1.

Ein Neustart ist nicht erforderlich, die Einstellung ist sofort aktiv.

14.4.8 Automatischer Modus

Neben den bisher besprochenen VPN-Typen existiert die Option Automatisch. Bei dieser versucht der Client selbstständig, eine VPN-Verbindung aufzubauen. In den Erweiterten Einstellungen finden sich daher die Konfigurationsoptionen für L2TP und IKEv2 (Abbildung 14.136; PPTP und SSTP haben keine Erweiterten Einstellungen).

Abbildung 14.136 Beim VPN-Typ »Automatisch« wird erst PPTP, dann L2TP und zum Schluss SSTP probiert.

In dieser Reihenfolge wird der Verbindungsaufbau probiert:

1. IKEv2
2. SSTP
3. PPTP
4. L2PT/IPSec

14.4.9 Connection Manager Administration Kit (CMAK, Verbindungs-Manager-Verwaltungskit)

Nun stehen wir wieder vor dem beliebten Problem: »Was tun, wenn nicht nur drei PCs, sondern dreihundert mit der VPN-Verbindung konfiguriert werden sollen?« In diesem Fall ist die Lösung das Connection Manager Administration Kit (CMAK). In der deutschen Version nennt es sich Verbindungs-Manager-Verwaltungskit.

In Windows Server 2012/R2 wird das Feature bereits mit dem VPN-Rollendienst installiert. Sie rufen den CMAK einfach auf, indem Sie genau diese Zeichenkette auf dem Startbildschirm eintippen.

Die erste sichtbare Komponente vom CMAK ist ein Assistent (Abbildung 14.137). Dieser Assistent ist ziemlich umfangreich, deshalb werde ich die notwendigen Eingaben nicht Schritt für Schritt durchgehen. Die Dialoge des Assistenten sind zwar in ihrer Konsequenz nicht immer sofort völlig selbsterklärend, aber die Aufgabe ist für jeden Administrator lösbar.

Im Verlauf der Arbeit mit dem Assistenten wird natürlich ein VPN-Eintrag erstellt – das ist ja auch der Zweck der Übung. In den Eigenschaften dieses Eintrags gibt es unter anderem eine VPN-Strategie zu konfigurieren (Abbildung 14.138).

Wie im vorherigen Abschnitt über den VPN-Typ beschrieben, ist beim Anlegen einer Verbindung mit dem VPN-Client von Windows 7/8/8.1 die Verbindungsreihenfolge beim VPN-Typ Automatisch festgelegt und kann nicht verändert werden. CMAK bietet mehr Konfigurationsmöglichkeiten, übrigens auch, was Verbindungsthemen jenseits von VPN betrifft.

Abbildung 14.137 Dieser Assistent nimmt das Erstellen eines Verbindungs-Manager-Profils vor.

Abbildung 14.138 Es können verschiedene VPN-Strategien konfiguriert werden.

Nach dem Durcharbeiten des Assistenten wird eine EXE-Datei erstellt, die auf den Clients installiert werden kann und Verbindungen gemäß den im Assistenten vorgenommenen Einstellungen einrichtet (Abbildung 14.139). Die EXE-Datei kann mit einer Softwareverteilungslösung verteilt werden. Mit der Option /Q kann ein Quiet-Modus gewählt werden – wenn die Datei ohne den Parameter für den Quiet-Modus aufgerufen wird, erscheint zunächst die Abfrage aus Abbildung 14.140.

Abbildung 14.139 Nach dem Durcharbeiten des Assistenten wird eine Installationsdatei erzeugt.

Abbildung 14.140 Wenn die EXE-Datei nicht im Quiet-Modus (»/Q«) aufgerufen wird, gibt es noch diesen Hinweis, bevor die Verbindung eingerichtet wird.

Im Assistenten können Sie übrigens diverse Einstellungen vornehmen, die so weit gehen, dass der Anmeldedialog mit veränderten Texten und auch Bildern versehen werden kann. Ein so gut wie nicht veränderter CMAK-Anmeldedialog ist auf Abbildung 14.141 gezeigt – optisch leicht modifiziert, aber ansonsten ist alles vorhanden.

Abbildung 14.141 Dies ist der Dialog zum Verbindungsaufbau.

Dass eine mit CMAK eingerichtete Verbindung letztendlich ganz »normal« gehandhabt wird, sehen Sie in Abbildung 14.142 an dem Dialog zur Verwaltung und Auswahl der Verbindungen. Die Funktionalität und Integration entspricht aber den Verbindungen, die in Windows 7/8/8.1 angelegt worden sind. (Windows 7 verwendet übrigens ein leicht modifiziertes Symbol.)

Abbildung 14.142 Die CMAK-Verbindung erscheint bei Windows 8/8.1 »ganz normal« bei den zur Verfügung stehenden VPN-Verbindungen.

Hinweisen möchte ich noch darauf, dass in den Eigenschaften einer mit CMAK angelegten Verbindung etwas andere Konfigurationsoptionen zur Verfügung stehen – genauer gesagt: weniger Konfigurationsoptionen. Der Benutzer hat beispielsweise nicht die Möglichkeit, die Verbindung umzukonfigurieren und den VPN-Typ oder die Authentifizierung zu ändern.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.