WireGuard-Tunnel zu FunkFeuer: Unterschied zwischen den Versionen

Aus FunkFeuer Wiki
Zur Navigation springen Zur Suche springen
 
(13 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 2: Zeile 2:
|name=WireGuard Tunnel für Nodes
|name=WireGuard Tunnel für Nodes
|startdate=2021/01/05
|startdate=2021/01/05
|state=Testing
|state=Proof of Concept
|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 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
* Konfig sehr einfach
* Konfig einfach - am Server komplett aus einer DB zu bauen.
* NAT Traversal, NO Client PortForwarding


=== MeshMesh ===
=== Nachteile ===


* Knoten könnten auch via Web sich vermeshen --> Redundanz
* für OLSR muss eine Tunneltechnik durch den Tunnel gebaut werden, da WireGuard mit dem KEY/IP Routing sonst Probleme macht.


== Nachteile ==
=== Link-Sammlung ===
 
* für OLSRv1 muss eine Layer2-Tunneltechnik durch den Tunnel gebaut werden, da WireGuard nur Layer3 macht
 
== Link-Sammlung ==


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


= Variante 1 - WG mit VXLAN =
== Netzaufbau ==
 
== Info ==
Remote Node kann via Wireguard verbinden und via SiteLocal ipv6 fd00 Adresse ein VXLAN aufbauen, dieses steckt in der bridge auf der OLSR läuft.
 
(SiteLocal könnte mit echter 0xFF IPv6 ersetzt werden, mir fällt jedoch kein Nutzen ein - atadxart)
 
* Wireguard Verbindung Node Public Key --> im Frontend hinterlegbar.
* SiteLocal IPv6 lässt sich zb aus NODE ID und Device ID aus dem Frontend errechnen.
* Wireguard ist zur Laufzeit konfigurierbar ohne laufende Tunnel zu stören.
* VXLAN ebenfalls zur Laufzeit konfigurierbar.
* IPv4 Sparsamkeit da nur eine IPv4 für alle Remote Nodes nötig
* Der IPv?/UDP-Wireguard/IPv6-VXLAN/IPv4 Stack ist recht dick doch da Wireguard multithread fähig ist darf mehr Durchsatz erwartet werden.
(ggü OpenVPN)
* Security - Daten Verschlüsselung, und durch Public/Private Key ist auch eine Authentifizierung gegenseitig gegeben.
 
--> Automatisierung somit vollständig möglich ohne Admin Eingriff am Tunnel-Server
 
=== TODO ===
 
Getestet ist es noch nicht, grundsätzlich müsste ein redundantes Tunnelserver Setup machbar sein.
 
atadxart - (werde ich noch nachliefern)
 
=== Netzaufbau ===
<pre>
<pre>
<Tunnelserver> ----------OLSR---------- <Node1>
      #-[WG/GRE/OLSR]---<Tunnelserver> ----------OLSR-------<Node1>
       |                                    |
      |                  |                                    |
  [Wireguard/VXLAN - OLSR]               |
  [OpenWRT Client]       |                                    |
       |                                    |
      |                [WG/GRE/OLSR]                         |
    <Remote Node> -----------OLSR----------#
       |                  |                                    |
      #-[WG/GRE/OLSR]---<Remote Node>-----------OLSR----------#
</pre>
</pre>


=== MTU ===
== WG mit GREv6 ==
Ausgehend von 1500 nutzbarer MTU
 
(PPPoE da leider oft bei den DSL Verbindungen nötig)
 
https://baturin.org/tools/encapcalc/?protocols=PPPoE,IPv4,WireGuard,IPv6,VXLAN,Ethernet
 
20 bytes bleiben da über aber es könnte ja IPv6 native vorm Wireguard sein dann kommt es auf
 
https://baturin.org/tools/encapcalc/?protocols=PPPoE,IPv6,WireGuard,IPv6,VXLAN,Ethernet
 
somit max MTU 1342
 
== Tunnelserver ==
 
* Debian 11
* OLSR von https://repos.freiesnetz.at/
* wireguard
* ifupdown2
 
=== /etc/network/interfaces ===
<pre>
auto lo
iface lo inet loopback
 
#VIRTUAL Wireless link to Node 1
# OLSR interface
 
auto enp1s0
iface enp1s0
  address 10.1.0.1/32
 
#INTERNET
 
auto enp2s0
iface enp2s0 inet dhcp
 
#Bridge für VXLANS
#OLSR Interface
 
auto br0
iface br0
  pre-up /usr/bin/ip link add br0 type bridge
  address 10.1.1.1/32
  post-up /usr/bin/ip link set br0 mtu 1342
 
#WIREGUARD
#für alle Clients


auto wg-olsr
Wir nutzen also von 1500 Framesize:
iface wg-olsr
{| class="wikitable" style="margin:auto"
  pre-up /usr/bin/ip link add wg-olsr type wireguard
|+ MTU bei IPv4 Tunnelverbindung
  pre-up /usr/bin/wg setconf wg-olsr /etc/wireguard/wg-olsr.conf
! Frame !! size !! 1500  !! DSL mit PPPoE !! Mobil
 
|-
  post-up /usr/bin/ip link set wg-olsr mtu 1420
|  ||  || 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
|}


#dieser part muss für jeden remote client ausgeführt werden
{| class="wikitable" style="margin:auto"
#Remote Node Config
|+ MTU bei IPv6 Tunnelverbindung
  post-up /usr/bin/ip addr add fd00:00ff:0001:abba::1/64 dev wg-olsr
! Frame !! size !! 1500  !! DSL mit PPPoE !! Mobil
  post-up /usr/bin/ip link add vxlan1 type vxlan id 1 remote fd00:00ff:0001:abba::2 dstport 4789 dev wg-olsr
|-
  post-up /usr/bin/ip link set vxlan1 up
|  ||  || 1500 || 1492 || 1464
  post-up /usr/bin/ip link set vxlan1 mtu 1342
|-
  post-up /usr/bin/ip link set vxlan1 master br0
| 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
|}


</pre>
warum nicht gleich GREv6 mit IPSec?
 
* weil der ESP Header 52 Bytes benötigt - damit ist man mit WireGuard 12 Bytes im Vorteil.
=== /etc/olsrd/olsrd.conf ===
* Und Keyverwaltung mit WireGuard ist auch einfacher Public/Private
 
Hier nur die zusätzlichen Settings
<pre>
Interface "enp1s0"
{
      AutoDetectChanges      yes
      LinkQualityMult        default 1.0
      Weight                  0
}


Interface "br0"
== Config ==
{
      AutoDetectChanges      yes
      LinkQualityMult        default 1.0
      Weight                  0
}
</pre>


=== /etc/wireguard/wg-olsr.conf ===
zw. Tunnelserver und Client(OpenWRT) wird ein Wireguard Tunnel aufgebaut
<pre>
[Interface]
ListenPort = 51820
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXX


##Remote Node
Adressen aus dem IPv6 ULA Bereich [[https://www.ip-six.de/]] einen klicken bzw wird es einen generator geben TODO
[Peer]
PublicKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXX
AllowedIPs = fc00:ff:1:abba::2
PersistentKeepalive = 25
</pre>


== Remote Node ==
fd14:XX::1 serverseitig


* Debian 11
fd14:XX::2 clientseitig
* OLSR von https://repos.freiesnetz.at/
* wireguard
* ifupdown2


=== /etc/network/interfaces ===
=== Warum IPv6 ===
<pre>
weil einfacher einzigartig zu bekommen bzw aus der nodeID zu errechnen.
auto enp1s0
iface enp1s0 inet dhcp


auto enp7s0
In diesen WireGuard Tunnel wird nun ein GREv6 Tunnel gelegt und macht das IP/KEY Routing bei WireGuard überflüssig.
iface enp7s0
  address 10.3.0.1/32


auto br0
=== Warum GRE ===
iface br0
  pre-up /usr/bin/ip link add br0 type bridge
  address 10.3.1.1/32
  post-up /usr/bin/ip link set br0 mtu 1342


auto wg-olsr
man könnte hier auch 0.0.0.0/0 verwenden bzw ::0/0 und alles direkt durch den WG Tunnel stopfen
iface wg-olsr
  pre-up /usr/bin/ip link add wg-olsr type wireguard
  pre-up /usr/bin/wg setconf wg-olsr /etc/wireguard/wg-olsr.conf
  address fd00:00ff:0001:abba::2/64
  post-up /usr/bin/ip link set wg-olsr mtu 1420
  post-up /usr/bin/ip link add vxlan1 type vxlan id 1 remote fd00:00ff:0001:abba::1 dstport 4789 dev wg-olsr
  post-up /usr/bin/ip link set vxlan1 up
  post-up /usr/bin/ip link set vxlan1 mtu 1342
  post-up /usr/bin/ip link set vxlan1 master br0
</pre>


=== /etc/olsrd/olsrd.conf ===
--> macht das Routing am Tunnel-Server dann kompliziert
<pre>
weiters konnte bis [[https://github.com/OLSR/olsrd/commit/fcb30aa4da732d279527feba01cacc7dc996d137]] OLSR nicht an PtP lauschen.
Interface "enp7s0"
{
AutoDetectChanges yes
LinkQualityMulti default 1.0
Weight 0
}


Interface "br0"
Da OLSR nun an PtP Interfaces lauschen kann. Könnte man sich das nochmal genauer ansehen.
{
AutoDetectChanges yes
LinkQualityMulti default 1.0
Weight 0
}
</pre>


=== /etc/wireguard/wg-olsr.conf ===
Dieser Patch ist leider noch nicht wirklich in der breite angekommen.
<pre>
[Interface]
ListenPort = 51820
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


#tunnel server
<pre style="color: red">
[Peer]
wenn hier wer eine Bessere Idee hat bitte melden.
Endpoint = tunnelserver:51820
PublicKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
AllowedIPs = fd00:ff:1:abba::1
PersistentKeepalive = 25
</pre>
</pre>


== Mikrotik ==
== MeshMesh ==
WireGuard und VXLAN laufen --> Docker OLSR
Was geht nicht IPv6 VXLAN, Mikrotik support fehlt, Workaround ZeroConf Ipv4


<pre>
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
# RouterOS 7.1.1
# software id =
#
# model = RB960PGS
# serial number = XXXXXXXXXXXXXX
/interface wireguard
add listen-port=13231 mtu=1420 name=wg-olsr
/interface vxlan
add mtu=1342 name=vxlan-olsr port=4789 vni=2
/interface lte apn
set [ find default=yes ] ip-type=ipv4
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip settings
set max-neighbor-entries=8192
/ipv6 settings
set accept-redirects=no max-neighbor-entries=8192
/interface vxlan vteps
add interface=vxlan-olsr remote-ip=169.254.0.1
/interface wireguard peers
add allowed-address=169.254.0.1/32 endpoint-address=\
    TUNNELIP endpoint-port=51820 interface=wg-olsr persistent-keepalive=\
    25s public-key="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX="
/ip address
add address=169.254.2.1/16 interface=wg-olsr network=169.254.0.0
/ip dhcp-client
add interface=sfp1
/system clock
set time-zone-name=Europe/Vienna
</pre>

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“