Version vom 21. April 2023, 23:48 Uhr

WireGuard Tunnel für Nodes
Starttermin	05 Jan. 21
Status	Proof of Concept

Projekt

TODO: WireGuard-Tunnel zu FunkFeuer

Falls du Interesse hast, diese Idee zu einem Projekt und hoffentlich zu einem lauffähigen Produkt für die 0xFF-Gemeinschaft zu machen, mach mit und teile deine Ideen und Vorstellungen.

--> https://matrix.to/#/%230xFF-WireGuardTunnel%3Amatrix.org // #0xFF-WireGuardTunnel:matrix.org

Ziel

Es soll möglich sein, über WireGuard die Funktionalität des jetzigen OpenVPN-Zugangs abzubilden.
Es soll eine möglichst vollautomatische Konfig über das Frontend machbar sein.
Es soll IPv4 und IPv6 möglich sein.

Vorteile

Verschlüsselung des Tunnels bei niedriger CPU-Last
Multicore nutzung durch WG
Tunnel ist stateless
Software deutlich kleiner als OpenVPN
Konfig einfach - am Server komplett aus einer DB zu bauen.
NAT Traversal, NO Client PortForwarding

Nachteile

für OLSR muss eine Tunneltechnik durch den Tunnel gebaut werden, da WireGuard mit dem KEY/IP Routing sonst Probleme macht.

Link-Sammlung

EdgeRouter WireGuard - https://github.com/WireGuard/wireguard-vyatta-ubnt
MTU Calc - https://baturin.org/tools/encapcalc/
OLSR Debian - https://repos.freiesnetz.at/

Netzaufbau

      #-[WG/GRE/OLSR]---<Tunnelserver> ----------OLSR-------<Node1>
      |                  |                                    |
  [OpenWRT Client]       |                                    |
      |                 [WG/GRE/OLSR]                         |
      |                  |                                    |
      #-[WG/GRE/OLSR]---<Remote Node>-----------OLSR----------#

WG mit GREv6

Wir nutzen also von 1500 Framesize:

MTU bei IPv4 Tunnelverbindung
Frame	size	1500	DSL mit PPPoE	Mobil
		1500	1492	1464
IPv4 zum Tunnelserver	20	1480	1472	1444
WireGuard	40	1440	1432	1404
IPv6	40	1400	1392	1364
GREv6	4	1396	1388	1360
Nutzdaten	104	1396	1388	1360

MTU bei IPv6 Tunnelverbindung
Frame	size	1500	DSL mit PPPoE	Mobil
		1500	1492	1464
IPv6 zum Tunnelserver	40	1460	1452	1424
WireGuard	40	1420	1412	1384
IPv6	40	1380	1372	1344
GREv6	4	1376	1368	1340
Nutzdaten	124	1376	1368	1340

warum nicht gleich GREv6 mit IPSec?

weil der ESP Header 52 Bytes benötigt - damit ist man mit WireGuard 12 Bytes im Vorteil.
Und Keyverwaltung mit WireGuard ist auch einfacher Public/Private

Config

zw. Tunnelserver und Client(OpenWRT) wird ein Wireguard Tunnel aufgebaut

Adressen aus dem IPv6 ULA Bereich [[1]] einen klicken

1 serverseitig

2 clientseitig

Warum IPv6 - weil einfacher einzigartig zu bekommen bzw aus der nodeID zu errechnen.

In diesen WireGuard Tunnel wird nun ein GREv6 Tunnel gelegt und macht das komplizierte KEY Routing für bei WireGuard überflüssig. man könnte hier auch 0.0.0.0/0 verwenden bzw ::0/0 und alles direkt durch den WG Tunnel stopfen - macht das Routing am Tunnel-Server dann kompliziert - was seid [[2]] jedoch gehen sollte da OLSR nun an PtP Interfaces lauschen kann. Dieser Patch ist leider noch nicht wirklich in der breite angekommen.

wenn hier wer eine Bessere Idee hat bitte melden.

MeshMesh

Bei Clients mit sehr guten Uplinks macht es durchaus Sinn - Inter Node Tunnel aufzubauen - mit niedrigem Multiplier die im Fall es Ausfalls des Tunnelservers noch das Mesh weiter erhalten können

@@ Zeile 83: / Zeile 83: @@
 |}
-warum nicht gleich GREv6 mit IPSec??es
+warum nicht gleich GREv6 mit IPSec?
 * weil der ESP Header 52 Bytes benötigt - damit ist man mit WireGuard 12 Bytes im Vorteil.
-* Und Keyverwaltung mit WireGuard ist auch einfacher
+* Und Keyverwaltung mit WireGuard ist auch einfacher Public/Private
 == Config ==

WireGuard-Tunnel zu FunkFeuer: Unterschied zwischen den Versionen