Tunnelkonzept: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(Überblick)
(Implementierungen: wireguard hinzugefügt)
Zeile 114: Zeile 114:
 
| je nach Schlüsselverwaltung
 
| je nach Schlüsselverwaltung
 
|
 
|
 +
|-
 +
! [https://www.wireguard.io/ wireguard]
 +
| ?
 +
| ?
 +
| ?
 +
| ja
 +
| ein Schlüssel je Client
 +
| wird geplant (Juli 2016)
 +
| ?
 +
| ?
 
|-
 
|-
 
|}
 
|}

Version vom 1. Juli 2016, 22:34 Uhr

Inhaltsverzeichnis

Überblick

Bis 2016 (Firmware v0.5.2) werden im Opennet zwei Arten von Tunneln verwendet (siehe auch Opennet FAQ#Im Opennet gibt es so viele Begriffe, was bedeuten diese? (Glossar)):

  • Nutzer-Tunnel für die verschlüsselte Verbindung eines Nutzer-APs mit einem Gateway-Server
  • Mesh/UGW-Tunnel für die Routing/OLSR-Verbindung eines Spender-APs (UGW-AP) mit einem oder mehreren Gateway-Servern (UGW-Server)

Beide Tunnel wurden bisher via OpenVPN aufgebaut.

Die Einführung von OLSRv2 und IPv6 stellt im Jahr 2016 eine gute Gelegenheit dar, diese Tunnel-Techniken zu überdenken und eventuell anzupassen.

Derzeit gibt es zwei Überlegungen:

  • das anscheinend "langsame" OpenVPN durch eine performantere VPN Technik zu ersetzen (User-Space / Kontextwechsel Problem)
  • aus den bisher verschlüsselten Mesh-Tunneln unverschlüsselte Tunnel zu machen. Die einzige Aufgabe dieser Tunnel wäre dann das Netzwerk virtuell über externe Netze zu spannen. Verschlüsseln muss dann jeder Knoten selbst, wenn er mit einem Endpunkt kommunizieren möchte.

Anforderungen


Allgemeine Anforderungen:

  • Unterstützung in OpenWrt
  • stabile Entwicklungs-Community
Eigenschaft \ Tunnel Nutzer-Tunnel (Nutzer-AP <-> UGW-Server) Mesh-Tunnel (UGW-AP <-> UGW-Server)
NAT-Unterstützung nicht erforderlich IPv4: erforderlich (Ist das wirklich so? Warum?)
Performance / Bandbreite ~20 MBit/s ~50 MBit/s
(Nutzer-Tunnel sollen über die Mesh-Verbindung fließen)
Verschlüsselung erforderlich nicht erforderlich
Authentifikation idealerweise via X.509 eventuell halb- oder vollautomatisch?

Implementierungen

Die Performance/Bandbreite-Werte stammen aus unterschiedlichen Quellen und sind kaum vergleichbar. Beispielsweise wird OpenVPN bei einer Messung von Justus Beyer mit 28 MBit/s bewertet, während unter Opennet-Bedingungen (Konfiguration, Anbindung) mit vergleichbarer Hardware nicht mehr als 10 MBit/s erreichbar sind.

Implementierung NAT-Unterstützung Performance [P1] Performance [P2] Verschlüsselung Authentifikation OpenWRT-Paketierung Committer (letzte 12 Monate) Single Interface on Server
OpenVPN ja ~10 MBit/swelches wir aber für Routing Protokoll brauchen 28MBit/s ja X.509 ja >10 ja
fastd ja ~20 MBit/s - ja ein Schlüssel je Client ja 1
tunneldigger ja  ? - nein nein inoffizielles Paket ~3
µAnytun ja  ? - ja  ? ja 1 ?
GRE / L2TP / IP in IP nein ~80 MBit/s 91MBit/s nein nein ja viele (Linux-Entwicklungsgemeinde)
(GRE / L2TP / IP in IP) + IPsec nein  ? - ja shared key, X.509 ja je nach Schlüsselverwaltung
wireguard  ?  ?  ? ja ein Schlüssel je Client wird geplant (Juli 2016)  ?  ?

[P1] Erfahrungen mit Opennet Installationen

[P2] https://justus.berlin/2016/02/performance-of-tunneling-methods-in-openwrt/

Anmerkungen

IPSec Probleme

  • Tunnel Mode: kann nicht genutzt werden, weil es keine zwei eindeutig trennbaren Netze auf beiden Seiten gibt
  • Transport Mode: unterstützt kein Multicast. Hier nur Point2Point Traffic. Denkbar wäre die Nutzung im GRE Tunnel. Dann würde nur der Point2Point Traffic verschlüsselt werden und der Multicast Traffic nicht.

Performanceanalyse von Hardware

Installation/Konfiguration im Opennet

Für die Installation/Konfiguration von IPSec und L2TP auf Debian Server + Openwrt folgende Anleitung lesen

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge