bomots.de PROFESSIONELLES LINUX - UND OPEN-SOURCE-KNOW-HOW Thomas Zeller Das Praxis-Know-how für den Aufbau einer OpenVPN-Umgebung
Thomas Zeller
2 Alle Rechte vorbehalten. Ohne ausdrückliche, schriftliche Genehmigung des Verlags ist es nicht gestattet, das Buch oder Teile daraus in irgendeiner Form durch Fotokopien oder ein anderes Verfahren zu vervielfältigen oder zu verbreiten. Dasselbe gilt auch für das Recht der öffentlichen Wiedergabe. Der Verlag macht darauf aufmerksam, dass die genannten Firmen- und Markennamen sowie Produktbezeichnungen in der Regel marken-, patent- oder warenrechtlichem Schutz unterliegen. Verlag und Autor übernehmen keine Gewähr für die Funktionsfähigkeit beschriebener Verfahren und Standards. 2008 bomots verlag Herausgeber: Dr. Holger Reibold Umschlaggestaltung: bomots verlag Satz: bomots verlag Coverbild: Photocase/Manuel Langer Druck: COD ISBN: 978-3-939316-51-0 www.bomots.de
3 Inhaltsverzeichnis Vorwort... 7 1 VPNs im Überblick... 9 1.1 Was ist ein VPN?... 10 1.2 VPN-Technologien im Überblick... 11 1.2.1 VPN-Topologien... 11 1.2.2 Tunneling-Verfahren... 14 1.2.3 VPN-Protokolle... 16 1.3 Sicherheitsaspekte beim Betrieb von VPNs... 18 1.3.1 Verschlüsselung... 19 1.3.2 Authentifizierung... 19 1.3.3 Wie vertrauenswürdig ist die Gegenstelle?... 20 1.3.4 Handling... 20 2 OpenVPN die Open-Source-Alternative... 23 2.1 Was spricht für OpenVPN?... 23 2.1.1 Die neue Version 2.1... 24 2.1.2 Versionsübersicht... 28 2.1.3 Lizenzierung... 29 2.1.4 Die Sache mit TCP und UDP... 30 2.2 Betriebsmodi von OpenVPN... 31 2.2.1 Peer-to-Peer (P2P)... 31 2.2.2 Server... 32 2.2.3 Client... 32 2.2.4 Routing oder Bridging?... 33 2.2.5 TUN und TAP... 34
4 Inhaltsverzeichnis 3 OpenVPN im Einsatz... 35 3.1 OpenVPN beschaffen... 35 3.2 Signatur überprüfen... 35 3.3 OpenVPN installieren... 37 3.3.1 Linux... 37 3.3.2 Windows... 42 3.4 Authentifizierungsmechanismen von OpenVPN... 48 3.4.1 Static-Key-Mode... 48 3.4.2 SSL/TLS Mode mit Zertifikaten... 49 3.4.3 Aufbau einer PKI mit Easy-RSA... 50 3.4.4 Zertifikate zurückziehen... 59 3.4.5 Alternativen zu Easy-RSA... 60 3.4.6 Alternative Authentifizierungsmethoden über Plug-ins... 64 4 OpenVPN einrichten... 67 4.1 Linux... 67 4.1.1 Konfiguration vorbereiten... 67 4.1.2 Start automatisieren... 70 4.2 Windows... 71 4.2.1 Installation unter Windows... 72 4.3 OpenVPN-Client einrichten... 74 4.4 Routing anpassen... 76 4.5 Regeln vom Server an die Clients übermitteln... 79 4.6 Es ist so weit: Testen Sie Ihr VPN... 81 4.7 Das Management-Interface... 83 4.8 Logging... 86 5 Einsatzszenarien von OpenVPN... 89 5.1 Szenario 1: Linux OpenVPN-Server mit Road-Warriors... 89 5.1.1 Die Eigenheiten des Szenarios... 89 www.bomots.de
5 5.1.2 Konfiguration... 90 5.2 Szenario 2: Verbindung von festen Standorten mit OpenVPN-Servern 94 5.2.1 Das Szenario im Überblick... 94 5.2.2 Konfiguration... 97 5.3 Szenario 3: WLAN absichern mit OpenVPN...102 5.3.1 Das Szenario im Überblick...102 5.3.2 Konfiguration...104 5.3.3 Alternative Konfiguration im Bridging-Mode...108 6 Typische Probleme und Troubleshooting...113 6.1 Dynamische IP-Adresse an beiden Endpunkten...113 6.2 Umgang mit NAT...115 6.3 OpenVPN über HTTP- und SOCKS-Proxys...117 6.4 Port 443 ist auf dem Server bereits belegt...121 6.5 Clients haben untereinander keine Verbindung...121 6.6 Geräte im Netzwerk hinter dem VPN-Server nicht erreichbar...122 Anhang A Firewalls mit OpenVPN...125 Astaro Security Gateway...125 IPCop/Zerina...126 Endian Firewall...127 ebox Plattform...129 Untangle...131 OpenWRT...131 RedWall-Firewall...133 Anhang B Tools und Frontends...135 OpenVPN-GUI...135 Webmin-GUI...136 KVpnc...138 tunneldigger...140
6 Inhaltsverzeichnis OpenVPN Control...141 GADMIN OpenVPN Server...143 Tunnelblick...145 Danksagung...147 Über den Autor...149 Index...151 www.bomots.de
7 Vorwort Meinen ersten Kontakt mit OpenVPN hatte ich im Jahr 2005, als ich beauftragt wurde, für eine populäre Linux-Zeitschrift einen Artikel über OpenVPN zu schreiben. Bereits nach kurzer Beschäftigung mit dem Projekt war ich von der ungeheuren Flexibilität vor allem im Umgang mit dynamischen IP-Adressen, NAT und Proxys hellauf begeistert. Stellen doch diese drei Mechanismen die häufigste Hürde beim Aufbau von VPNs dar. Beim Aufbau verschiedener Testumgebungen auf unterschiedlichen Betriebssystemen lernte ich darüber hinaus sehr schnell die beinahe mühelose Konfiguration selbst komplexer VPN-Szenarien zu schätzen. Bis heute ist mir in der Open-Source-Welt kein VPN-System begegnet, das es in Sachen Flexibilität, Stabilität und Einfachheit mit OpenVPN aufnehmen könnte. Aus dieser Begeisterung heraus ist dieses Buch entstanden. Thomas Zeller (Heimsheim, im November 2008)
8 Vorwort www.bomots.de
9 1 VPNs im Überblick Im Zeitalter der Globalisierung fällt der sicheren Kommunikation über das Internet eine immer höhere Bedeutung zu. Schließlich müssen geografisch verstreute Unternehmensstandorte Daten untereinander austauschen und reisende Mitarbeiter benötigen jederzeit Zugriff auf Applikationen und Daten im Unternehmen. Virtuelle Private Netze (VPN) ermöglichen die sichere Kommunikation über das Internet und sind bereits seit Jahren fester Bestandteil der Kommunikationsinfrastruktur von Unternehmen. Neben einer Vielzahl kommerzieller und zum Teil auch proprietärer VPN-Produkte hat sich OpenVPN die SSL-VPN-Lösung aus dem Open-Source-Lager inzwischen einen festen Platz erarbeitet. Gegenüber den meist auf dem IPSec-Standard basierenden kommerziellen VPN- Produkten kann OpenVPN bei gleichwertigem Sicherheitsniveau vor allem in drei Bereichen ordentlich punkten: 1. Die Konfiguration und Administration des VPN-Servers und der Clients ist wesentlich einfacher. 2. OpenVPN kann problemlos über Firewalls, NAT-Gateways und Proxy- Server kommunizieren. 3. OpenVPN steht als Server und als Client für alle wichtigen Betriebssysteme (Windows ab Windows 2000, Linux, MacOS X, BSD und Solaris) zur Verfügung. Administratoren und Anwender schätzen OpenVPN daher gleichermaßen als zuverlässiges und robustes System, um gesicherte Verbindungen zwischen Rechnern und Netzen über das Internet herzustellen. Nicht zuletzt ist als weiterer positiver Effekt auch die Tatsache zu nennen, dass für den Einsatz von OpenVPN keine Lizenzgebühren anfallen. Der Schwerpunkt des vorliegenden Buches liegt weniger auf der erschöpfenden Abhandlung sämtlicher technischer Details von OpenVPN. Vielmehr sollen mithilfe der im Buch beschriebenen Konfigurationsszenarien auch weniger versierte Anwender und Administratoren in die Lage versetzt werden, schnell und dennoch sicher ein zuverlässiges VPN aufzubauen.
10 VPNs im Überblick 1.1 Was ist ein VPN? Die Abkürzung VPN steht für Virtuelles Privates Netz und bezeichnet zunächst lediglich die Verbindung von zwei oder mehr Computern bzw. Netzwerken über ein drittes Netzwerk mithilfe einer Tunneltechnologie. Das dritte Netzwerk muss dabei nicht zwangsläufig das Internet sein. Infrage kommen auch andere Netzwerke wie z. B. ein privates wireless LAN, das Netzwerk eines Telekommunikationsanbieters oder Energieversorgers, aber auch das ISDN- oder GSM-Netz. In der Praxis dürfte jedoch die überwiegende Mehrheit der VPNs über das Internet aufgebaut werden, da diese Netzwerkinfrastruktur praktisch flächendeckend zur Verfügung steht. Darüber hinaus benötigt heute ohnehin praktisch jeder Standort einen Internet-Zugang. Nun ist das Internet aber alles andere als ein privater Ort. Denn hier tummeln sich alle möglichen Anbieter, Anwender und auch weniger wohlmeinende Zeitgenossen. Aus diesem Grunde werden die Daten der beteiligten Netzwerke beim Transport über das Drittnetz mithilfe einer VPN-Software ver- bzw. entschlüsselt und lassen so ein Virtuelles Privates Netzwerk entstehen oder anders gesagt, Daten zwischen den beteiligten Netzwerken werden mithilfe der Verschlüsselung nur noch durch private Tunnel übertragen. Der Vollständigkeit halber möchte ich hier noch anmerken, dass es neben den im vorliegenden Buch beschriebenen VPN-Technologien noch einige weitere gibt. So bieten beispielsweise die großen Internet-Service-Provider ebenfalls VPN- Produkte an. Diese basieren aber im Gegensatz zu den hier beschriebenen Verfahren auf der Vergabe eines privaten Subnetzes an ihre Kunden innerhalb des Provider-Netzwerks. Auf diese Weise werden die Netzwerke der Kunden logisch voneinander getrennt und nur zwischen Benutzern desselben Netzwerks können Daten ausgetauscht werden. Bei dieser Art VPN werden die Daten jedoch in der Regel unverschlüsselt im Netzwerk des Betreibers übertragen und es besteht so prinzipiell die Gefahr, dass Mitarbeiter des Service-Providers Einblick in den Datenverkehr ihrer Kunden nehmen. Abhilfe schafft hier beispielsweise der Einsatz von VPN-Routern innerhalb des privaten Netzwerks des Service-Providers, die den Datenverkehr zusätzlich verschlüsseln. Eine Sonderform nimmt in diesem Zusammenhang auch die MPLS-Technologie (= Multiprotocol Label Switching) ein, die ebenfalls von großen Internet-Service- Providern als Plattform für eine verteilte Kommunikationsinfrastruktur angeboten wird. Anders als beim klassischen Routing, bei dem die Datenpakete von Router zu Router übertragen werden, überträgt MPLS Datenpakete auf einem vorsignalisierten Datenpfad. Dieses Verfahren bietet unter anderem den Vorteil, bestimmte Daten bei der Übertragung priorisieren (z. B. Sprache vor Daten) zu können. www.bomots.de
VPN-Technologien im Überblick 11 1.2 VPN-Technologien im Überblick Während wir uns im vorigen Abschnitt mit der Definition und der grundlegenden Arbeitsweise von VPNs befasst haben, wird es nun etwas konkreter. Auf den folgenden Seiten werden wir zunächst die verschiedenen Technologien verschlüsselter Kommunikation gegeneinander abgrenzen, häufig anzutreffende VPN- Topologien beschreiben und Ihnen die wichtigsten VPN-Protokolle vorstellen. Denn wer sich nicht eingehend mit der Thematik befasst, könnte aufgrund der Allgegenwärtigkeit von IPSec-basierenden VPNs zu der Überzeugung gelangen, diese wären ohne Alternative. Tatsächlich steht aber ein ganzes Bündel an Protokollen zur Verfügung, mit denen sich verschlüsselte und authentifizierte Verbindungen über unsichere Netzwerke herstellen lassen. 1.2.1 VPN-Topologien Das Host-zu-Host-Szenario stellt die einfachste aller VPN-Topologien dar, denn sie verbindet genau einen Rechner (Host) mit genau einem weiteren Rechner. Dabei übernimmt einer der beiden Rechner die Rolle des Servers, der andere verbindet sich entsprechend als Client mit dem Server. Host-to-Host-Szenarien finden sich zum Beispiel bei Heimanwendern, die von unterwegs aus auf den PC zu Hause zugreifen möchten. Aber auch wenn der Datenaustausch zwischen zwei Servern oder Arbeitsstationen in einem Unternehmensnetzwerk verschlüsselt erfolgen soll, z. B. um Lauscher fernzuhalten, bietet sich das Host-zu-Host-Szenario an. Das Host-zu-Host-Szenario. Das Client-to-Site-Szenario ähnelt der Host-to-Host-Variante. Denn auch hier verbindet sich ein VPN-Client mit einem VPN-Server. Der Unterschied zur Hostto-Host-Variante besteht darin, dass sich hinter dem Server noch ein Netzwerk mit weiteren Netzwerkgeräten befindet. Geräte in diesem Netzwerk sind für den Client
12 VPNs im Überblick ebenfalls erreichbar, sofern auf dem Server das Routing (IP-Forwarding) eingerichtet wurde. Zusätzlich wird auf dem Server eine Route benötigt, die eintreffende Pakete in das dahinter liegende Netz weiterreicht. Das Client-to-Site-Szenario beschreibt daher eine typische Remote-Access-Verbindung, z. B. wenn mobile Mitarbeiter von unterwegs auf Daten und Dienste im Netzwerk der Firma zugreifen möchten. Das Client-zu-Client-Szenario. Das Site-to-Site-VPN stellt die höchste Ausbaustufe unter den VPN-Topologien dar. Site-to-Site-VPNs verbinden zwei (oder mehrere) Netzwerke mithilfe von VPN-Gateways miteinander. Computer, die sich hinter diesen Gateways befinden, können so auf Dienste der Computer im jeweils anderen Netzwerk zugreifen, ohne sich dabei selbst um den Aufbau eines Tunnels oder die Authentifizierung kümmern zu müssen. Verschlüsselung und Authentifizierung werden also an zentraler Stelle von den beteiligten Gateways bereitgestellt. Site-to-Site-VPNs finden sich häufig bei der Vernetzung von Unternehmensstandorten, z. B. um an einem zentralen Standort einen Mailserver, Terminalserver oder andere zentrale Dienste betreiben zu können. Site-to-Site-VPNs stellen damit genau die Alternative zu per Standleitung vernetzten Standorten dar, für die Virtuelle Private Netze einmal vorgesehen waren. www.bomots.de
VPN-Technologien im Überblick 13 Das Site-to-Site-Szenario.
14 VPNs im Überblick 1.2.2 Tunneling-Verfahren In VPNs kommen verschiedene Tunnel-Verfahren zum Einsatz, insbesondere das SSH- und das SSL-Tunneling. Das Kürzel SSH (= Secure Shell) bezeichnet sowohl das Netzwerkprotokoll als auch das entsprechende Programm. Landläufig bekannt sein dürfte, dass Administratoren per Secure-Shell-Client eine verschlüsselte und authentifizierte Verbindung zu Remote-Computern herstellen können, auf denen ein Secure-Shell-Server läuft. SSH läuft vollständig im Userspace und erfordert keinerlei Modifikation am Netzwerk-Stack des Betriebssystems. SSH bietet darüber hinaus zusätzliche Funktionen wie SFTP (= Secure FTP) bzw. SCP (= Secure Copy) und stellt damit eine Alternative zu den Protokollen Telnet, rlogin, rsh und FTP dar, die sowohl Daten als auch Benutzerpasswörter im Klartext übertragen und nur über schwache Authentifizierungsmechanismen verfügen. Die Referenzimplementierung von SSH stellt das im BSD-Lager beheimatete OpenSSH-Projekt dar, es gibt aber auch einige kommerzielle Anbieter, z. B. SSH Tectia der Firma SSH Communications Security oder WinSSHD (für Windows) der Firma bitvise. Die aktuelle Protokollversion SSH-2 benutzt per Default den TCP-Port 22 und verwendet für die Authentifizierung RSA- bzw. DSA-Keys. Beim Verbindungsaufbau prüft der Client zunächst den Host-Key des SSH- Servers, um die Authentizität des Servers sicherzustellen. Sofern der Server entsprechend konfiguriert wurde, überprüft dann der Server den Key des Clients und lässt ein Login nur bei korrektem Key zu. X.509-Zertifikate, wie sie z. B. in IPSecbasierten VPNs verwendet werden, unterstützt SSH dagegen standardmäßig nicht. Über den sog. Port-Forwarding-Mechanismus erlaubt SSH außerdem das Tunneln anderer Netzwerkprotokolle, sofern diese auf TCP basieren und einen festen Port verwenden. Auf diese Weise ist es problemlos möglich, Verbindungen z. B. zu einem HTTP-, SMTP-, POP-, oder IMAP-Server durch eine bestehende SSH- Verbindung zu tunneln und damit ein äquivalentes Sicherheitsniveau wie in einem VPN zu erreichen. Um zu verhindern, dass sich Benutzer beliebige Portforwardings am Client eintragen, um so auch Dienste hinter dem SSH-Gateway zu nutzen, die vom Administrator nicht freigegeben wurden, müssen die Portforwardings allerdings auch in der Konfigurationsdatei am SSH-Server eingetragen werden. SSH bietet damit zwar eine Reihe ähnlicher Vorteile, wie sie in VPNs üblich sind, taugt aber aufgrund der Einschränkung beim Tunneln nicht-tcp-basierter Protokolle und der fehlenden Unterstützung von X.509-Zertifikaten zur Authentifizierung nicht als vollständiger Ersatz zu VPNs. Bei Secure Socket Layer (SSL), respektive dessen Nachfolger Transport Layer Security (TLS) handelt es sich um ein Verschlüsselungsprotokoll, das entwickelt www.bomots.de
VPN-Technologien im Überblick 15 wurde, um Protokollen ohne eigene Sicherheitsmechanismen verschlüsselte und authentifizierte Verbindungen zur Verfügung zu stellen. Allgemein bekannt ist SSL/TLS heute vor allem durch die Sicherung des HTTP- Protokolls, z. B. für das Onlinebanking. SSL-gesicherte HTTP-Verbindungen sind erkennbar am angehängten s (https://). Die bekannteste Implementierung von SSL ist OpenSSL. Mit GnuTLS existiert daneben aber auch noch eine weitere. Neben der Verschlüsselung, die in der Praxis hauptsächlich durch den RSA- bzw. AES- Standard erfolgt, bietet SSL/TLS auch eine Authentifizierung über (X.509) Zertifikate. Ähnlich wie bei SSH erlaubt SSL/TLS ebenfalls das Tunneln anderer Protokolle, indem IP-Pakete vollständig in SSL gekapselt werden. Seine Eigenschaften prädestinieren SSL/TLS daher auch zum Einsatz in VPNs, da SSL/TLS im Gegensatz zu beispielsweise IPSec problemlos mit NAT (Network Address Translation) oder Proxys zusammenarbeitet. Seit einigen Jahren haben sich SSL-VPN Lösungen verschiedener Hersteller am Markt etabliert. Diese SSL- VPNs arbeiten zum Teil Client-los, das heißt, dass zur Nutzung von Netzwerkdiensten auf Client-Seite lediglich ein Webbrowser und ggf. ein Plug-in (z. B. Java) erforderlich ist. Andere SSL-VPN-Lösungen, darunter OpenVPN, benötigen dagegen einen Client auf Anwenderseite. Der Unterschied dieser beiden Ansätze ist, dass die Client-less-Lösungen keinen vollständig transparenten Netzwerkzugriff erlauben, sondern wie beim SSH- Tunneling je Protokoll einen eigenen Tunnel benötigen. Der Vorteil eines SSL- VPNs, bei dem aufseiten des Anwenders ein Client zum Einsatz kommt, besteht also im Wesentlichen darin, dass eine vollständige Netzwerktransparenz (wie bei IPSEC) erreicht wird. Die Kompatibilität zu NAT & Co. bleibt dabei vollständig erhalten und die gesamte VPN-Kommunikation läuft über nur einen einzigen TCPoder UDP-Port.
16 VPNs im Überblick 1.2.3 VPN-Protokolle Virtuelle Private Netzwerke greifen auf verschiedene Protokolle für die Sicherung das Datenverkehrs zurück. Die wichtigsten sind PPTP, L2TP und IPSec. Das Point-to-Point-Tunneling-Protocol (PPTP) ist ein VPN-Protokoll, das vor allem in Windows-lastigen Netzwerken weit verbreitet ist. Hintergrund dafür ist, dass PPTP von einem Herstellerkonsortium entwickelt wurde, dem u. a. auch Microsoft angehört. Aus technischer Sicht erlaubt PPTP das Tunneln von PPP- Paketen, die ihrerseits zuvor in GRE-Pakete (Generic Routing Encapsulation) verpackt wurden. Die Konsequenz daraus ist, dass PPTP-VPNs zwei Ports, nämlich TCP-1723 und IP-Protokoll 47 (für GRE), benötigen. Der Hauptkritikpunkt an PPTP ist aber, dass die Verschlüsselungsstärke direkt von der Qualität des gewählten Passworts abhängt. Ist das Passwort gut gewählt (> 12 Zeichen), kann auch PPTP als ausreichend sicher betrachtet werden. Windows XP kann ohne zusätzliche Client-Installation Verbindungen zu PPTP-Servern herstellen. Das Layer-2-Tunneling-Protocol (L2TP) stellt eine Kombination der Protokolle PPTP und des älteren L2F (Layer-2-Forwarding-Protocol) dar. L2TP bietet zwar eine Authentifizierung nach dem PAP/CHAP-Verfahren, bringt aber keine eigene Verschlüsselung mit. Die fehlende Verschlüsselung wird daher in der Regel durch das IPSec-Protokoll nachgerüstet, man spricht dann von L2TP over IPSec. Windows-XP-Nutzer schätzen L2TP over IPSec, weil Windows XP zum einen über das DFÜ-Netzwerk bereits über die notwendige Funktionalität verfügt und so kein VPN-Client mehr installiert werden muss. Zum anderen kann die Authentifizierung durch den ergänzenden Einsatz des IP- Sec-Protokolls mithilfe von X.509 Zertifikaten erfolgen, was die Sicherheit vor allem im direkten Vergleich mit PPtP dramatisch erhöht. Soll L2TP over IPSec hinter einem NAT-Router genutzt werden, muss die IPSec-NAT-T-Funktionalität durch Windows XP Service Pack 2 nachgerüstet und am Router die folgenden Ports geöffnet werden: 500/UDP (IKE) 4500/UDP und IP-Protokoll 50 (IPSEC ESP). IPSec (IP-Security) stellt die technische Basis für die überwiegende Mehrzahl der VPN-Verbindungen dar. IPSec ist kein einzelnes Protokoll, sondern eine ganze Protokollfamilie. Denn Bestandteil von IPSec sind die Protokolle Authentication Header (AH), Encapsulated Security Payload (ESP) und Internet Key Exchange (IKE). AH und ESP sind dabei für die Authentifizierung und Verschlüsselung der Datenpakete zuständig, während IKE für den Schlüsselaustausch der VPN-Partner verantwortlich zeichnet. Für die eigentliche Authentifizierung kommen bei IPsec- VPNs entweder das Preshared-Key-Verfahren (PSK) oder die zertifikatsbasierte Authentifizierung mittels X.509-Zertifikate infrage. www.bomots.de
VPN-Technologien im Überblick 17 Entwickelt wurde IPSec Ende der neunziger Jahre eigentlich für IPv6 und wurde dann auf IPv4 portiert. IPSec-VPNs sind auf der IP-Ebene (Netzwerkschicht) angesiedelt und sichern damit eine vollständige Netzwerkverbindung nicht nur einzelne Applikationsprotokolle. IPSec hat sich aufgrund dieser Eigenschaften zum De-facto-Standard entwickelt und ist gut für die Vernetzung verteilter Standorte geeignet. Als nachteilig hat sich hingegen die äußerst hohe Komplexität von IPSec sowohl bei der Implementierung und vor allem auch bei der Fehleranalyse erwiesen. Ein weiterer gravierender Nachteil bei der Nutzung von IPSec-Clients hinter NAT- Gateways und Firewalls ist die fehlende Kompatibilität zwischen IPsec und NAT. Unterstützt der jeweilige Router oder die Firewall nicht den NAT-T-Mechanismus (NAT Traversal), lässt sich keine IPSec-Verbindung zum Ziel aufbauen.
18 VPNs im Überblick 1.3 Sicherheitsaspekte beim Betrieb von VPNs Die wichtigsten technischen Aspekte beim Betrieb jeder Datenkommunikation sind die Wahrung der Vertraulichkeit, der Integrität, der Authentifizierung und der Verfügbarkeit. Dies gilt natürlich in besonderem Maße für VPN-Verbindungen, deren eigentlicher Zweck es ja gerade ist, diese Zielsetzung der sicheren Kommunikation zu erreichen. Vertraulichkeit wird im VPN durch die Verschlüsselung der Datenpakete erreicht. Die Integrität der Daten, also der Nachweis darüber, dass Daten so ankommen, wie sie verschickt wurden, wird durch kryptografische Hashfunktionen sichergestellt. Für die Authentifizierungsprüfung unterstützen VPNs in der Regel Mechanismen wie Zertifikate, Schlüsseldateien, Passwörter und zum Teil auch Geräte mit 2- Faktor-Authentifizierung. Zu diesen Geräten gehören z. B. kryptografische Tokens, die durch eine PIN geschützt sind und Einmalpasswörter generieren können. Aber auch Smartcards sind Geräte zur 2-Faktor-Authentifizierung, denn zur Verwendung sind zwei Faktoren, nämlich etwas, das man besitzt (Token, Smartcard), und etwas, das man weiß (PIN, Passwort), erforderlich. Die Verfügbarkeit schließlich wird wie bei anderen Prozessen in der Informationstechnologie durch die Schaffung von Redundanzen erreicht. Denn auch das sicherste VPN basiert letztlich auf Hardware, die durch verschiedene Umstände ausfallen kann (Energieversorgung, technischer Defekt usw.). Doch auch die VPN- Software selbst kann, beispielsweise durch einen Denial-of-Service-Angriff, lahmgelegt werden. Unter Denial-of-Service versteht man die vorsätzliche Außer- Betriebsetzung eines Diensts, z. B. indem dieser mit einer größeren Anzahl von Anfragen belastet wird, als das betreffende System abarbeiten kann. Neben diesen technischen Aspekten spielen aber auch organisatorische Überlegungen eine wichtige Rolle beim Design von Virtuellen Privaten Netzen. Denn was nutzt die beste Authentifizierung, wenn Anwender sorglos mit ihren Keys und Zertifikaten umgehen oder ihre Passwörter für jedermann lesbar notieren? Weiterhin kann auch die beste VPN-Software Lücken, die durch administrative Fahrlässigkeit bei der Installation und Konfiguration der Software entstanden sind, nicht ausgleichen. Nach der Devise Keep it simple ist daher auch die Übersichtlichkeit in der Konfiguration und Bedienung von größter Bedeutung. www.bomots.de
Sicherheitsaspekte beim Betrieb von VPNs 19 1.3.1 Verschlüsselung Für die Verschlüsselung im VPN kommen je nach VPN-Protokoll unterschiedliche Verschlüsselungsverfahren zum Einsatz. IPSec-VPNs verschlüsseln ihre Daten mithilfe von ESP, das verschiedene Verfahren für die eigentliche Verschlüsselung einsetzt. Dazu gehören DES, 3DES, IDEA, Cast und Blowfish. Grundsätzlich hängt die Sicherheit der Verschlüsselung von der Schlüssellänge ab. OpenVPN verwendet für die Verschlüsselung der Datenpakete entweder statische Schlüssel oder die OpenSSL-Library. Kommt OpenSSL zum Einsatz, kann OpenVPN damit sämtliche Verschlüsselungsverfahren und Schlüssellängen verwenden, die von OpenSSL unterstützt werden. In der Default-Einstellung nutzt OpenVPN eine Blowfish-Verschlüsselung mit einer Schlüssellänge von 128 Bit. Durch eine einfache Konfigurationsänderung können Sie OpenVPN aber auch anweisen, stattdessen eine AES-Verschlüsselung mit 256-Bit-Key zu verwenden. 1.3.2 Authentifizierung Mit Authentifizierung wird im VPN der Vorgang zur Überprüfung der Berechtigung eines Benutzers oder einer Gegenstelle bezeichnet. Infrage kommen hier im Wesentlichen die Authentifizierung per Passphrase oder alternativ die Verfahren Preshared Key (PSK) bzw. die zertifikatbasierte Authentifizierung. Die ausschließliche Authentifizierung aufgrund einer Passphrase ist schon lange nicht mehr zeitgemäß. Schließlich lassen sich Passwörter ausspähen oder durch Brute-Force- Attacken auch erraten. Besser ist da schon das Preshared-Key-Verfahren geeignet, bei dem ein zuvor vereinbarter Schlüssel mit allen Beteiligten vereinbart und ausgetauscht wird. Nur wer im Besitz des richtigen Schlüssels ist, darf dann am VPN teilnehmen. Scheidet allerdings einer der Beteiligten aus, muss der bisher vereinbarte Schlüssel geändert und erneut an die übrigen Beteiligten verteilt werden. Bei hohen Benutzerzahlen ein nicht zu unterschätzender Organisationsaufwand. Die sicherste, wenngleich auch aufwendigste Variante zur Authentifizierung stellt die zertifikatbasierte Authentifizierung dar. Beim zertifikatbasierten Authentifizierungsverfahren wird an jeden Teilnehmer ein digitales Zertifikat (X.509 Zertifikat) ausgegeben, dessen Gültigkeit anhand des Public Keys der ausgebenden Zertifizierungsinstanz (Certificate Authority, CA) und mithilfe sog. Zertifikatrückzugslisten (Certificate Revocation List, CRL) überprüft werden kann. Die Gültigkeit von Zertifikaten kann im Vorfeld festgelegt werden. Ist ein Zertifikat abgelaufen, ist keine Anmeldung am VPN mehr möglich. Weiterhin hat der Administrator die
20 VPNs im Überblick Möglichkeit, Zertifikate mithilfe der Certificate Revocation List auch manuell für ungültig zu erklären. 1.3.3 Wie vertrauenswürdig ist die Gegenstelle? Eine Frage, die Sie sich vor der Anbindung einer Außenstelle oder eines Remote- Benutzers stets stellen sollten, ist die nach der Vertrauenswürdigkeit der Gegenstelle. Denn schließlich wollen Sie sich ja nicht Probleme wie beispielsweise die Viren eines per VPN verbundenen PCs in Ihr Netzwerk importieren. Denken Sie auch daran, dass ein für den VPN-Betrieb vorkonfiguriertes Notebook ohne zusätzliche Schutzmechanismen, etwa eine Festplattenverschlüsselung oder zumindest ein Verbindungspasswort, von jedermann dazu genutzt werden kann, auf Ihr Netzwerk zuzugreifen. In Abhängigkeit von der Vertrauenswürdigkeit einer VPN-Gegenstelle sollten Sie also entscheiden, für welche Protokolle Sie eine Gegenstelle überhaupt zulassen. Denn wird per VPN lediglich Zugriff auf den zentralen Mailserver über das VPN benötigt, besteht ja nicht zwangsläufig die Notwendigkeit, diesen Client auch für den Zugriff auf Fileshares freizuschalten. Gut geeignet für weniger vertrauenswürdige Gegenstellen sind z. B. Terminalserverprotokolle, die den grafischen Zugriff auf Applikationen erlauben, aber keine vollständig transparente Verbindung zwischen den beteiligten Partnern erfordern. Die meisten dieser Protokolle können sogar problemlos über SSH getunnelt werden. Dazu gehören z. B. die Protokolle ICA (Citrix) und RDP unter Windows, bzw. X11 oder VNC unter Linux vorausgesetzt, diese wurden entsprechend sorgfältig konfiguriert. 1.3.4 Handling Einen weiteren, nicht zu unterschätzenden Aspekt bei der Planung und Konfiguration eines VPN, stellt auch die Handhabung des Systems selbst dar. Sie sollten sich daher bereits in der Designphase klarmachen, welchen Aufwand Sie bei der anstehenden Konfiguration treiben müssen. Denn nicht nur für das eigentliche Setup, sondern insbesondere dann, wenn Probleme im VPN-Betrieb auftreten, werden Sie ein übersichtlich konfiguriertes System und aussagekräftige Logfiles zu schätzen wissen. Und gerade in diesem Bereich kann OpenVPN enorm punkten, denn OpenVPN arbeitet komplett im Userspace und erfordert daher keine Modifikation am Kernel. Die Konfigurationsdateien sind einfach strukturiert und gut lesbar. Weiterhin kön- www.bomots.de
Sicherheitsaspekte beim Betrieb von VPNs 21 nen die Konfigurationsdateien praktisch ohne Änderungen auch mit OpenVPN Servern unter verschiedenen Betriebssystemen eingesetzt werden.
22 VPNs im Überblick www.bomots.de
Sicherheitsaspekte beim Betrieb von VPNs 23 2 OpenVPN die Open-Source-Alternative Nachdem wir uns im ersten Kapitel mit der grundsätzlichen Arbeitsweise von VPNs auseinandergesetzt haben, beschäftigen wir uns ab hier ausschließlich mit OpenVPN. Bevor wir im dritten Kapitel dann in die eigentliche Installation und Konfiguration von OpenVPN auf unterschiedlichen Plattformen und für verschiedene Einsatzszenarien einsteigen, liefert dieses Kapitel noch einige Hintergrundinformationen zur Arbeitsweise von OpenVPN. 2.1 Was spricht für OpenVPN? Für den Einsatz von OpenVPN sprechen verschiedene Dinge. Hier sind insbesondere die breite Betriebssystemunterstützung sowie die Offenheit und Kompatibilität zu nennen. Hinsichtlich der unterstützten Betriebssysteme dürfte es nicht wirklich viele Alternativen zu OpenVPN geben. Denn mit OpenVPN können Sie Ihren VPN-Server oder VPN-Client auf praktisch allen verbreiteten Betriebssystemen nutzen: Linux (ab Kernelversion 2.2) Solaris OpenBSD (ab Version 3.0) Mac OS X Darwin FreeBSD NetBSD Windows (ab Windows 2000) Leider scheitert der Einsatz von OpenVPN nur allzu häufig daran, dass es nicht zu den Endgeräten anderer Hersteller kompatibel ist. Sobald Sie es also mit Infrastrukturen zu tun haben, deren VPNs beispielsweise auf IPSec basieren, werden Sie es mit der Einführung von OpenVPN schwer haben. Allerdings bietet sich der Aufbau eines OpenVPN-Servers, aber auch in IPSec-dominierten Infrastrukturen an. Nämlich dann, wenn es darum geht, parallel zu einer bestehenden Site-to-Site- Anbindung einen Remote-Access für mobile Benutzer einzurichten.
24 OpenVPN die Open-Source-Alternative Müssen Sie hingegen keine Rücksicht auf bereits vorhandene Strukturen nehmen, ist OpenVPN aufgrund seiner Offenheit und der Verwendung offener Standards eine echte Alternative zu kommerziellen Produkten. Als Argumente für OpenVPN seien hier exemplarisch nur die Unterstützung dynamischer IP-Adressen, die Kompatibilität zu Network Address Translation (NAT) und die praktisch freie Auswahl der Authentifizierungsmethoden (Passwort, Zertifikat, Smartcard, Radius/One- Time-Passwords usw.) genannt. 2.1.1 Die neue Version 2.1 Seit James Yonan, der Erfinder und Haupt-Entwickler von OpenVPN, im Mai 2001 die erste Version 0.90 von OpenVPN veröffentlichte, ist das Projekt stark gewachsen. Denn die OpenVPN-Community umfasst nach Angaben auf der Projektseite http://openvpn.net zwischenzeitlich rund 2,5 Millionen User, die Software wird etwa 150.000mal pro Monat heruntergeladen. Der derzeit aktuelle und stabile Zweig von OpenVPN ist Version 2.0 mit dem Release 2.0.9. Die Entwicklung des Folgezweigs 2.1 ist allerdings schon sehr weit vorangeschritten und hat das Beta-Stadium bereits seit Längerem hinter sich gelassen. Zum Zeitpunkt der Entstehung dieses Buchs war Release Candidate 13 der Version 2.1 aktuell (veröffentlicht am 09. Oktober 2008). Es ist daher sehr wahrscheinlich, dass mit Erscheinen dieses Buchs die endgültige Version 2.1 bereits freigegeben ist. Aus diesem Grunde basieren alle unsere im Kapitel OpenVPN im Einsatz vorgestellten Beispielszenarien und Konfigurationen auch auf diesem Release Candidate. Schauen wir uns an, was sich verändert hat. OpenVPN 2.1 bringt viele Neuerungen, die den Einsatz von OpenVPN weiter vereinfachen: OpenVPN läuft jetzt unter Windows Vista und zwar sowohl in der 32- als auch in der 64-Bit-Variante. Der TAP-Win32 Netzwerkadapter benötigt zum Öffnen nun nicht mehr zwingend Administratorenrechte. In der Windows-Version von OpenVPN wird die grafische Benutzeroberfläche OpenVPN-GUI nun automatisch mit installiert. Nur unter Windows verfügbar ist die neue Direktive --auto-proxy. Wird diese Direktive verwendet, versucht OpenVPN über die Windows-InternetQueryOption- API die korrekten Proxy-Einstellungen zu ermitteln. www.bomots.de
Sicherheitsaspekte beim Betrieb von VPNs 25 Mithilfe des neuen Features Topology Subnet können Sie in TUN-basierten VPNs Clients nun jedem Client genau eine IP-Adresse zuteilen, statt wie bisher je vier (/30 Subnetzmaske). Die Direktive wird in der Konfigurationsdatei in der folgenden Form angegeben: topology mode Folgende Parameter kommen als mode infrage: net30 Wie bisher wird pro Client ein 30er-Subnetz vergeben. Sollen sich auch Windows-Clients mit dem Server verbinden, ist dieser Parameter obligatorisch! p2p Verwendet eine Point-to-Point-Topologie und weist jedem (nicht- Windows) Client genau eine IP-Adresse zu. subnet Auch dieser Parameter weist jedem Client nur eine IP-Adresse zu, funktioniert im Gegensatz zu p2p aber auch mit Windows-Clients. Dabei müssen sowohl der Client als auch der Server OpenVPN in Version 2.1 einsetzen. Unter Windows muss zusätzlich mindestens Version 8.2 des TAP-Win32-Treibers installiert sein. Weitere Neuerungen sind: Durch die Implementierung des PKCS#11-Formats können nun auch Smartcards verwendet werden, die das Zertifikat und den Key in einer Containerdatei erwarten. Das Port-Share Feature für den SSL-Port ermöglicht es nun, auf dem gleichen Server einen SSL-Webserver und OpenVPN auf Port 443-TCP zu betreiben. Multiline-Parameterlisten und Inline-Zertifikate im XML-Stil erlauben es nun, Zertifikate, Plug-ins und Push-Direktiven direkt in die Konfigurationsdatei zu schreiben, sodass keine externen Dateien mehr verwendet werden müssen. Dazu ein Beispiel. Bisher erfolgt die Angabe beispielsweise des CA-Zertifikats in der folgenden Form: ca /etc/openvpn/ca.crt In Version 2.1 können Sie die gleichen Informationen direkt in die Konfigurationsdatei schreiben:
26 OpenVPN die Open-Source-Alternative <ca> -----BEGIN CERTIFICATE----- MIIEgDC- CA2igAwIBAgIJAO++FtScSLO/MA0GCSqGSIb3DQEBBQUAMIGGMQswCQYDVQQG EwJERTELMAk- GA1UECBMCQlcxEjAQBgNVBAcTCUhlaW1zaGVpbTEVMBMGA1UEChMMT3BlblZQ Ti1UZXN0MRgwFgYDVQQDEw9PcGVuVlBOLVRlc3QgQ0ExJTAjBgkqhkiG9w0BC QEWFk9wZW5WUE5AbnVyZnVlcnNwYW0uZGUwHhcNMDgwNzIyMTYzMjIzWhcNMT gwnziwmtyzmjizwjcbhjelmak- GA1UEBhMCREUxCzAJBgNVBAgTAkJXMRIwEAYDVQQHEwlIZWltc2hlaW0xFTAT BgNVBAoT- DE9wZW5WUE4tVGVzdDEYMBYGA1UEAxMPT3BlblZQTi1UZXN0IENBMSUwIwYJK ozihvcnaqkbfhzpcgvuvl- BOQG51cmZ1ZXJzcGFtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgK CAQEAvUJ3kd+T7WqdQqTacjCoKsb0PtGL0Z5yrb/xf4zROTbv0nTmwMf4A+rB8lf8J zpa8fbjyyex56mxxsxpixuykgvptnjq816wx0q2zonkeoa+ei1c+jjhkhqygd M4Udb8FrzyjyHM6NlOZg2Ix+/QL4x2HGz0n4LEKYL1b4wlpqNK+Teiq4/Ucb4 5GaMo2rtpZeqyHAkydZ0ZPFMQcZVzHjKuL+ll1EqCiti0oi6bKlzoe5r4kUKZ LKq3UH/rQpGFZuqCzCDiqC2EDzpdUYF0cPa7CIK9NSwNtjvYIr9/fEisiUTDu DAQtwt07V8nfyE1bDh62A89+j468q9DHls3qwIDAQABo4HuMIHrMB0GA1UdDg QWBBQ4+Y5vBXmVtvY6JOoompMW4c3s8TCBuwYDVR0jBIGzMIGwgBQ4+Y5vBXm VtvY6JOoompMW4c3s8aGBjKSBiTCBhjELMAkGA1UEBhMCREUxCzAJBgNVBAgT AkJXMRIwEAYDVQQHEwlIZWltc2hlaW0xFTATBgNVBAoTDE9wZW5WUE4tVGVzdDEYMBYGA1UEAxMPT3B lblzqti1uzxn0ienbmsuwiwyjkozihvcnaqkbfhzpcgvuvlboqg51cmz1zxjz cgftlmrlggka774w1jxis78wdaydvr0tbauwaweb/zanbgkqhkig9w0baqufa AOCA- QEAT+bwHo3ge/3gb7pOgNWTyxMB3LjFgnmbT9veoMEwCp3WVL5S5qvcihLV6f NrUQfC2t73IyJluJY5s6oVaWzr5KenUPk652wPdL7w9J40jLSvnjvs3et1Z49 b6zffbpheggujfe3rg5scyiglyu6espndopjw/ev5r0frtg3rvce0q8zyi6ym Nt7zxZcwh4Q1NJ0p7ja9tphgdQPCjElI8BP0G/sh0h01U9SGPBidwIQTEnnDi jhts0398pa2roz6jf+f3ibzahhzsxphqche/kkf9rvgh1w3r9b4a727b6hykf bahs1nd4ieumubdkxyevhjxlw81ip38bpnvpo0zq== -----END CERTIFICATE----- </ca> www.bomots.de
Sicherheitsaspekte beim Betrieb von VPNs 27 Das funktioniert auch mit Plug-ins und Push-Direktiven: <plugin> /usr/lib/openvpn/openvpn-auth-pam.so openvpn </plugin> <push> redirect-gateway def1 route-gateway 192.168.1.254 </push>
28 OpenVPN die Open-Source-Alternative 2.1.2 Versionsübersicht Für Interessierte haben wir nachfolgend eine kurze Chronik der Entwicklung von OpenVPN nachgezeichnet: Mai 2001 Das erste Release (Version 0.90) unterstützt Linux und kann IP-Tunnel über UDP herstellen. Zur Verschlüsselung verwendet das System Blowfish, zum Signieren von Paketen kommt die SHA1 HMAC Signatur zum Einsatz. März 2002 Version 1.0 verwendet erstmals TLS für die Authentifizierung und den Schlüsseltausch, eine Manpage wird geschrieben. April 2002 Version 1.1.0: Portierung auf OpenBSD, der Schutz vor Replay-Attacken wird verstärkt und ein Feature für das Traffic-Shaping kommt hinzu. Mai 2002 Mit Version 1.2.0 wird das System auf Solaris portiert und die Konfiguration kann erstmals mittels Konfigurationsdatei erfolgen. Oktober 2002 Version 1.3.2 unterstützt nun auch NetBSD und erhält IPv6-Support für Linux über das TUN-Interface. Juli 2003 Die Portierung auf die Windows-Plattform beginnt mit Version 1.4.2. November 2003 Mit Version 1.5.0 ist ein weiterer Meilenstein erreicht. OpenVPN unterstützt nun Windows 2000 und XP. Mai 2004 Version 1.6.0 bringt OpenSSL für Windows-Installationen im Bundle mit und kann nun auch unter Windows mit DHCP arbeiten. April 2005 Version 2.0 erscheint nach 20 Betaversionen und 21 Release-Candidates. OpenVPN bindet das PAM-Modul ein und erhält die easyrsa Skripte. August 2005 Mit Version 2.0.1 halten die Easy-RSA-Skripte 2.0 Einzug in OpenVPN. November 2005 Ab Version 2.0.4 kann OpenVPN beim Setzen des Default-Gateways die Route mit der niedrigsten Metrik wählen. April 2006 OpenVPN unterstützt Ethernet Bridging nun auch unter NetBSD. Februar 2007 Der zweite Release Candidate der neuen Version 2.1 erscheint, insbesondere die Windows-Version erfährt zahlreiche Änderungen, nachdem Windows Vista nun verfügbar ist. www.bomots.de
Sicherheitsaspekte beim Betrieb von VPNs 29 April 2007 Version 2.1_rc3 erhält OpenVPN-GUI als Installationsoption in der Windows-Version. Januar 2008 OpenVPN 2.1 RC-7 kann unter Linux nun vollständig unter einem nicht-privilegierten Benutzeraccount laufen, Windows Vista wird unterstützt. September 2008 OpenVPN 2.1 RC-12 erhält unter anderem einen DHCP-Proxy-Modus, mit dem VPN-Clients im Bridging-Mode den DHCP-Server hinter dem OpenVPN-Server transparent nutzen können. Oktober 2008 Mit OpenVPN 2.1 RC-13 kann das Management- Interface neben den schon bekannten TCP-Sockets jetzt auch Unix Domain Sockets verwenden. Mithilfe der Direktiven management-client-user und management-client-group lässt sich jetzt auch kontrollieren, welche Prozesse sich mit dem Socket verbinden dürfen. 2.1.3 Lizenzierung OpenVPN steht als freies Open-Source-Projekt unter der GPL-Lizenz zur Verfügung. Das Programm darf damit kostenlos genutzt und der Quelltext darf im Rahmen der Bestimmungen der GNU Public License jederzeit an die eigenen Bedürfnisse angepasst werden. Zusätzlich bietet James Yonan mit seinem Partner Francis Dinha über seine Firma OpenVPN Technologies, Inc. auch kommerzielle Lizenzen von OpenVPN an. Das Angebot richtet sich an Hersteller, die OpenVPN modifizieren und ihre proprietären Änderungen an der Software nicht wie in der GNU Public License vorgesehen publizieren wollen.
30 OpenVPN die Open-Source-Alternative 2.1.4 Die Sache mit TCP und UDP Für die VPN-Kommunikation über TCP/IP wird ein entsprechendes Transportprotokoll benötigt. Im Gegensatz zu den meisten anderen VPN-Produkten können Sie bei OpenVPN sowohl das zu verwendende Protokoll, TCP oder UDP, als auch den Port, der für dieses Protokoll verwendet wird, nach Belieben festlegen. Diese Freiheit ist ungeheuer hilfreich, zum Beispiel wenn es darum geht, VPN-Tunnel aus restriktiv verwalteten Netzwerken aufzubauen. Schließlich lässt nicht jeder Firewall-Administrator die Nutzung beliebiger Protokolle und Ports zu. In den meisten öffentlichen Netzwerken für den Internetzugriff, z. B. am öffentlichen WLAN Hotspot oder im Hotelnetzwerk, ist der Aufruf von HTTPS-Webseiten möglich. Konfigurieren Sie Ihren OpenVPN-Server in der Firma oder zu Hause dann einfach so, dass er den TCP-Port 443 verwendet, können Sie problemlos eine VPN-Verbindung aufbauen. Das funktioniert sogar dann, wenn im besagten Netzwerk Proxy-Zwang herrscht. Typischerweise werden öffentliche Internetzugänge über ein NAT-Device (Router oder Firewall) geführt. Auch mit NAT (= Network Address Translation) kommt OpenVPN problemlos zurecht. In der Default-Einstellung verwendet OpenVPN das Protokoll UDP und den Port 1194. Das verbindungslose UDP-Protokoll bietet die optimale Basis für die Kommunikation von OpenVPN. Denn zum einen basieren die meisten Protokolle, die Sie später über den Tunnel verwenden werden, ohnehin auf TCP (TCP über TCP zu tunneln ist keine gute Idee) und zum anderen ist UDP aufgrund der nicht vorhandenen Fehlerkontrolle einfach das schnellere Protokoll. Die Verwendung von TCP als Transportprotokoll ist also eher die zweite Wahl und sollte immer dann zum Einsatz kommen, wenn UDP aufgrund einer restriktiv konfigurierten Firewall keine Alternative darstellt oder wenn die Dienste, die später über das VPN genutzt werden sollen, selbst im Wesentlichen auf UDP basieren. www.bomots.de
Betriebsmodi von OpenVPN 31 2.2 Betriebsmodi von OpenVPN In den Versionen < 1.6 unterstützte OpenVPN lediglich den Point-2-Point-Modus. Dieser benötigte pro Verbindung eine eigene Konfigurationsdatei und einen eigenen TCP- oder UDP-Port pro Verbindung. Sollten also vier Clients mit einem OpenVPN-Server kommunizieren, mussten auf dem Server vier Konfigurationsdateien erstellt und je ein eigener Port für die Kommunikation geöffnet werden, natürlich auch in der Firewall. So kommunizierte Client 1 dann beispielsweise mit dem UDP-Port 1194, Client 2 mit dem UDP-Port 1195 usw. Auch in den aktuellen Versionen verwendet OpenVPN per Default den Point-2-Point-Modus. Dieser ist aber nur dann ideal, wenn Sie eine überschaubare Anzahl von Standorten miteinander verbinden möchten. Auf den folgenden Seiten werden die aktuellen Betriebsmodi sowie grundlegende Eigenschaften und Konzepte von OpenVPN beschrieben. 2.2.1 Peer-to-Peer (P2P) Sofern in der OpenVPN-Konfigurationsdatei nichts anderes angegeben wurde, verwendet das Programm als Standardbetriebsmodus traditionell den Point-to- Point-Modus. Sie sollten allerdings darauf achten, den Betriebsmodus explizit in der Konfigurationsdatei aufzuführen, da die Konfigurationsdatei so leichter verständlich ist. Wie schon im letzten Absatz angeführt, erfordert der Point-to-Point Modus für jeden Tunnelendpunkt eine eigene Konfigurationsdatei und verwendet exklusiv einen eigenen TCP- oder UDP-Port. In der Praxis werden Sie den Pointto-Point-Modus daher nur einsetzen wollen, wenn Ihr VPN lediglich aus zwei Teilnehmern besteht. Der Peer-to-Peer-Modus wird in der Konfigurationsdatei mit der Direktive mode p2p aktiviert.
32 OpenVPN die Open-Source-Alternative 2.2.2 Server Für typische Remote-Access-Szenarien, bei denen sich mehrere Benutzer über einen zentralen Server in ein Netzwerk einwählen, ist der Server-Modus weit besser geeignet. Denn in diesem Modus werden alle eingehenden Verbindungen von einem einzigen Serverprozess verwaltet und es muss in der Firewall daher auch nur ein Port geöffnet werden. Es versteht sich von selbst, dass die Beschränkung auf eine einzelne Konfigurationsdatei natürlich ebenfalls die Administration und Wartung vereinfacht. Der Server-Modus wird in der OpenVPN-Konfigurationsdatei mit der Direktive mode server aktiviert. 2.2.3 Client Das OpenVPN-Gegenstück zum Server-Modus stellt der Client-Modus dar. Die Definition eines Teilnehmers als Client erfolgt wie beim Server- und P2P-Modus über die Konfigurationsdatei, in der nun das Schlüsselwort client verwendet wird. Im Client-Modus bietet OpenVPN die Möglichkeit, mehrere Clients mit einer spezifischen Client-Konfiguration auszustatten. Auf diese Weise kann der Server beispielsweise IP-Adressen an die Clients verteilen oder die Routing-Tabelle auf dem Betriebssystem des Clients manipulieren. Grundsätzlich erlaubt OpenVPN die Verwendung ein- und derselben Konfigurationsdatei für eine große Anzahl Clients. In Abhängigkeit von der gewählten Authentifizierungsmethode static Key-Mode oder SSL/TLS-Mode mit Zertifikaten sollten Sie allerdings für jeden Benutzer ein eigenes Zertifikat mit individuellem Common Name (CN) verwenden. Zwar können sich prinzipiell auch mehrere Benutzer ein Zertifikat teilen, jedoch muss dann nach Ausscheiden eines Teilnehmers das Zertifikat auch bei allen anderen Clients geändert werden. www.bomots.de
Betriebsmodi von OpenVPN 33 2.2.4 Routing oder Bridging? Mithilfe von OpenVPN können Netzwerke prinzipiell über zwei verschiedene Prinzipien Routing und Bridging miteinander verbunden werden. Beide Ansätze bieten spezifische Vor- und Nachteile, die wir nachfolgend etwas näher beleuchten werden. Generell lässt sich sagen, dass der Routing-Modus dem Bridging- Modus in den meisten Fällen vorzuziehen ist, da dieser eine bessere Skalierbarkeit gewährleistet. Je größer die Anzahl der Teilnehmer am VPN ist, desto besser ist das Routing-Prinzip geeignet. 2.2.4.1 Routing Routing wird generell eher in großen und sehr großen Netzwerken eingesetzt, da es eine hervorragende Skalierbarkeit bietet. Bestes Beispiel für die Skalierbarkeit gerouteter Netzwerke ist das Internet. Grundsätzlich werden in gerouteten Netzwerken nur jeweils die Daten an einen Teilnehmer übertragen, die auch für diesen bestimmt sind. Auf diese Weise können Daten in einem Netzwerk also sehr effizient übertragen werden. Im Gegensatz zum Bridging ist die Administration eines gerouteten Netzwerks allerdings aufwendiger, da für jedes Teilnetz (also für jeden Teilnehmer) Routen eingerichtet und allen Teilnehmern bekannt gemacht werden müssen. Bezogen auf OpenVPN bedeutet der Einsatz des Routing-Modes also zunächst einen höheren Aufwand bei der Einrichtung und im Betrieb des VPN. Dieser Nachteil wird aber durch eine sehr effiziente Ausnutzung der Netzwerkbandbreite und einer daraus resultierenden höheren Geschwindigkeit mehr als wettgemacht. Wenn Sie die Wahl haben, sollten Sie sich daher immer dafür entscheiden, OpenVPN im Routing-Mode zu betreiben. 2.2.4.2 Bridging Im Gegensatz zum Routing arbeitet Bridging auf der Sicherungsschicht des ISO/OSI-Modells (Layer 2) und verbindet auf diese Weise alle Teilnehmer im VPN in einem LAN. Befinden sich alle Teilnehmer in einem gemeinsamen LAN, müssen Sie sich also z. B. nicht um die manuelle Verteilung von Routeninformationen kümmern, da auch Broadcasts über den VPN-Tunnel übertragen werden. Der Betrieb eines OpenVPN im Bridging-Mode vereinfacht somit zum einen die Konfiguration, macht aber zum anderen die Verwendung von auf Broadcast basierenden Diensten überhaupt erst möglich.
34 OpenVPN die Open-Source-Alternative Möchten Sie beispielsweise im VPN über die Windows-Netzwerkumgebung Ihr Netzwerk erforschen (Network browsing), wird die Weiterleitung von Broadcasts zwingend benötigt, sodass keine Alternative zum Bridging-Mode existiert. Diese Vorteile erkauft sich der Administrator allerdings mit einer wesentlich schlechteren Netzwerkperformance, da alle Broadcasts von allen Teilnehmern wiederum an alle anderen Teilnehmer verteilt werden. Diese berüchtigten Broadcast-Stürme überlasten Netzwerke bereits nach kurzer Zeit, sodass insbesondere Teilnehmer mit geringer Bandbreite im VPN keine sinnvollen Datenübertragungsraten mehr erzielen. Für den Einsatz des Bridging-Modes stellt OpenVPN zwei Skripte zur Aktivierung und De-Aktivierung der Network-Bridge bereit. Details zum Bridging finden Sie im Kapitel 5, Einsatzszenarien von OpenVPN, im Abschnitt WLAN absichern. 2.2.5 TUN und TAP Routing wird generell eher in großen und sehr großen Netzwerken eingesetzt, da es eine hervorragende Skalierbarkeit bietet. Bestes Beispiel für die Skalierbarkeit gerouteter Netzwerke ist das Internet. Grundsätzlich werden in gerouteten Netzwerken nur jeweils die Daten an einen Teilnehmer übertragen, die auch für diesen bestimmt sind. Auf diese Weise können Daten in einem Netzwerk also sehr effizient übertragen werden. Im Gegensatz zum Bridging ist die Administration eines gerouteten Netzwerks allerdings aufwendiger, da für jedes Teilnetz (also für jeden Teilnehmer) Routen eingerichtet und allen Teilnehmern bekannt gemacht werden müssen. Bezogen auf OpenVPN bedeutet der Einsatz des Routing-Modes also zunächst einen höheren Aufwand bei der Einrichtung und im Betrieb des VPN. Dieser Nachteil wird aber durch eine sehr effiziente Ausnutzung der Netzwerkbandbreite und einer daraus resultierenden höheren Geschwindigkeit mehr als wettgemacht. Wenn Sie die Wahl haben, sollten Sie sich daher immer dafür entscheiden, OpenVPN im Routing-Mode zu betreiben. www.bomots.de
OpenVPN beschaffen 35 3 OpenVPN im Einsatz Genug der Vorrede. Schauen wir uns an, wie Sie in der Praxis mit OpenVPN arbeiten, wie Sie es installieren und konfigurieren. 3.1 OpenVPN beschaffen OpenVPN steht als Source-Code Paket für Unix-Betriebssysteme wie BSD, MacOS X, Solaris und Linux als TAR.GZ- bzw. ZIP-Archiv und für Windows- Betriebssysteme als Installerpaket (EXE-Datei) unter http://www.openvpn.net/index.php/downloads.html zum Download bereit. Selbstverständlich können Sie unter Linux aber auch die in den Paket-Repositories verwendeten OpenVPN- Versionen verwenden, die Sie bequem über den Paketmanager Ihrer Distribution installieren können. Unsere Konfigurationsbeispiele basieren allerdings auf den Release-Candidates 13 der OpenVPN Version 2.1. Sofern unter Ihrem Betriebssystem eine andere Version von OpenVPN installiert ist, kann es also zu Unterschieden kommen. Damit Sie auf Ihrem System die gleichen Voraussetzungen vorfinden, zeigen wir nachfolgend die Installation aus den entsprechenden Quellpaketen bzw. mithilfe des Windows- Installationspakets auf. Beim Einsatz von Sicherheitssoftware wie OpenVPN sollten Sie natürlich stets darauf achten, nur Pakete zu verwenden, deren Authentizität sich anhand einer Signatur überprüfen lässt. OpenVPN-Pakete sind mit einer GPG-Signaturdatei von James Yonan versehen. Laden Sie daher zusammen mit dem OpenVPN-Paket für Ihre Betriebssystem-Plattform auch gleich das passende GPG-Signatur-File mit herunter. Sie finden alle erforderlichen Downloads unter folgender URL: http://www.openvpn.net/index.php/downloads.html. 3.2 Signatur überprüfen Um die Authentizität der heruntergeladenen Softwarepakete zu überprüfen, benötigen Sie die Software GnuPG (GNU Privacy Guard) und den entsprechenden Public Key von James Yonan. GnuPG steht unter http://www.gnupg.de/download /mirrors.de.html ebenfalls für alle wichtigen Betriebssysteme zum kostenlosen Download bereit, James Yonans Public Key können Sie unter https://secure.openvpn.net/pubkey.txt herunterladen. Speichern Sie den Key zu-