WireGuard-Tunnel zu FunkFeuer: Unterschied zwischen den Versionen

Aus FunkFeuer Wiki
Zur Navigation springen Zur Suche springen
 
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 5: Zeile 5:
|desc=
|desc=
}}
}}
= TODO: WireGuard-Tunnel zu FunkFeuer =
== 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.
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.
Zeile 92: Zeile 92:


Adressen aus dem IPv6 ULA Bereich [[https://www.ip-six.de/]] einen klicken bzw wird es einen generator geben TODO
Adressen aus dem IPv6 ULA Bereich [[https://www.ip-six.de/]] einen klicken bzw wird es einen generator geben TODO
fd14:XX::1 serverseitig
fd14:XX::1 serverseitig
fd14:XX::2 clientseitig
fd14:XX::2 clientseitig


Warum IPv6 - weil einfacher einzigartig zu bekommen bzw aus der nodeID zu errechnen.
=== 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 IP/KEY Routing bei WireGuard überflüssig.
 
=== Warum GRE ===
 
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
weiters konnte bis [[https://github.com/OLSR/olsrd/commit/fcb30aa4da732d279527feba01cacc7dc996d137]] OLSR nicht an PtP lauschen.
 
Da OLSR nun an PtP Interfaces lauschen kann. Könnte man sich das nochmal genauer ansehen.
 
Dieser Patch ist leider noch nicht wirklich in der breite angekommen.


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 [[https://github.com/OLSR/olsrd/commit/fcb30aa4da732d279527feba01cacc7dc996d137]] jedoch gehen sollte da OLSR nun an PtP Interfaces lauschen kann. Dieser Patch ist leider noch nicht wirklich in der breite angekommen.
<pre style="color: red">
<pre style="color: red">
wenn hier wer eine Bessere Idee hat bitte melden.
wenn hier wer eine Bessere Idee hat bitte melden.

Aktuelle Version vom 21. April 2023, 23:58 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

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 bzw wird es einen generator geben TODO

fd14:XX::1 serverseitig

fd14:XX::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 IP/KEY Routing bei WireGuard überflüssig.

Warum GRE

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 weiters konnte bis [[2]] OLSR nicht an PtP lauschen.

Da OLSR nun an PtP Interfaces lauschen kann. Könnte man sich das nochmal genauer ansehen.

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

Abgerufen von „https://wiki.funkfeuer.at/index.php?title=WireGuard-Tunnel_zu_FunkFeuer&oldid=3526“