Zugriff von unterwegs per RAS und VPN

Clients, die außerhalb der Firma unterwegs sind, müssen eine Verbindung zum Exchange Server aufbauen können, um Nachrichten zu übermitteln. Es ist dabei egal, ob dies nun ein Outlook im Offlinebetrieb ist oder ein POP3-Client. All diesen Anwendungsprogramme ist keine eigene Verbindungssoftware beigelegt, die mit proprietären Protokollen arbeiten oder selbst die Übertragungseinrichtungen ansteuern. Sie nutzen einfach eine bestehende Netzwerkverbindung.

Achtung:
Die Nutzung von PPTP mit dem Authentifizierungsprotokoll MSCHAPv2 oder schwächer ist nicht mehr angeraten, da diese Übertragung und insbesondere die Anmeldedaten in weniger als 24h decodiert werden können.

Seit Windows 7 mit Windows 2008R2 und höher könnte auch Direct Access eine interessante Option sein.

Achtung:
Bitte betreiben Sie ihren Exchange Server niemals ungeschützt und ungesichert am Internet. Da die Anmeldedaten am Postfach mit ihren Netzwerkdaten identisch sind, wäre jede Unsicherheit hier fatal, da ein Angreifer dann auch andere Dienste ansprechen könnte. Zudem ist nie ganz sicher, dass auch regulär veröffentlichte Dienste nicht doch später eine Lücke offenbaren.

Outlook Anywhere
Outlook kann seine Zugriffe auch per HTTPS-Tunnel. Wenn Sie "nur" Exchange und Outlook über das Internet verbinden wollen, dann ist dies meine Präferenz

Outlook zu Exchange

Es ist Aufgabe des darunter liegenden Betriebssystems, eine Verbindung aufzubauen. POP3 und IMAP4-Clients benötigen zwingend das Protokoll TCP/IP. Früher konnte Outlook sogar noch IPX oder NetBeui nutzen, aber auch heute ist das nicht mehr von Belang. Outlook benötigt allerdings nicht die Datei und Druckfreigabe von Microsoft oder andere Dateidienste. Seit Outlook 2007 und Exchange 2007 wird aber auch HTTP/HTTP für die Exchange WebServices verwendet und mit Exchange 2013 ist HTTP das alleinige Protokoll.

Natürlich könnte man HTTP auch einfach so über das Internet zum Exchange Server senden, aber das ist nicht für alle Umgebungen angeraten. Wir haben nun mehrere Wege, eine Verbindung aufzubauen: Aber ehe Sie nun Modems auspacken, Telefonanschlüsse stilllegen, sollten Sie ein paar Minuten auf das Thema Namensauflösung verwenden. Denn selbst wenn Sie von ihrem PC den Exchange Server über die IP-Adresse "anpingen" können, ist das noch nicht ausreichend, darüber auch Outlook zu betreiben.

RAS / DialIn

Der Abschnitt RAS/Dialin dürfte fast keine Bedeutung mehr haben, da die Einwahl per Modem oder ISDN schon fast verschwunden ist. Die Zeiten von 14.400er Modems oder gar 9600 per GSM sind zumindest in der "zivilisierten Welt" schon Vergangenheit.

Der Remote Access Dienst von Windows NT erlaubt es einem Client sich über eine Wählverbindung direkt in das lokale Netzwerk einzuwählen. In der Regel bekommt der Client dabei eine IP-Adresse aus dem internen Netzwerk und kann dann arbeiten, als wäre er im Netzwerk vor Ort. Nur die Geschwindigkeit ist natürlich nicht so schnell. Beim Einsatz von RAS ist neben TCP/IP auch das Protokoll IPX und NetBeui möglich, aber ich kann ihnen davon nur abraten. TCP/IP ist einfach das effektivere Protokoll. Unter die Thematik RAS fallen alle direkten Einwahl-Lösungen mit ihrem PC in das Firmennetzwerk über Modem, ISDN-Karte aber auch Funktelefon (GSM).

