Open Source im professionellen Einsatz

Newsletter abonnieren
Seite durchsuchen

HEFTARCHIV | NEWS | E-BIBLIOTHEK | VIDEO | BLOGS | WHITEPAPER | EVENTS | ACADEMY | ABO | SHOP

user friendly

  Home  »  Heft & Abo  »  Heftarchiv  »  2003  »  10  »  Offener Tunnel  

RSS-Feed der aktuellen News von Linux-Magazin Online Folgen Sie Linux-Magazin Online auf Twitter
Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark

Virtuelle private Netze ohne Kernel-Modifikation: OpenVPN

Offener Tunnel

von Achim Leitner
Erschienen im Linux-Magazin 2003/10

Der einfach zu konfigurierende OpenVPN-Daemon nutzt das Tun-Device und arbeitet selbst im Userspace. Das UDP-Protokoll verwendet TLS-Verfahren zur Authentifizierung und kann damit als sehr sicher gelten.

Um IP-Pakete zu tunneln, braucht eine VPN-Software Zugang zum Kernel. Während Freeswan dazu als eigenes Kernelmodul realisiert ist, setzt OpenVPN[1] auf ein vorhandenes Modul (Tun/Tap) und arbeitet komplett im Userspace. Damit ist es sehr einfach in Betrieb zu nehmen. Seit 1.5-beta3 ist OpenVPN selbst für Windows verfügbar, bereits seit längerem unterstützt es neben Linux noch Mac OS X, Solaris, FreeBSD, NetBSD und OpenBSD.

OpenVPN ist zwar nicht zu IPsec kompatibel, dennoch verwendet es ein Standardprotokoll: TLS (Transport Layer Security[4]). Der Nachfolger von Netscapes SSL (Secure Sockets Layer), kommt bei der Authentifizierung mit X.509-Zertifikaten zum Einsatz.

Abbildung 1 verdeutlicht das VPN-Prinzip: Laptop und Server sind über ein beliebiges Netz verbunden und verwenden dort ihre reale IP-Adresse. Das VPN gibt Laptop und Server je eine zusätzliche, virtuelle IP-Adresse. Alle Daten, die über die virtuellen Adressen gesendet werden, verpackt OpenVPN in UDP-Pakete und sendet sie an die reale IP des Gegenübers. Der Empfänger packt die Daten aus und behandelt sie so, als wären sie über seine virtuelle Adresse hereingekommen. Es entsteht ein Tunnel zwischen Laptop und Server.

Grabungsarbeiten

Das folgende Beispiel geht davon aus, dass beide Rechner über »eth0« an das reale Netz angeschlossen sind - bei WLAN, ISDN, Modem oder DSL ist das entsprechende Interface einzusetzen. Neben dem hier dargestellten Client-to-Site-VPN kann OpenVPN auch ganze Standorte vernetzen, dazu ist lediglich das Routing anzupassen. Im Bridge-Modus verbindet es zwei Teile eines LAN sogar transparent. Im Idealfall nutzen beiden Tunnelendpunkte statische IPs. Für dynamische Adressen empfiehlt sich DynDNS[5], um jederzeit die aktuelle IP-Adresse des Gegenübers per festem DNS-Namen zu erhalten.

Als Client dient im Folgenden ein Laptop, der sich mit dem VPN-Server verbindet. Für erste Tests ist es sinnvoll, beiden OpenVPN-Rechnern einen gemeinsamen geheimen Schlüssel zu geben, das Shared Secret:

openvpn --genkey --secret Geheimer.Key

Den Inhalt von » Geheimer.Key« dürfen nur die beiden Rechner kennen, er darf auch nur für Root lesbar sein - wer den Schlüssel kennt, kann den Tunnel problemlos knacken.

Um den Tunnel zu graben, benötigt OpenVPN die IP-Adresse oder den DNS-Namen des Zielrechners, den Namen des Tunneldevice (per Default »tun0«) sowie die beiden virtuellen IP-Adressen für das VPN sowie die Schlüsseldatei. Auf dem Client sieht das so aus:

openvpn --dev tun0 
  --remote Reale_Server-IP 
  --ifconfig Virtuelle_Laptop-IP 
    Virtuelle_Server-IP 
  --secret Geheimer.Key

Wer die Optionen lieber in eine Konfigurationsdatei schreibt, muss dafür nur die führende Striche »--« entfernen, jede Option in eine Zeile setzen und OpenVPN anschließend mit den Parameter »--config Datei« aufrufen.

Passender Ausgang

Auf dem Server sind die IP-Adressen anzupassen:

openvpn --dev tun0 
  --remote Reale_Laptop-IP 
  --ifconfig Virtuelle_Server-IP 
    Virtuelle_Laptop-IP 
  --secret Geheimer.Key

Die virtuellen Tunneladressen sind fast beliebig, sie müssen aber private Adressen sein und aus einem anderen Block stammen als die realen Adressen, um das Routing einfach zu halten. Reales und virtuelles Netz sind dann leicht zu unterscheiden.

Ob der Tunnel steht, zeigt ein abschließender Ping-Test: Auf dem Laptop ermittelt »ping Virtuelle_Server-IP«, ob der Server durch den Tunnel erreichbar ist. Wenn alles klappt, kann OpenVPN auch als Daemon laufen, der »--daemon«-Parameter sorgt für diesen Wandel. Aber Vorsicht: Jetzt muss die Datei, die den geheimen Schlüssel enthält, mit ihrem absoluten Pfad angeben sein.

Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark
Ähnliche Artikel
Gestapelte Röhren Von WAP zu IP: OpenVPN tunnelt und schützt mobile
Keine Magie Open VPN mit Aladdins E-Tokens in großen Umgebungen
Einfache Verbindung VPN-Daemon im Userspace: Tinc
Schutz(be)dürftig Gravierende Fehler in VPN-Protokollen und deren Lösung
Streichholzschachtel Praxistest: Komplette Firewall inklusive Konfigurationssoftware auf USB-Stick
Kräftespiel Linux im Netzwerk: Was war. Was ist. Was wird.
Whitepaper
Usage Landscape Enterprise Open Source Data Integration

Die Nachfrage nach Datenintegrationslösungen für Unternehmen ist zunehmend gestiegen und vor allem das Interesse an Open Source Technologien wird immer größer. Doch wie und von wem werden Open Source Datenintegrationslösungen genutzt und welches Nutzungsverhalten lässt sich daraus ableiten? Das vorliegende White Paper präsentiert die Erfahrungswerte von über 1000 Open Source Nutzern und liefert fundierte Antworten auf diese Fragen.

Download PDF (Registrierung erforderlich)
Daten Migration - Eine Publikation von Bloor Research

Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.

Download PDF (Registrierung erforderlich)
Kommentare (0)