WireGuard-Tunnel zu FunkFeuer: Unterschied zwischen den Versionen
K |
K (→Config) |
||
Zeile 89: | Zeile 89: | ||
== Config == | == Config == | ||
zw. Tunnelserver und Client(OpenWRT) wird ein Wireguard | zw. Tunnelserver und Client(OpenWRT) wird ein Wireguard Tunnel aufgebaut | ||
Adressen aus dem IPv6 ULA Bereich [[https://www.ip-six.de/]] einen klicken | Adressen aus dem IPv6 ULA Bereich [[https://www.ip-six.de/]] einen klicken |
Version vom 21. April 2023, 23:47 Uhr
WireGuard Tunnel für Nodes | |
---|---|
Starttermin |
05 Jan. 21 |
Status | |
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:
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 |
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??es
- weil der ESP Header 52 Bytes benötigt - damit ist man mit WireGuard 12 Bytes im Vorteil.
- Und Keyverwaltung mit WireGuard ist auch einfacher
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