Auch wenn der Server in der Firma kein Windows Server ist sondern z.B. ein NetWare oder Unix-System oder eine Hardwarelösung (z.B. LUCEnt MAX oder Cisco), ist für Outlook der unterschied nicht zu erkennen. Sie können diese Zugang mit zusätzlichen Mechanismen schützen, z.B. Chipkarten, Einmalkennworten etc. (SecureID, etc.) oder Rückruf, um den Anrufer sicherer zu identifizieren. 

Das größte Risiko hierbei ist, dass der Benutzername und das Kennwort eines Anwenders veruntreut wird und damit jemand unbefugtes eine Verbindung in ihr Netzwerk aufbauen kann. Insofern ist es zu überlegen, ob das Zugangssystem vom Hauptnetzwerk durch einen Router oder eine Firewall abgetrennt wird, so dass nur die notwendigen Dienste passieren können.

Nachteil einer direkten Einwahl ist allerdings immer die begrenzte Bandbreite (max. 64KBit) und natürlich die Entfernung und die damit verbundenen Telekommunikationskosten (speziell aus Hotels) und die teilweise schlechte Leitungsqualität. Zudem müssen Sie als Firma ausreichend Zugangsports bereithalten, um auch in Spitzenzeiten eine Erreichbarkeit zu gewährleisten. Die Kosten können Sie aber z.B.: durch einen gebührenfrei 0800-Nummer drücken. Das könnte unterm Strich günstiger für Mitarbeiter aus Hotels sein.

VPN Pro und Kontra

Sicher werden immer mehr Dienste per HTTPS angebunden. Der Zugang zu Exchange per Outlook Webzugriff  wird von Version zu Version besser und selbst der Zugange per ActiveSync und aktuelle Tablets und Smartphones ist schon sehr leistungsfähig. Auch Sharepoint und andere Dienste nutzen HTTP oder HTTPS. Dennoch ist der Bedarf für VPNs weiter vorhanden, weil eine Firma z.B. nicht jeden Dienst, der HTTPS nutzt, auch so erreichbar machen möchte. Ein VPN ist mehr als nur ein "Tunnel" durch das unsichere Internet in das Firmen lan, sondern erlaubt eine pauschale einmalige Authentifizierung und zudem den Zugriff auf den Client. Über NAP (Network Access Policies) können bestimmte Voraussetzungen des Clients überprüft werden (Patchstand, Virenscanner etc.) und auch für das VPN können stärkere Authentifizierungsverfahren wie z.B. Smartcard, Zertifikate etc. eingesetzt werden.

Auf der anderen Seite erfordern die meisten VPNs natürlich einen Aufbau der Verbindung durch den Anwender. Zwar erlauben Lösungen wie Direct Access auch eine "permanente Verbindung" aber in der Regel ist es dem Anwender überlassen, die Verbindung aufzubauen. Nicht alle Lösungen bauen eine getrennte Verbindung automatisch wieder auf, so dass mobile Anwender z.B. im Zug nicht glücklich sein werden. Aus Sicher der Firma ist bei einer VPN-Lösung natürlich gut zu sehen, wer wie lange "online" ist und welche Datenmenge übertragen wird. Zudem können VPN-Clients auch aus der Ferne "verwaltet" werden.

Aber selbst das klassische Windows VPN kann durchaus einen "automatischen Verbindungsaufbau" veranlassen, wenn der Client eine interne Ressource erreichen will. Oder ein geplanter Task baut die Verbindung einfach permanent auf.

Nachteilig ist aber wiederrum, dass die Verbindungen per VPN bestimmte Voraussetzungen benötigen. Dazu zählt nicht nur eine Server und die Unterstützung auf dem Client, sondern auch die Erreichbarkeit verschiedener Netzwerkports. Transportprovider oder Zugangsprovider können solche Verbindungen gezielt behindern oder drosseln. Manchmal verhindert auch einfach der DSL-Router eine VPN-Verbindung, wenn er bestimmte Dienste und Ports nicht zulässt.

