WireGuard-Tunnel zu FunkFeuer - Versionsgeschichte

Atadxart: /* Warum IPv6 */

2023-04-21T22:58:43Z

Warum IPv6

← Nächstältere Version		Version vom 21. April 2023, 22:58 Uhr
Zeile 101:		Zeile 101:

	In diesen WireGuard Tunnel wird nun ein GREv6 Tunnel gelegt und macht das IP/KEY Routing bei WireGuard überflüssig.		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		man könnte hier auch 0.0.0.0/0 verwenden bzw ::0/0 und alles direkt durch den WG Tunnel stopfen

Atadxart: /* Warum IPv6 */

2023-04-21T22:56:56Z

Warum IPv6

← Nächstältere Version		Version vom 21. April 2023, 22:56 Uhr
Zeile 100:		Zeile 100:
	weil einfacher einzigartig zu bekommen bzw aus der nodeID zu errechnen.		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.		In diesen WireGuard Tunnel wird nun ein GREv6 Tunnel gelegt und macht das IP/KEY Routing 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.
			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.

	<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.

Atadxart: /* TODO: WireGuard-Tunnel zu FunkFeuer */

2023-04-21T22:52:02Z

TODO: WireGuard-Tunnel zu FunkFeuer

← Nächstältere Version		Version vom 21. April 2023, 22:52 Uhr
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.

Atadxart: /* Config */

2023-04-21T22:50:12Z

Config

← Nächstältere Version		Version vom 21. April 2023, 22:50 Uhr
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 komplizierte KEY Routing für bei WireGuard überflüssig.		In diesen WireGuard Tunnel wird nun ein GREv6 Tunnel gelegt und macht das komplizierte KEY Routing für bei WireGuard überflüssig.

Atadxart: /* Config */

2023-04-21T22:49:35Z

Config

← Nächstältere Version		Version vom 21. April 2023, 22:49 Uhr
Zeile 91:		Zeile 91:
	zw. Tunnelserver und Client(OpenWRT) wird ein Wireguard Tunnel aufgebaut		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 bzw wird es einen generator geben TODO
	::1 serverseitig		fd14:XX::1 serverseitig
	::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.

Atadxart: /* WG mit GREv6 */

2023-04-21T22:48:18Z

WG mit GREv6

← Nächstältere Version		Version vom 21. April 2023, 22:48 Uhr
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.		* 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 ==		== Config ==

Atadxart: /* Config */

2023-04-21T22:47:51Z

Config

← Nächstältere Version		Version vom 21. April 2023, 22:47 Uhr
Zeile 89:		Zeile 89:
	== Config ==		== Config ==

	zw. Tunnelserver und Client(OpenWRT) wird ein Wireguard ~~Tunnelaufgebaut~~		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

Atadxart am 21. April 2023 um 22:45 Uhr

2023-04-21T22:45:29Z

← Nächstältere Version		Version vom 21. April 2023, 22:45 Uhr
Zeile 16:		Zeile 16:
	* Es soll eine möglichst vollautomatische Konfig über das Frontend machbar sein.		* Es soll eine möglichst vollautomatische Konfig über das Frontend machbar sein.
	* Es soll IPv4 und IPv6 möglich sein.		* Es soll IPv4 und IPv6 möglich sein.
	* ...

	== Vorteile ==		=== Vorteile ===

	* Verschlüsselung des Tunnels bei niedriger CPU-Last		* Verschlüsselung des Tunnels bei niedriger CPU-Last
			* Multicore nutzung durch WG
	* Tunnel ist stateless		* Tunnel ist stateless
	* Software deutlich kleiner als OpenVPN		* Software deutlich kleiner als OpenVPN
Zeile 26:		Zeile 26:
	* NAT Traversal, NO Client PortForwarding		* NAT Traversal, NO Client PortForwarding

	== Nachteile ==		=== Nachteile ===

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

	== Link-Sammlung ==		=== Link-Sammlung ===

	* EdgeRouter WireGuard - https://github.com/WireGuard/wireguard-vyatta-ubnt		* EdgeRouter WireGuard - https://github.com/WireGuard/wireguard-vyatta-ubnt
