Tunnelkonzept: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(Überblick über Tunnel-Techniken)
 
(Implementierungen: meinen Kommentar gelöscht, weil ich auch nicht mehr weiß warum es ihn gibt)
 
(20 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
== Überblick ==
 
== Überblick ==
Bis 2016 ([[Opennet Firmware Versionen|Firmware v0.5.2]]) werden im Opennet zwei Arten von Tunneln verwendet:
+
Bis 2016 (mind. [[Opennet Firmware/Versionen|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
 
* Nutzer-Tunnel für die verschlüsselte Verbindung eines Nutzer-APs mit einem Gateway-Server
* Mesh-Tunnel für die Routing/OLSR-Verbindung eines Spender-APs (UGW) mit einem oder mehreren Gateway-Servern
+
* 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.
 
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.
+
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 ==
 
== Anforderungen ==
  
 
{{hinweis|Die untenstehenden Anforderungen sind noch nicht diskutiert, sondern nur ein Entwurf.}}
 
{{hinweis|Die untenstehenden Anforderungen sind noch nicht diskutiert, sondern nur ein Entwurf.}}
 +
 +
Allgemeine Anforderungen:
 +
* Unterstützung in OpenWrt
 +
* stabile Entwicklungs-Community
  
 
{| {{prettytable}}
 
{| {{prettytable}}
! Eigenschaft
+
! Eigenschaft \ Tunnel
! Nutzer-Verbindung
+
! Nutzer-Tunnel (Nutzer-AP <-> UGW-Server)
! Mesh-Verbindung
+
! Mesh-Tunnel (UGW-AP <-> UGW-Server)
 
|-
 
|-
 
! NAT-Unterstützung
 
! NAT-Unterstützung
 
| nicht erforderlich
 
| nicht erforderlich
| IPv4: erforderlich <br> IPv6: unklar
+
| IPv4: erforderlich (Ist das wirklich so? Warum?)
 
|-
 
|-
 
! Performance / Bandbreite
 
! Performance / Bandbreite
Zeile 39: Zeile 47:
 
! Implementierung
 
! Implementierung
 
! NAT-Unterstützung
 
! NAT-Unterstützung
! Performance
+
! Performance [P1]
 +
! Performance [P2]
 
! Verschlüsselung
 
! Verschlüsselung
 
! Authentifikation
 
! Authentifikation
 
! OpenWRT-Paketierung
 
! OpenWRT-Paketierung
 
! Committer (letzte 12 Monate)
 
! Committer (letzte 12 Monate)
 +
! Single Interface on Server
 +
! Layer2/3
 
|-
 
|-
 
! [http://openvpn.net OpenVPN]
 
! [http://openvpn.net OpenVPN]
 
| ja
 
| ja
 
| ~10 MBit/s
 
| ~10 MBit/s
 +
| 28MBit/s
 
| ja
 
| ja
 
| X.509
 
| X.509
 
| ja
 
| ja
 
| >10
 
| >10
 +
| ja
 +
| beides
 
|-
 
|-
 
! [https://projects.universe-factory.net/projects/fastd/wiki fastd]
 
! [https://projects.universe-factory.net/projects/fastd/wiki fastd]
 
| ja
 
| ja
 
| ~20 MBit/s
 
| ~20 MBit/s
 +
| -
 
| ja
 
| ja
 
| ein Schlüssel je Client
 
| ein Schlüssel je Client
 
| ja
 
| ja
 
| 1
 
| 1
 +
|
 +
| L2
 
|-
 
|-
 
! [https://github.com/wlanslovenija/tunneldigger tunneldigger]
 
! [https://github.com/wlanslovenija/tunneldigger tunneldigger]
 
| ja
 
| ja
 
| ?
 
| ?
 +
| -
 
| nein
 
| nein
 
| nein
 
| nein
 
| inoffizielles Paket
 
| inoffizielles Paket
 
| ~3
 
| ~3
 +
|
 +
| ?
 
|-
 
|-
 
! [http://www.anytun.org/ µAnytun]
 
! [http://www.anytun.org/ µAnytun]
 
| ja
 
| ja
 
| ?
 
| ?
 +
| -
 
| ja
 
| ja
 
| ?
 
| ?
 
| ja
 
| ja
 
| 1
 
| 1
 +
| ?
 +
|?
 
|-
 
|-
 
! GRE / L2TP / IP in IP
 
! GRE / L2TP / IP in IP
 
| nein
 
| nein
 
| ~80 MBit/s
 
| ~80 MBit/s
 +
| 91MBit/s
 
| nein
 
| nein
 
| nein
 
| nein
 
| ja
 
| ja
 
| viele (Linux-Entwicklungsgemeinde)
 
| viele (Linux-Entwicklungsgemeinde)
 +
|
 +
| L2
 
|-
 
|-
 
! (GRE / L2TP / IP in IP) + IPsec
 
! (GRE / L2TP / IP in IP) + IPsec
 
| nein
 
| nein
 
| ?
 
| ?
 +
| -
 
| ja
 
| ja
| shared key, X.509, ...?
+
| shared key, X.509
 
| ja
 
| ja
 
| je nach Schlüsselverwaltung
 
| je nach Schlüsselverwaltung
 +
|
 +
| L3
 +
|-
 +
! [https://www.wireguard.io/ wireguard]
 +
| ?
 +
| ?
 +
| ?
 +
| ja
 +
| ein Schlüssel je Client
 +
| wird geplant (Juli 2016)
 +
| ?
 +
| ?
 +
| L3
 +
|-
 
|}
 
|}
 +
 +
[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 ==
 +
* https://wiki.openwrt.org/doc/howto/vpn.ipsec.performance
 +
* ...
 +
* (gabs nicht hier im Wiki auch iorgendwo Mesungen?)....
 +
 +
=== Installation/Konfiguration im Opennet ===
 +
Für die Installation/Konfiguration von IPSec und L2TP auf Debian Server + Openwrt folgende Anleitung lesen
 +
* [[Benutzer:Leo/IPSec_Test-Konfigurationsanleitung]]

Aktuelle Version vom 25. Februar 2018, 21:47 Uhr

Inhaltsverzeichnis

[Bearbeiten] Überblick

Bis 2016 (mind. 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.

[Bearbeiten] 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?

[Bearbeiten] 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 Layer2/3
OpenVPN ja ~10 MBit/s 28MBit/s ja X.509 ja >10 ja beides
fastd ja ~20 MBit/s - ja ein Schlüssel je Client ja 1 L2
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) L2
(GRE / L2TP / IP in IP) + IPsec nein  ? - ja shared key, X.509 ja je nach Schlüsselverwaltung L3
wireguard  ?  ?  ? ja ein Schlüssel je Client wird geplant (Juli 2016)  ?  ? L3

[P1] Erfahrungen mit Opennet Installationen

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

[Bearbeiten] 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.

[Bearbeiten] Performanceanalyse von Hardware

[Bearbeiten] 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