Funktionen

Unterstützung von IPv6 in OpenVPN

OpenVPN ist ein unter der GPL stehendes Projekt zum Aufbau von virtuellen, im allgemeinen verschlüsselten Netzverbindungen und wird wegen seiner geringen Grundkomplexität und Robustheit in vielen Situationen eingesetzt.

Generell unterstützt OpenVPN zwei Tunneltypen und zwei Betriebsmodi.

Bei Nutzung des tun-Tunneltyps bildet OpenVPN gegenüber dem Betriebssystem ein virtuelles Punkt-zu-Punkt Interface nach. Dieses kann nur IPv4 und (bei Unterstützung durch den tun-Treiber der Plattform) IPv6 transportieren. Hingegen emuliert der tap-Tunneltyp mit 802.3 Ethernet ein virtuelles broadcastf&aaum;higes Punkt-zu-Multipunkt-Interface, welches beliebige auf Ethernet nutzbare Protokolle unterstü:tzt. Im Point2Point-Modus (1:1) wird eine virtuelle L2-Verbindung zwischen genau zwei - im allgemeinen fest konfigurierten - Systemen aufgebaut. Die dabei entstehenden virtuellen Interfaces können wie eine physikalische Leitung benutzt und manuell konfiguriert werden, OpenVPN bietet allerdings auch Konfigurationsoptionen um IPv4-Adressen oder -Routen zu setzen.

Im Client/Server-Modus (1:n) entspricht OpenVPN mehr dem klassischen "Einwahl"-VPN für Mitarbeiter. In diesem Modus existiert auf Serverseite exakt ein Prozess und ein virtuelles Interface, auf das ein ganzer Adress-Block geroutet wird. Beim Verbindungsaufbau wird dem Client nach der Authentifizierung eine (je nach Konfiguration dynamische, semistatische oder statische) Adresse zugewiesen und diese, zusammen mit anderen Informationen wie z.B. Routingeinträgen, an den Client übertragen ("push"). Da mit dem bevorzugten tun-Tunneltyp gegen&uum;ber dem Betriebssystem nur ein einziges Punkt-zu-Punkt-Interface mit allen verbundenen Clients zur Verfü¼gung steht wird innerhalb des OpenVPN-Prozesses basierend auf einer internen Routingtabelle eine weitere Routingentscheidung getroffen.

Aufgabenstellung

OpenVPN bietet derzeit keinerlei aktive Unterstützung für IPv6. Im p2p-Modus ist eine Nutzung nur durch die vollständig manuelle Konfiguration von Adress- und Routinginformationen auf beiden Seiten möglich. Im Client/Server-Modus ist IPv6 prinzipiell bei Nutzung eines tap-Tunnels möglich, die Adresskonfiguration muss dabei allerdings an OpenVPN vorbei durch andere Mechanismen (RA, DHCPv6) erfolgen. Der Einsatz eines tap-Tunnels ist jedoch aufgrund von Sicherheitsbedenken und erhöhtem Overhead nicht empfohlen. Eine Nutzung von IPv6 im Client/Server-Modus mit einem tun-Tunnel ist aufgrund des fehlenden prozessinternen Routings im Moment nicht möglich.

Im Rahmen der Bachelorarbeit sollen folgende Aufgaben bearbeitet werden:

Kurzvorstellung und Einholung von Kommentaren und weiteren Anforderungen in der Anwender-/Entwicklergemeinschaft, insbesondere auf den entsprechenden Mailinglisten des Projekts (openvpn-users und openvpn-devel)

Kontaktaufnahme mit dem Hauptentwickler (James Yonan) zur Abklärung der bevorzugten Art der Zusammenarbeit. Ziel ist die Aufnahme des im Rahmen der Arbeit entstehenden Patches in das Entwicklungs-Repository.

Definition und Erweiterung der entsprechenden APIs und Protokolle zur Unterstützung der folgenden Konfigurationsoptionen:

• Zuweisung von statischen IPv6-Adressen (ifconfig)
• Konfiguration von statischen Routen (route)
• IPv6-Versionen alle relevanten Optionen des Client/Server-Modus, unter anderem
  • server / server-bridge
  • ifconfig / ifconfig-pool / ifconfig-pool-persist / ifconfig-push
  • iroute

Design und Implementierung eines internen Routings für den Client/Server-Modus mit tun-Tunneln

die entstehende OpenVPN-Version muss auf den üblichen Plattformen (Linux, BSD-Derivate, Windows) übersetzbar und ausführbar sein.

Evaluation von IPv6 mit tun-Tunneln unter Windows

IPv4-Interoperabilität mit nicht-IPv6-fähigen OpenVPN-Versionen, sowohl als Server als auch als Client, muss weiterhin gewährleistet sein.

Dokumentation der neuen und geänderten Parameter in den zugehörigen Manpages und Hilfetexten Eine lauffähige Version mit der Basisfunktionalität soll wenigstens vier Wochen vor Abgabe auf die Entwickler-Mailingliste gepostet und die danach entdeckten Fehler und Ungereimtheiten in Zusammenarbeit mit der Community behoben werden. Ziel ist die Bereitstellung eines Patches, der in Qualität und Funktionsumfang zur Aufnahme in den Entwicklungsbaum geeignet ist.

Aufgabensteller:
PD Dr. Helmut Reiser

Anforderungen:
Netze, Programmierung

Dauer des Fopras/SEPs: 3 Monate

Anzahl Bearbeiter: 1

Betreuer:
Bernhard Schmidt, LRZ, Tel. 35831-7885, bernhard.schmidt@lrz.de

---