Tunnelkonzept: Unterschied zwischen den Versionen
Leo (Diskussion | Beiträge) (Mehr Prosa hinzugefügt) |
Leo (Diskussion | Beiträge) (→Implementierungen: meinen Kommentar gelöscht, weil ich auch nicht mehr weiß warum es ihn gibt) |
||
(13 dazwischenliegende Versionen von 2 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 (siehe auch [[Opennet FAQ#Im Opennet gibt es so viele Begriffe, was bedeuten diese? (Glossar)]]): | + | 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. | ||
Zeile 8: | Zeile 8: | ||
Derzeit gibt es zwei Überlegungen: | Derzeit gibt es zwei Überlegungen: | ||
− | * das anscheinend "langsame" OpenVPN durch eine performantere VPN Technik zu ersetzen | + | * 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. | * 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. | ||
Zeile 53: | Zeile 53: | ||
! 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] | ||
Zeile 62: | Zeile 64: | ||
| ja | | ja | ||
| >10 | | >10 | ||
+ | | ja | ||
+ | | beides | ||
|- | |- | ||
! [https://projects.universe-factory.net/projects/fastd/wiki fastd] | ! [https://projects.universe-factory.net/projects/fastd/wiki fastd] | ||
Zeile 71: | Zeile 75: | ||
| ja | | ja | ||
| 1 | | 1 | ||
+ | | | ||
+ | | L2 | ||
|- | |- | ||
! [https://github.com/wlanslovenija/tunneldigger tunneldigger] | ! [https://github.com/wlanslovenija/tunneldigger tunneldigger] | ||
Zeile 80: | Zeile 86: | ||
| inoffizielles Paket | | inoffizielles Paket | ||
| ~3 | | ~3 | ||
+ | | | ||
+ | | ? | ||
|- | |- | ||
! [http://www.anytun.org/ µAnytun] | ! [http://www.anytun.org/ µAnytun] | ||
Zeile 89: | Zeile 97: | ||
| ja | | ja | ||
| 1 | | 1 | ||
+ | | ? | ||
+ | |? | ||
|- | |- | ||
! GRE / L2TP / IP in IP | ! GRE / L2TP / IP in IP | ||
Zeile 98: | Zeile 108: | ||
| ja | | ja | ||
| viele (Linux-Entwicklungsgemeinde) | | viele (Linux-Entwicklungsgemeinde) | ||
+ | | | ||
+ | | L2 | ||
|- | |- | ||
! (GRE / L2TP / IP in IP) + IPsec | ! (GRE / L2TP / IP in IP) + IPsec | ||
Zeile 107: | Zeile 119: | ||
| 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 | ||
+ | |- | ||
|} | |} | ||
Zeile 112: | Zeile 138: | ||
[P2] https://justus.berlin/2016/02/performance-of-tunneling-methods-in-openwrt/ | [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, 22: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
Die untenstehenden Anforderungen sind noch nicht diskutiert, sondern nur ein Entwurf. |
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
- https://wiki.openwrt.org/doc/howto/vpn.ipsec.performance
- ...
- (gabs nicht hier im Wiki auch iorgendwo Mesungen?)....
[Bearbeiten] Installation/Konfiguration im Opennet
Für die Installation/Konfiguration von IPSec und L2TP auf Debian Server + Openwrt folgende Anleitung lesen