Zeile 36:		Zeile 36:
	* OLSR Debian - https://repos.freiesnetz.at/		* OLSR Debian - https://repos.freiesnetz.at/

	=== Netzaufbau ===		== Netzaufbau ==
	<pre>		<pre>
	#-[WG/GRE/OLSR]---<Tunnelserver> ----------OLSR-------<Node1>		#-[WG/GRE/OLSR]---<Tunnelserver> ----------OLSR-------<Node1>
Zeile 46:		Zeile 46:
	</pre>		</pre>

	= WG mit GREv6 =		== WG mit GREv6 ==

	Wir nutzen also von 1500 Framesize:		Wir nutzen also von 1500 Framesize:
Zeile 103:		Zeile 103:
	</pre>		</pre>

	= MeshMesh =		== MeshMesh ==

	Bei Clients mit guten Uplinks ~~>200Mbit~~ 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		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

Atadxart: /* WG mit grev6 */

2023-04-21T22:43:45Z

WG mit grev6

← Nächstältere Version		Version vom 21. April 2023, 22:43 Uhr
Zeile 46:		Zeile 46:
	</pre>		</pre>

	= WG mit ~~grev6 =~~		= WG mit GREv6 =
	~~== OpenWRT~~ ==

	~~zw. Tunnelserver und Client(OpenWRT) wird ein Wireguard Tunnelaufgebaut~~
	~~Adressen aus dem IPv6 ULA Bereich [[https://www.ip-six.de/]] einen klicken~~
	~~::1 serverseitig~~
	~~::2 clientseitig~~

	~~In diesen Tunnel wird nun ein GREv6 Tunnel gelegt - dieser hat nur 4 Bytes Overhead und macht die komplizierte KEY Routing config bei WireGuard überflüssig.~~

	Wir nutzen also von 1500 Framesize:		Wir nutzen also von 1500 Framesize:
Zeile 80:		Zeile 72:
	\| \|\| \|\| 1500 \|\| 1492 \|\| 1464		\| \|\| \|\| 1500 \|\| 1492 \|\| 1464
	\|-		\|-
	\| IPv6 zum Tunnelserver \|\| 40 \|\| ~~1440~~ \|\| 1452 \|\| 1424		\| IPv6 zum Tunnelserver \|\| 40 \|\| 1460 \|\| 1452 \|\| 1424
	\|-		\|-
	\| WireGuard \|\| 40 \|\| ~~1400~~ \|\| 1412 \|\| 1384		\| WireGuard \|\| 40 \|\| 1420 \|\| 1412 \|\| 1384
	\|-		\|-
	\| IPv6 \|\| 40 \|\| ~~1360~~ \|\| 1372 \|\| 1344		\| IPv6 \|\| 40 \|\| 1380 \|\| 1372 \|\| 1344
	\|-		\|-
	\| GREv6 \|\| 4 \|\| ~~1356~~ \|\| 1368 \|\| 1340		\| GREv6 \|\| 4 \|\| 1376 \|\| 1368 \|\| 1340
	\|-		\|-
	\| Nutzdaten \|\| ~~104~~ \|\| ~~1356~~ \|\| 1368 \|\| 1340		\| Nutzdaten \|\| 124 \|\| 1376 \|\| 1368 \|\| 1340
	\|}		\|}

	warum nicht gleich GREv6 mit IPSec??		warum nicht gleich GREv6 mit IPSec??es
	* weil der ESP Header 52 Bytes benötigt - damit ist man mit WireGuard 12 Bytes im Vorteil.		* 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

			== Config ==

			zw. Tunnelserver und Client(OpenWRT) wird ein Wireguard Tunnelaufgebaut

			Adressen aus dem IPv6 ULA Bereich [[https://www.ip-six.de/]] 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 [[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">
			wenn hier wer eine Bessere Idee hat bitte melden.
			</pre>

	= MeshMesh =		= MeshMesh =

	Bei Clients mit guten Uplinks >200Mbit 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		Bei Clients mit guten Uplinks >200Mbit 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

Atadxart: PoC

2023-04-21T22:27:22Z

PoC

Änderungen zeigen