Eine besondere Variante eines "VPN" ist natürlich die direkte Einwahl per analogen Modem oder ISDN in einen Dialin-Zugang des Anbieters. Technisch ist dieser Weg am Aussterben da die erreichbaren Bandbreiten kaum mehr für moderne Anwendungen ausreichen und es auch aus Supportaspekten oft einfacher ist, erst eine Internet-Verbindung seitens des Anwenders aufbauen zu lassen. Hier wird der Anwender schon selbst ein Interesse an einer Funktion haben und wenn quasi erst mal der Internet-Zugriff besteht, dann kann auch eine Firma mit Fernwartungsprogrammen und anderen Werkzeugen sehr viel einfacher nach dem Fehler suchen.

Die Qual der Wahl

Wer in der Windows Welt unterwegs ist und nicht grade mit Vor-Vor-Versionen von Windows arbeiten muss, hat gleich eine ganze Reihe von VPN-Optionen. Jeder Windows-Server ist von sich aus schon VPN-Server, sofern die Rolle "Routing und Remote Access" installiert ist und auch ein Windows Client ist sehr flexibel im Bezug auf das genutzte VPN-Protokoll. Hier zwei Bilder:

Server Client

Auf dem Windows Routing und RAS-Service können Sie über die Einstellungen auf "Ports" sehr einfach bestimmten, welche VPN Protokolle vom Server angeboten werden und wie viele parallele Verbindungen dazu genutzt werden.

Auch der Windows Clients ist sehr kommunikativ. Bei der Betriebsart "Automatisch versucht er PPTP, L2TP und SSTP nacheinander. Anhängig vom VPN-Protokoll sind weiter Optionen (z.B. Authentifizierungen) möglich.

Da stellt sich ein Administrator natürlich die Frage, warum ein System so viele Optionen anbieten muss. Dies ist zum Teil der Geschichte geschuldet, das PPTP wohl das erste VPN-Protokoll von Microsoft war  und zudem verwendet jedes Protokoll einen etwas anderen Weg zu Übertragung. Je nach Provider und Technik funktionieren einige Wege nicht immer oder zuverlässig. Auch sind die zur Verfügung stehenden Authentifizierungsverfahren abweichend. Die folgende Tabelle soll daher nur als einfache erste Übersicht dienen:

Protokoll Transport Richtung Bewertung

PPTP

TCP/1723(Control)
IC 47 (GRE) Data

In +Out

Aus heutiger Sicht unsicher, da die Verschlüsselung zu schwach ist und in ca. 24h die Verschlüsselung gebrochen ist. Wurde dann noch ein schwaches Authentifizierungsverfahren genutzt, dann sind auch Anmeldedaten sehr einfach zu erhalten

L2TP

UDP/500
UDP/4500
IP/50(ESP)

In + Out

 

SSTP

TCP/443

In Only

Wenn HTTPS funktioniert und der ausgehende Proxy keine Authentifizierung erfordert, ist dieser Weg sehr universell. Leider auch durch den Overhead sehr langsam.

IKEv2

UDP/500
UDP/4500
IP/50(ESP)

In Only

IKEv2 nutzt die gleichen Ports wie L2TP nur eine moderne Version des Protokolls.

Es ist nun natürlich nicht so, dass nur Microsoft entsprechende VPNs anbietet. Es gibt eine ganze Menge von Drittanbietern, die natürlich auch eigene VPN-Zugangssysteme anbieten und entsprechende Clients für den Desktop. Interessant, da kostenfrei, kann hier z.B. OpenVPN sein.

VPN und mehrere Subnetze

VPN hat unzweifelhaft etwas mit IP-Adressen und vor allem IP-Routing zu tun. Dabei gibt es durchaus einige Fälle zu betrachten, wenn ein Client "von draußen" nach drinnen geht. Hier mal ein paar Ansätze.

Situation Beschreibung

Das ist die klassische Umgebung, die schon viele Jahre in Firmen z.B. mit dem Windows Routing und RAS-Server oder TMG betrieben wurde. Der Client kann sich auf den VPN-Server einwählen und erhält den VPN-Server als Default Gateway. Alle Pakete gehen ab sofort durch den VPN-Tunnel, es sei denn die Gegenstelle ist im lokalen Netzwerk des Clients (z.B. Drucker) oder auf dem Client gibt es abweichend konfigurierte Leitwege.

