Implementierung von Open-Source VPN-Systemen am Beispiel von OpenVPN
Aus Winfwiki
| Name des Autors: | Marius Sperling |
| Titel der Arbeit: | Implementierung von Open-Source VPN-Systemen am Beispiel von OpenVPN |
| Hochschule und Studienort: | FOM Essen |
Inhaltsverzeichnis |
1 Einleitung
Diese Arbeit soll einen Überblick über die Implementation von OpenVPN geben. VPNs nehmen in der heutigen Zeit immer mehr an Bedeutung zu. Die Verwendung von VPNs stieg in den letzten Jahren rapide. Abbildung 1[1] zeigt einen Graphen der die rasante Entwicklung von 1998 bis 2003 deutlich macht.
Es ist möglich auch andere Technologien zu verwenden die allerdings wesentlich teurer sind. Dies ist einer der wesentlichsten Gründe wieso das VPN so gut angenommen wurde. Die Variante des VPNs ist einfach deutlich kostengünstiger, ob es kommerzielle oder OpenSource Produkte sind[2]. Durch die starke Nachfrage von VPN Lösungen, wurden auch im OpenSource Bereich verschiedene VPN-Softwarelösungen entwickelt.
Um einen Einblick in die Möglichkeiten von OpenVPN zu geben werden in dieser Arbeit die wichtigsten Punkte erläutert.
2 Grundlagen
In diesem Kapitel wird kurz erklärt was ein VPN ist und zu welchem Zweck es entwickelt wurde. Desweiteren werden OpenSource Produkte gegenüber kommerzieller Software abgegrenzt.
2.1 Was ist ein VPN?
Ein VPN wurde entwickelt um Verbindungen auf einem sicheren Wege von geografisch getrennten Standorten herzustellen. Ein Unternehmen hat mehrere Möglichkeiten dies zu realisieren.
Die Eine ist, man mietet sich eine dedizierte Leitung - eine sogenannte Leased-Line - auf der nur die Daten des eigenen Unternehmens übertragen werden, so hat Niemand anders darauf Zugriff. Weitere Technologien sind Frame-Relay und ATM die hier nicht weiter erläutert werden. Die Günstigste Möglichkeit ist ein VPN. Die Daten werden verschlüsselt und sind nur für die Beteiligten lesbar. So können öffentliche Netze für die Übertragung von Unternehmensdaten genutzt werden, ohne einer großen Gefahr des Ausspionierens ausgeliefert zu sein. Man spricht bei der Verschlüsselung von Daten zwischen zwei geografisch getrennten Standorten zur plastischen Vorstellung auch von einem Tunnel der durch das öffentlich Internet verläuft[3].
2.2 VPN Software
Die Software die für ein VPN verwendet wird, muss hohe Anforderungen erfüllen, damit die Daten geschützt vor Angriffen sind. Diese Anforderungen versuchen kommerzielle sowie auch OpenSource Produkte zu erfüllen. Diese beiden Sparten werden in diesem Kapitel gegenüber gestellt.
2.2.1 Open Source
Open Source beschreibt Produkte, deren Quelltexte öffentlich zugänglich sind und somit auch kostenlos zur Verfügung stehen. Im VPN Bereich ist das populärste das OpenVPN. Durch die Vielzahl an Entwicklern, die an diesem Produkt programmieren besteht ein hohes Potenzial in solchen Programmen. So ist die verwendete Verschlüsselung OpenSSL auf dem modernsten Stand und kann mit kommerziellen Konkurrenten mithalten.
Der Nachteil ist der, dass sich große Unternehmen auf die schnelle Behebung von Fehlern in der Software verlassen können müssen. Dies ist bei OpenSource Produkten nicht gegeben.
2.2.2 Kommerziell
In großen Unternehmen werden daher in der Regel kommerzielle Produkte implementiert. Es können Verträge ausgehandelt werden, die z.B. besagen dass das Produkt 99,9% des Jahres laufen wird.
Kommerzielle Systeme sind unteranderem relativ teuer, da eine VPN-Lösung immer an neue technische Gegebenheiten angepasst und auf wachsende Kapazitäten vorbereitet werden muss. Daher ist eine gute Alternative das OpenVPN, welches ebenfalls von vielen freien Entwicklern immer weiterentwickelt wird. Dass kommerzielle Systeme in der Regel ein grafisches Management System haben, welches sehr übersichtlich und einfach zu handhaben ist. Eine der populärsten Anbieter sind Cisco, Juniper und Citrix[4].
3 Implementierung
In diesem Kapitel werden die verschiedenen VPN Architekturen vorgestellt, die Features von OpenVPN und die Authentifizierungstypen. Es soll ein Überblick gegeben werden, was für eine erfolgreiche Implementierung erforderlich ist und welche die wichtigsten Aspekte für die Implementierung sind. Welche Features vom Aufwand der Einrichtung und vom Nutzen den Anforderungen entsprechen. Außerdem soll gezeigt werden, dass auch ein OpenSource Produkt viele verschiedene Möglichkeiten hat ein VPN zu realisieren.
3.1 Architekturen
Vorerst werden die grundlegenden Architekturen erläutert, die in einer OpenVPN Lösung möglich sind. Im Rahmen von OpenVPN gibt es 2 verschiedene Typen einer VPN Architektur. Die Unterschiede werden hier aufgezeigt und erklärt[5].
3.1.1 End-to-Site
Die Netzwerkarchitektur End-to-Site ist eine sehr verbreitete Methode ein VPN zu betreiben. Der Benutzer bzw. Mitarbeiter eines Unternehmens kann sich über das Internet in das Unternehmensnetz einwählen. Das heißt der Client benötigt lediglich eine Internetverbindung und kann so völlig unabhängig vom Ort an seinem Notebook arbeiten als säße er in seinem Büro.
Um dies zu ermöglichen benötigt man am Standort des Netzes ein VPN-Gateway[4] und der Client eine Software auf seinem Notebook[6]. Den grundlegenden Aufbau macht Abbildung 2[7] deutlich.
Der Server besteht aus einer Hardware und einer Software, in diesem Falle OpenVPN. Das Notebook kann dann eine Verbindung initiieren, die auch Tunnel genannt wird. Über diesen Tunnel werden die Daten mit einer entsprechenden Verschlüsselung übertragen. Die Verbindung besteht immer nur solange bis sie vom Client beendet wird.
Für Mitarbeiter die oft unterwegs sind und die Möglichkeit haben sich ins Internet einzuwählen, ist das eine gute Variante unabhängig vom Ort voll Handlungsfähig zu sein. Mittels einer UMTS Verbindung ins Internet hätte der Benutzer sogar eine permanente Verbindung zum Unternehmensnetz. Vielbeschäftigte Mitarbeiter nutzen diese Technologie auch gerne um Abends oder am Wochenende Zuhause noch die letzten Mails o.Ä. zu schreiben[4].
3.1.2 Site-to-Site
Um geografisch getrennte Standorte zu verbinden wird eine Site-to-Site Architektur implementiert. Das bedeutet, dass an jedem Standort ein VPN-Gateway installiert wird wie es in Abbildung 3[8] zu sehen ist. Frühere Technologien mit denen eine solche Verbindung möglich waren, sind Frame Relay oder ATM, die wegen ihrem hohen Preis durch das VPN vom Markt verdrängt wurden. Besonders bei weitentfernten Standorten waren die Kosten sehr hoch. Die Kosten für eine VPN-Verbindung ist nicht von der Entfernung der Standorte abhängig. Der Tunnel einer Site-to-Site Architektur ist permanent hergestellt anders als beim End-to-Site, wo die Verbindung immer wieder getrennt und wieder neu aufgebaut wird.
Diese Architektur wird mittlerweile fast in jedem Unternehmen eingesetzt um kostensparend Standorte zu vernetzen. Es werden kaum noch zusätzliche Standorte eröffnet die nicht per VPN verbunden sind. Mittels VPN können bspw. zentrale Server zur Datenspeicherung verwendet werden. Große Datenmengen können ohne erheblichen Aufwand von einem Ort zum anderen übertragen werden. Die Übertragungsgeschwindigkeit hängt von der Leistungsfähigkeit der Internetanbindung ab[9].
3.2 Features
Nun werden verschiedenste Features von OpenVPN aufgezeigt. Es wird das Managementinterface vorgestellt, die verwendete Verschlüsselungstechnik, Möglichkeiten zur Steigerung der Ausfallsicherheit und Lastverteilung. Es soll zeigen, dass sich auch mit einem OpenSource Produkt mächtige Features implementieren lassen.
3.2.1 Management
Im Management eines VPN gibt es zwei grundlegende Kategorien. Zum Einen der Ist-Zustand und zum Anderen die historischen Daten. Der Ist-Zustand zeigt die aktuelle Auslastung des Systems und bspw. die zu derzeit eingerichteten Benutzer. Der Ist-Zustand kann über ein Managementinterface abgerufen werden. Die historischen Daten zeigen die vergangenen Systemstati und können mittels logging aufgezeichnet werden.
Über das Managementinterface lassen sich Informationen abrufen oder z.B. auch einzelne Verbindungen löschen. Folgend einige interessanten Kommandos im Interface, die die Art und Weise des Managements zeigen sollen.
Mit der Eingabe des Befehls "log" wird das logging ein oder ausgestellt und verschiedene Einstellungen bezüglich des Inhalts der Logs können noch hinzugefügt werden.
Mit dem Kommando "status" lässt sich die OpenVPN Client List, die Routing Table und die Global Stats ausgeben. Hier ein Beispiel:
status 1 OpenVPN CLIENT LIST Updated, Wed Mar 15 22:27:10 2006 Common Name, Real Address, Bytes Recieved, Bytes Sent, Connected Since VPN_Client_host_gelb,1.1.1.1:2048,7473,7981,Wed Mar 15 22:18:45 2006 VPN_Client_host_gruen,2.2.2.2:2048,7437,8180,Wed Mar 15 22:17:45 2006 ROUTING TABLE Virtual Address, Common Name, Real Address, Last Ref 172.16.30.6, VPN_Client_host_gruen,2.2.2.2:2048,Wed Mar 15 22:17:46 2006 172.16.30.10, VPN_Client_host_gelb,1.1.1.1:2048,Wed Mar 15 22:18:46 2006 GLOBAL STATS Max bcast/mcast queue length,0 END
Das beenden eines Tunnels lässt sich mit dem Befehl "kill" realisieren. Angenommen man möchte den Tunnel des Clients VPN_Client_host_gruen disconnecten, sieht das wie folgt aus:
kill VPN_Client_host_gruen SUCCESS: common name 'VPN_Client_host_gruen' found, 1 client(s) killed
In dieser Form werden alle Kommandos eingegeben und bearbeitet. Bisher gibt es nur für die Clients von OpenVPN eine grafische Oberfläche. Doch da es sich um ein OpenSource Produkt handelt, können sich Entwickler dafür einsetzen eine solche Oberfläche zu entwickeln und diese mit OpenVPN zu verbinden[10].
Bei kommerziellen Systemen gibt es in der Regel immer eine Weboberfläche oder auch eine Applikation auf der man bspw. übersichtlich Client Lists anzeigen lassen kann, einen Graphen der die Dauer der Verbindungen anzeigt o.Ä.
3.2.2 OpenSSL
Die Library von OpenSSL wird von OpenVPN zur Verschlüsselung von Daten benutzt. OpenSSL ist ein sehr robustes und mächtiges Programm geworden.
Die Entwickler von OpenSSL - welches übrigens auch OpenSource ist - haben viel Wert auf die Sicherheitsaspekte gelegt. Innerhalb von 3 Jahren wurden 15 Sicherheitslücken bekannt lediglich 4 davon wurden als definitives Sicherheitsproblem eingestuft und 3 davon lassen sich nur in bestimmten Laborumgebungen replizieren. Diese sind also eher Theorie. Die Sicherheitslücke die sich auch im praktischen Betrieb umsetzen ließ wurde Juli 2002 behoben. Außerdem werden die wichtigsten Standards wie SSLv2/v3 und TLSv1 unterstützt [11].
Das macht deutlich, dass OpenSSL mit den modernsten Verschlüsselungstechniken mithalten kann. Der Sicherheitsaspekt wird also keinesfalls vernachlässigt nur weil man sich nicht für ein kommerzielles System entschieden hat.
3.2.3 Failover
Für große Unternehmen ist die Ausfallsicherheit von großer Bedeutung. Daher bietet es sich an ein Failover zu implementieren. Unter einem Failover versteht man einen ungeplanten Wechsel von einem Primärserver zu einem Sekundären. Fällt also der Primärserver aus wird direkt der Sekundäre benutzt. So kann eine sehr hohe Ausfallsicherheit gewährleistet werden ohne großen Aufwand.
OpenVPN hat ein solches Feature nicht direkt integriert, doch es lässt sich durch eine floating static route realisieren. Ein dynamisches Routingprotokoll schwenkt hier bei Ausfall des Servers automatisch auf die 2. Route des Sekundärservers. So kann eine solche Ausfallsicherheit auch mit OpenVPN implementiert werden[12]. Die zusätzlichen Kosten belaufen sich darauf, dass ein weiterer Server angeschafft werden muss der den Anforderungen der floating static route gerecht wird.
Auf Abbildung 4 ist der Server, der das Routing übernimmt mit client benannt (etwas verwirrend weil dieser eignelitch ein Server ist), der grüne master ist die momentan aktive Komponente. Fällt der master aus wird auf den Rechner slave umgeroutet. Schwenkt der client bei einem Ausfall schnell genug automatisch auf die zweite Route, bekommt der Benutzer im besten Fall nichts von dem Ausfall mit[13].
Sinnvoll ist es ein Failover zu implementieren wenn sehr kritische Vorgänge über die VPN Verbindungen abgewickelt werden oder Kunden auf eine hohe Verfügbarkeit bestehen.
3.2.4 Load-Balancing
Umso größer die Anzahl der VPN Benutzer ist, umso mehr Performance benötigt der Server der die Tunnel verarbeitet. Diese Verarbeitung ist deswegen so rechenintensiv, weil alle Daten verschlüsselt und entschlüsselt werden müssen.
Es bietet sich an Load-Balancing zu betreiben. Auch hier wird ein weiterer Server benötigt. Die Idee ist, dass die Anfragen auf zwei Server aufgeteilt werden. Durch das implementieren von IPtables sorgt eine einfache Regel dafür, dass die Anfragen abwechselnd auf die Server verteilt werden. Dieses System lässt sich gut mit einem Failover vereinen, da bereits zwei VPN-Server vorhanden sind. Fällt dann ein Server aus, werden wieder alle Anfragen auf Einen gesendet. Die Verarbeitung der IPtables ist bspw. auf dem OpenSource Linux mit dem Plugin Pound möglich. Dies lässt sich mit dem Failover Server vereinen. Dadurch entstehen keine weiteren Kosten, solange man bereits ein Failover System in Betrieb hat.
Ist dies gegeben ist es durch ein paar Arbeitsstunden getan das Load-Balancing zu implementieren. Es wird allerdings wirklich erst benötigt wenn es eine hohe Anzahl von VPN-Benutzern gibt und der Server bald an seine Grenzen kommen würde[14].
Abbildung 5[15] zeigt den Aufbau eines Load-Balancing Systems. Der Load-Balancer teilt die Anfragen, wie bereits angesprochen, auf die beiden Server auf.
3.3 Authentifikation
Die Konzeption des VPN ist es Daten von zwei unabhängigen Orten sicher über öffentliche Medien zu übertragen. Ohne Verschlüsselung der Daten und Authentifikation der einzelnen Benutzer bzw. Standorte wäre dies nicht möglich. Plastisch kann man sich eine verschlüsselte Übertragung vorstellen, als würden die Daten hinter einer verrauchten nicht durchsichtigen Scheibe vor dem Rest der Welt versteckt.
Verschlüsselte Daten können von Niemanden gelesen werden außer die Empfänger, die die entsprechenden Mittel haben die Daten zu entschlüsseln. Die Daten die mittels Verschlüsselungsalgorithmus verschlüsselt werden nennt man clear text, die verschlüsselten Dateien nennt man ciphertext oder crypt text. Die Daten werden durch mathematische Algorithmen manipuliert. Diesen Prozess rückgängig zu machen ohne die entsprechenden Mittel zur Entschlüsselung zu kennen ist sehr komplex, zeitaufwändig und teuer, aber es ist machbar[16].
In diesem Kapitel werden die möglichen Authentifikationsmöglichkeiten aufgezeigt. Vom einfachen Preshared Key bis zum RADUIS-Server.
3.3.1 Preshared Key
Die Variante des Preshared Key berechtigt jeden zur Verwendung eines Tunnels die diesen Key kennen. Der Schlüssel wird mit einer Kommandozeile mit Hilfe von OpenVPN erstellt. Diese lautet unter Linux wie folgt:
/usr/local/sbin/openvpn --genkey --secret mykey.txt
Diese Datei enthält nun einen 2048bit großen Schlüssel. Um zu verdeutlichen dass es sich hier nicht um ein herkömmliches Kennwort handelt hier ein Beispiel eines Keys (dieser muss nicht von Hand eingegeben werden):
-----BEGIN OpenVPN static key----- 1a8f56301cd7377898f2e08399eeb14d bc14af2aedebbde8c3849f564b349b8c 2b45b5ab89ad10ec6ce96dcfc31b096e 57c231aae2164dd12ec08ec80d8a9f0b 0397c5a3060918f7a0e43b45702b42eb c8908e22b5ab57604fee63da61799cc7 0e2a1c9f76738d05782a94a691328ddb a72c2dcd68fb7fe60cf4739b49191770 7ba489579f3d8b52db15dd79a2eccd60 67e8dea9a6349d8a5a135c341fbed822 32a5b0f33b7bb664f5d64b6a04077a40 e71cc183ccf8e7b6df08a72ea5ff7c00 b8354a9c2f9511b722c90cd2b8a75234 8d3778eabc83dfa8a3b320743f646cb3 eb315a33b053c69c174a4654a3168500 0f3cc6b7ca9c01594a3e5f2d7f0d451c -----END OpenVPN Static key V1-----
Der Vorteil einer Preshared-Key Implementierung ist, dass sich diese sehr einfach realisieren lässt und insbesondere für Testzwecke eignet. Im Realbetrieb besteht die Gefahr dass der Schlüssel einem Angreifer bekannt wird. Ist er in Besitz dieses Schlüssels kann er ohne Probleme die Daten entschlüsseln und einsehen. Auch das Lesen der Daten in Zukunft ist so möglich. Um dieses Risiko zu reduzieren, sollte regelmäßig der Schlüssel geändert und ausgetauscht werden, was bei dieser Methode manuell passieren muss[17]. In der Regel kann man diese Methode verwenden wenn keine kritischen Daten übertragen werden oder man benutzt sie für Tests in Laborumgebungen.
3.3.2 Certificate Authority
Die Certificate Authority ist für die Ausstellung, Verteilung, Erneuerung und Sperrung digitaler Zertifikate verantwortlich und ist eine bereits viel sicherere Methode als der Preshared Key. Die Identität einer Person muss bei Ausgabe eines Zertifikats vorerst sorgfältig geprüft werden, um kein Risiko einzugehen, dass sich Angreifer auf diese einfache Art und Weise Zugang in das Netz verschaffen[18]. Die Stärke der Authentifizierung hängt weniger von dem Verfahren ab, sondern davon wie sehr man auf die Vergabe von Zertifikaten acht gibt[19].
Doch wie sieht ein digitales Zertifikat denn nun aus? In einem Zertifikat sind Angaben wie Name, Schlüssel, verwendete Algorithmus und der Gültigkeitsbereich sowohl zeitlich als auch bezüglich des Berechtigungsbereiches.
Die Struktur der Zertifikate ist von der ITU standardisiert. Der detailierte Inhalt eines digitalen Zertifikats nach ITU-X.509 sehen Sie in Abbildung 6[20].
Für eine erfolgreiche Verbindung zwischen Server und Client sind folgende Dateien erforderlich:
- OpenVPN-Server benötigt
- Server Schlüssel
- dazugehörige Zertifikat
- und passende Zertifikat vom Client
- OpenVPN-Client benötigt
- Clientschlüssel
- dazugehörige Zertifikat
- Zertifikat von der CA
Es ist immer empfehlenswert den Clientschlüssel zusätzlich mit einem Passwort zu schützen[21].
3.3.3 RADIUS-Server
RADIUS (= Remote Authentication Dial In User Service) erzeugt eine einzelne zentrale Datenbank mit allen Userinformationen. Diese Technik ist dann sinnvoll zu implementieren wenn mehrere VPN-Server im Unternehmen existieren. Alle VPN-Server greifen so auf den RADIUS-Server zu und die Authentifizierung der User wird dann zentral vom RADIUS-Server übernommen. Egal auf welchen VPN-Server der User nun zugreift er wird niemals unterschiedliche Rechte o.Ä. haben, da die Authentifizierung nur an einer Stelle im Netz stattfindet[22].
Um RADIUS mit OpenVPN zu verwenden wird ein OpenVPN-Plugin verwendet namens openvpn-auth-pam. PAM steht für Pluggable Athentication Module, dieses erlaubt es unter Linux durch verschiedene Dienste einen RADIUS-Server zu verwenden. Für die Verwendung eines RADIUS-Dienstes gibt es viele verschiedene Softwarepakete, kommerziell und OpenSource.
User werden z.B. unter dem RADIUS-Dienst von Debian Linux folgendermaßen angelegt:
user_gelb NAS-IP-Address =="172.16.1.254", Auth-Type := Local, User-Password == "pass-gelb"
Dieser Eintrag bewirkt, dass folgende Bedingungen erfüllt werden müssen: der Benutzer user_gelb kommt von Server 172.16.1.254 und hat das korrekte Passwort eingegeben. Auf folgender Abbildung[23] ist zu sehen wie sich die Verbindung mit einem RADIUS-Server aufbaut.
Auf dem VPN-Server ist es notwendig in dem RADIUS-Plugin von OpenVPN den RADIUS-Server einzutragen. Auf beiden Seiten muss ein sogenanntes shared secret Passwort eingetragen werden, welches zur Verschlüsselung zwischen den beiden Servern dient.
Nicht zu vergessen ist, dass auch bei Einsatz eines RADIUS-Servers Zertifikate benutzt werden können. Es ist hier so, dass die Authentifizierung per Zertifikat bis zum VPN-Server vordringt alles weitere mit Username und Kennwort läuft dann zwischen VPN-Server und RADIUS-Server ab[24].
Wenn mehrere VPN-Server vorhanden sind hat ein RADIUS-Server auch den Vorteil, dass sich das Einrichten von Usern ein einziges Mal beschränkt. Es können keine unterschiedlichen Eingaben entstehen, und somit wie bereits erwähnt keine unterschiedlichen Berechtigungen.
4 Praxisnahes Fallbeispiel
Für eine praxisnahe Darstellung eines VPN Netzwerkes, wird nun nochmal ein Fallbeispiel gegeben, welches die Komponenten und den grundsätzlichen Aufbau des Netzwerkes zeigt.
4.1 Aufbau des Netzwerkes
Als typische Verbindung von VPNs wird in diesem Fallbeispiel, eine Vernetzung von 3 Standorten gewählt. Die Vernetzung durch einen Tunnel ist weitaus preiswerter als eine Verbindung durch eine Leased-Line.
Durch entsprechende Routingprotokolle kann für ein hohes Maß an Verfügbarkeit bei Nutzung mehrerer Tunnel zu unterschiedlichen Standorten realisiert werden. Ein typisches Beispiel wäre der redundante Aufbau einer Verbindung zwischen der Zentrale und einigen Zweigstellen.
Auf Abbildung 8[25] wird deutlicher wie ein solches Netzwerk aufgebaut ist. Es sind 3 Standorte vorhanden, die Zentrale, Standort X und Standort Y. Standort X und Y sind per VPN-Tunnel mit der Zentrale verbunden. An jedem Standort muss mindestens ein VPN-Server vorhanden sein. Der Grund für die zwei Server in der Zentrale wird gleich klar. Die Firewall direkt rechts an der Wolke sichert das Netz vor ungewollten Zugriffen und sperrt dafür verschiedene Ports, die Firewall hinter den VPN-Servern ist für das verhindern von internen Angriffen implementiert.
Nun zu den Funktionen dieses Netzes. Durch ein entsprechendes dynamischen Routingprotokoll ist es egal, ob sich die Standorte mit VPN-Server A oder B verbinden, der Tunnel wird in jedem Fall aufgebaut. VPN-Server A und B sind mit Failover implementiert, um Ausfallsicherheit zu gewährleisten. Zusätzlich ist ein Load-Balancing integriert, um die Server möglichst gleichmäßig zu belasten. Bei 2 Standorten würde jeder der beiden Server für einen Standort den Tunnel verarbeiten.
Desweiteren ist stark anzunehmen, dass sich Mitarbeiter mit einer End-to-Site Verbindung in das Firmennetz einwählen wollen. Auch dies ist ohne Probleme möglich. Die User würden dann via Internet - welches in der Abbildung 8 als Wolke dargestellt ist -auf einen der VPN-Server zugreifen und einen Aufbau eines Tunnels initiieren. Je mehr Standorte oder User vorhanden sind, je mehr macht auch das Load-Balancing Sinn.
Auf die Arten der Authentifizierungen wird hier nicht mehr eingegangen. Empfehlenswert ist aber immer die sicherste Methode, und zwar die der Zertifikate mit zusätzlichem Passwort[26].
4.2 häufige Probleme
Angenommen ein End-to-Site User ist in einem fremden Unternehmen und bekommt einen Internet Zugang mit verschiedenen "Barrieren" zur Verfügung gestellt. Praktische Beispiele sind die Umsetzung der Adresse (NAT) oder die Benutzung eines speziellen Proxys beim Internetzugang.
OpenVPN hat mit NAT keine Probleme, da ein Protokoll verwandt wird, welches die Verbindung über ein NAT-Gateway ohne Probleme aufbaut.
Der Standardport der für OpenVPN verwandt wird, ist 1194. Dieser ist in der Regel auf Firewall-Systemen gesperrt. Das bedeutet, dass das fremde Unternehmen diesen Port erst in ihrer Firewall öffnen müsste. OpenVPN hat aber auch die Möglichkeit die Tunnel über jeden beliebigen Port zu übertragen. Auch Port 80 und 443, die generell für das Surfen benutzt werden und in zahlreichen Netzen gestattet sind, können benutzt werden.
Wird zusätzlich ein Proxy verwendet sollte dies über Port 443 geschehen und nicht über Port 80, da dieser unverschlüsselten Verkehr mit HTML-Elementen erwartet. Der Proxy wird nun in die Proxykonfiguration eingetragen. Nun kann der Tunnel aufgebaut werden.
Wie man sieht ist OpenVPN sehr flexibel und kann verschiedene Barrieren leicht bewältigen[27].
5 Fazit
Zum Schluss ist festzuhalten, dass OpenVPN eine VPN-Lösung ist, die sehr kostengünstig ist und trotzdem viel leistet. Ein grafisches Management ist bisher allerdings noch nicht vorzuweisen, welches die Einrichtung und Konfiguration deutlich erleichtern würde. Soll so etwas verfügbar sein sollte sich für ein Plugin für OpenVPN einsetzen oder sich für ein kommerzielles System entscheiden. Die Möglichkeiten die sich mit einem OpenSource Projekt auftuen sind grenzenlos. Jeder kann beliebig Plugins Programmieren um OpenVPN zu verbessern. Da die Software kostenlos ist besteht allerdings keine Garantie oder ein Vertrag zur Wartung, es sei denn man beschafft sich diese von Dritten.
6 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|---|---|
| ATM | Asynchronous Transfer Mode |
| HTML | Hypertext Markup Language |
| ITU | International Telecommunication Union |
| NAT | Network Address Translation |
| PAM | Pluggable Athentication Module |
| RADIUS | Remote Authentication Dial-In User Service |
| SSL | Secure Sockets Layer |
| TLS | Transport Layer Security |
| UMTS | Universal Mobile Telecommunications System |
| VPN | Virtual Private Network |
7 Abbildungsverzeichnis
| Abb.-Nr. | Abbildung |
|---|---|
| 1 | Entwicklung der Anzahl verwendeter VPN-Systeme von 1998-2003 |
| 2 | Struktur einer End-to-Site Verbindung |
| 3 | Struktur einer Site-to-Site Verbindung |
| 4 | Aufbau eines Failover |
| 5 | Aufbau eines Load-Balancing |
| 6 | Inhalt eines ITU X.509 standardisierten Zerfifikats Version 1 - 3 |
| 7 | Vernetzung einer VPN-Lösung mit RADIUS-Server |
| 8 | VPN-Anbundung zweier Standorte an eine Zentrale |
8 Fußnoten
- ↑ VPN - Virtuelle Private Netze S.26
- ↑ VPN - Virtuelle Private Netze S.24
- ↑ Building and Managing Virtual Private Networks S23f
- ↑ 4,0 4,1 4,2 VPN - Virtuelle Private Netze S.38f
- ↑ OpenVPN S.11
- ↑ OpenVPN S.93
- ↑ OpenVPN S.11
- ↑ OpenVPN S.12
- ↑ VPN - Virtuelle Private Netze S.41f
- ↑ OpenVPN S.146
- ↑ OpenVPN S.39
- ↑ OpenVPN and the SSL VPN Revolution, S.18
- ↑ Projekte Cluster
- ↑ OpenVPN and the SSL VPN Revolution, S.17
- ↑ Load-Balancing Pound
- ↑ Virtual Private Networks, S22f
- ↑ OpenVPN S.131f
- ↑ VPN - Virtuelle Private Netze, S.164
- ↑ VPN - Virtuelle Private Netze S.150
- ↑ VPN - Virtuelle Private Netze S.153f
- ↑ OpenVPN S.93
- ↑ Building and Managing Virtual Private Networks S.131
- ↑ OpenVPN S.135
- ↑ OpenVPN S.135-139
- ↑ OpenVPN S.182
- ↑ OpenVPN S.181f
- ↑ OpenVPN S.189f
9 Literaturverzeichnis
| Bauer, Johannes (2006) | Bauer, Liebscher, Thielking-Riechert: OpenVPN, 1. Auflage, dpunkt.verlag, Heidelberg |
| Hosner, Chalie (2004) | Hosner: OpenVPN and the SSL VPN Revolution, http://www.sans.org/reading_room/whitepapers/vpns/openvpn_and_the_ssl_vpn_revolution_1459?show=1459.php&cat=vpns, SANS Institute |
| Kosiur, Dave (1998) | Kosiur, Dave: Building and Managing Virtual Private Networks, 1. Auflage, Wiley, New York |
| Kruppa (2005) | Kruppa: Projekte Cluster, http://npftp.elektronik.htw-aalen.de/index.php?nav=projekte_cluster&main=cluster/kr04/kr04.html, Hochschule Aalen |
| Kunwar, Niranjan (2007) | Kunwar: Load-Balancing Pound, http://nirlog.com/2007/11/28/load-balancing-web-servers-with-pound/#more-271, NIRLOG |
| Lipp, Manfred (2001) | Lipp, Manfred: VPN - Virtuelle Private Netze, 1. Auflage, Addison-Wesley, München |
| Scott, Charley (1999) | Scott, Wolfe, Erwin: Virtual Private Networks, 2. Auflage, O'Reilly, Sebastopol |