Gerade beim Zugriff auf das Internet kommen alle Schutzmechanismen der Firma auch diesem Client zugute. Allerdings kostet es auch etwas mehr Bandbreite, da Daten zweimal durch die Internetanbindung der Firma müssen.

Auch kann jeder Zugriff des Anwenders von zuhause über das VPN natürlich protokolliert werden.

Achten sie darauf aber auch die die Source-IP Umsetzung. Wenn der Client mit einer privaten IP durch den RRAS-Server ins Internet geht, dann muss die Source-IP per NAT umgesetzt werden.

Wenn es die Sicherheitsrichtlinien zulassen, kann man daher bei der VPN-Einrichtung den Eintrag zum "Default Gateway" erst einmal abschalten.

Die Zugriff auf das Internet erfolgen dann lokal und nur die IP-Adressen des Firmennetzwerk werden durch den VPN-Tunnel bedient.

By default, when a Windows-based VPN client makes a VPN connection, the VPN client automatically adds a new default route für the VPN connection and sets a higher metric für the existing default route. Because a new default route has been added, all Internet locations, except für the IP address of the tunnel server and locations based on other routes, are not reachable für the duration of the VPN connection.
Quelle: http://technet.microsoft.com/en-us/library/cc776755(v=ws.10).aspx

Das geht einfach, solange das Firmennetzwerk nur genau ein Subnetz hat.

Besteht das Firmennetzwerk aber aus mehreren Subnetzen, dann muss der Administrator schon etwas mehr tun, denn wenn das Default Gateway hier nicht mehr der VPN-Server ist, dann müssen Leitwege auf dem Client den IP-Stack dazu bringen, diese Daten durch den Tunnel zum VPN-Server zu senden. Das ist z.B. mit statischen Einträgen auf dem Client möglich oder sie nutzen die Funktion "Stateless IP Routes" über die DHCP-Option 121.

The general case solution is to configure your DHCP server to provide the proper routes to the client via option 121, "Classless Static Routes". The Windows 7 DHCP client will send a DHCPINFORM after connecting to the VPN and should receive the routes from the DHCP server
Quelle: http://serverfault.com/questions/261236/windows-server-2008-r2-rras-vpn-client-routing

DHCP Option 121 is ignored by DHCP clients prior to Windows Server 2008 and Windows Vista. This may not work if you are using a Windows Server 2008 DHCP server to assign networking configuration to these clients. Windows Vista and Windows Server 2008 DHCP clients use both Option 121 and Option 249
http://tmgblog.richardhicks.com/2009/01/08/using-dhcp-to-assign-static-routes/

http://msdn.microsoft.com/en-us/library/cc227282.aspx
The length and the data format für the Microsoft Classless Static Route Option are exactly the same as those specified für the Classless Static Route Option in [RFC3442]; the only difference is that Option Code 249 SHOULD<16> be used instead of or in addition to Option Code 121

Ein besonderer Fall ist, wenn der Client allen Traffic zum VPN-Server sendet, aber per nicht über einen Proxy geht oder der VPN-Server zugleich Internetzugang hat. Das Paket mit der "öffentlichen IP" landet beim RRAS-Server der aber als Default Gateway" das Internet hat. Also wird er das Paket selbst versuchen zu versenden und es erst einmal nicht zum Default Gateway aller anderen Systeme im internen LAN zu senden.

Man kann nun versuchen, auf dem Client und dem Server irgendwie mit NAT die Adressen umzusetzen aber eine korrekte Lösung habe ich hierzu bislang nicht finden können.

Ich betrachte daher den VPN-Server genau wie einen Client und erlaubt ihm auch die gleichen Zugriffe, wie diese einem internen Client zugestanden werden. Allerdings hier eben auf dem externen Interface Richtung Internet. Wenn zwischen Internet und dem externen Interface daher noch eine Firewall ist, dann muss diese entsprechend geöffnet werden.

Das entspricht dann aber wieder dem Szenario 1.

Sie sehen also, dass es nicht nur um ein bisschen VPN geht, sondern durchaus auch IP-Routing die Sache komplexer machen kann.

Weitere Links