Wireguard 0.0.20161230 linuxkernel 3.18+ gluon v2016.2.2


#1

wireguard erlaubt seit letzter Woche auch Kernel 3.18++
dass ist nicht nur super für Android Geräte, sondern auch für aktuelles Gluon (2016++). Die sind im Moment in der Regel noch bei ~ 3.18 Kerneln.

damit kann man wireguard/gretap auch auf den 841er laufen lassen, soweit bin ich derweil. Nun stehen Geschwindigkeit Tests und ein Plan für Key/IP Austausch Peer<>Server noch an.

also von Hand unter ./gluon/openwrt/package/kerne/network - wireguard Ordner entsprechend angelegt und Makefile sowie files/wireguard.sh hinzugefügt.
(von hier kopiert https://github.com/openwrt/packages/tree/master/net/wireguard , sonst müsste man alternativ an den OpenWRT Commit als Grundlage drehen und das explodiert erfahungsgemäss gerne mal an vielen anderen Stellen)
(evtl im Ordner gluon/openwrt make menuconfig ausführen und wireguard sowie gre zum bauen vormerken)

danach die fastd-pakete aus der site.mk entfernt und die für wireguard/gre nötigen Pakete hinzugefügt. Wenn man nicht für die 4Mb Geräte baut, kann man fastd durchaus auch drin lassen.

# hinzugeügte Pakete zu site.mk
kmod-gre kmod-gre6 ip-full kmod-wireguard wireguard-tools \

# entfernte Pakete
#         gluon-config-mode-mesh-vpn \
#        gluon-mesh-vpn-fastd

related links
lede-wireguard-gretap-ergebnisse-unter-livebedingungen
wireguard-als-zukuenftige-vpn-loesung
erste wg tests
wireguard-tag

script für all incl auf knoten

# cat foo.sh 
#!/bin/sh

# every peer should have its own ip
IP=192.168.99.2

# check if key exist
[ -f /root/wg_privatekey ] || wg genkey > /root/wg_privatekey && wg pubkey < /root/wg_privatekey > /root/wg_publickey

# del and make new wg0
ip link del dev wg0 2>/dev/null || true
ip link add dev wg0 type wireguard

# if conf not exist make 
if [ ! -f /root/wg_conf ]; then
cat<<EOF > /root/wg_conf
[Interface]
ListenPort = 10099

[Peer]
PublicKey = Gqntn/96zfRrz6SedcNXzw7b+vyjn6IfZlFM8+6U63E= 
Endpoint = 136.243.153.228:10099
AllowedIPs = 0.0.0.0/0,fe80::/0
EOF
fi

# addconf
wg addconf wg0 /root/wg_conf
wg set wg0 private-key /root/wg_privatekey
ip addr add fdf1::$(cat /sys/class/net/eth0/address)/64 dev wg0
ip addr add fe80::$(cat /sys/class/net/eth0/address)/64 dev wg0
# <me> peer <the other>
ip address add $IP/32 peer 192.168.99.1/32 dev wg0
# test if v6 is sufficient , so own ip could be uniq
#ip address add fdf1::$(cat /sys/class/net/eth0/address) peer fdf1::16:3e:75:72:af/64 dev wg0
ip link set up dev wg0

# grestuff
ip link add gre4 type gretap remote 192.168.99.1 local $IP
ifconfig gre4 up

# batman
batctl if add gre4

helpfull lines for server…

# nebst dem anderen foo , siehe peer config ...  neuer peer zu server hinzufügen
# angenommen der server lauscht auf 10099 und wg0 intern auf 192.168.99.1
wg genkey > /root/wg_privatekey && wg pubkey < /root/wg_privatekey > /root/wg_publickey

wg set wg0 peer lustigerneuerpeerkey= allowed-ips 192.168.99.5/32
ip link add gre5 type gretap remote 192.168.99.5 local 192.168.99.1 ttl 255
ifconfig gre5 up

[ffdus] Gluon 2016.2.5.2 stable (fastd/l2tp): clientroaming + 841v12
[ffdus] Gluon 2016.2.5 release (fastd/l2tp zur Auswahl)
Gluon, L2TP und site.conf
Anytun tunnel protokoll
500+ gretap tunnel Interfaces in batman einhängen (für wireguard)
#2

Echt Klasse, dass du dich da so reinhängst! Weiter so!!!


#3

…ich hab zwar nicht mal die Hälfte technisch verstanden, was Du da genau machst, aber wenn es funktioniert: Super!

Danke für Dein Engagement!


#4

Es gibt hier vermutlich viele Dutzend Leute, die sehr, sehr gespannt in Eurer Richtung schauen und positiven Meldungen entgegenfiebern.

Wenn irgendwelche “überschaubare” Aufgaben zu übernehmen sind oder ihr Resourcen braucht, dann meldet Euch bitte!


500+ gretap tunnel Interfaces in batman einhängen (für wireguard)
#5

danke - im großen sinds nunmehr detail und design fragen,
neben dem testen auf Geräten und Geschwindigkeit wären da noch fragen wie

  • wie wieviele gretap tunnel if kann man so auf nem server aufmachen (>500)
  • wieviele dieser tunnel interface kann man in batman einhängen (>500)
  • hat das unvorhergesehene performance impacts
  • wie gestaltet man die keyverwaltung (inkl. der nötigen ip)
  • ein passendes paket dazu bauen für den config mode
  • Freifunk durch Freifunk verhindern = erkennen von echtem uplink oder mesh
  • soll es sowas wie ein fallback geben (ähnl. wie bei fastd mehrere supernodes)
  • macht 4.4 kernel (gerade lede) oder 3.18 nen großen unterschied?

im grunde wäre es super andere bauen das auch mal zusammen um da erfahrungen zu sammeln.
mit starker vorsicht zu geniessen wären diese sysupgrade
v2016.2.x.2-wg (v14 und v15 da) http://openfreiburg.de/freifunk/firmware/support/sysupgrade/
(vorsicht da u.a emergency script (mit reboot wenn keine batgw für 10 min) darin und ssh keys von uns aus freiburg)


500+ gretap tunnel Interfaces in batman einhängen (für wireguard)
#6

Die Tunnel laufen super und stabil und der durchsatz ist gut, mag jemand da mit an einem Gluon package basteln … ? direkte PM an mich


#7

Kannst du vielleicht nochmal kurz die Fakten zusammen fassen:

  • Wireguard ist ein VPN Tunnel? Layer ?
  • greTAP ist auf diesem Tunnel nötig?
  • die Kombination greTAP und Wireguard kann kann fastd / L2TP ersetzen?
  • Gibt es eine Verschlüsselung?
  • Läuft es im Kernel oder im Userspace?
  • Man will Wireguard weil?

Gruß
Tarnatos


#8

Layer 3 crypto Routing Protokoll - ähnlich OpenVpn wird dort ein IP>IP Tunnel aufgemacht und UDP benutzt., Generell ist die Seite von wireguard, da sehr gut und Informativ https://www.wireguard.io/

um für batman-adv das nötige layer 2 zur verfügung zu stellen. Man kann natürlich auch fragen wofür man eigentlich Batman in Richtung Backend will. Aber für einen smoothes ersetzen von bestehenden Lösungen (und großen Batman Netzen) ist das nötig.

für l2tp kann ich nix sagen, wenn damit auch l2tp-eth gemeint ist bestimmt. Für Fastd trifft das zu, es wird dann der gretap-tunnel der auf dem wireguard IF liegt in Batman-adv eingehängt. Die Lösung funktioniert auf den Routern und gegenüber einem Endpunkt dann genauso wie fastd. Auf Serverseite hat man dann neben dem wg0 IF pro peer ein zusätzliches gretap Link-IF.

[quote=“Tarnatos, post:7, topic:14122”]
Gibt es eine Verschlüsselung?
[/quote]fast identisch zu fastd - daher find ich das so charmant. einen mind. 3mal so schnellen Tunnel auf den embedded Devices zu haben wie fastd.
siehe dazu auch https://www.wireguard.io/protocol/

kernelspace, wireguard sowie gretap - contextswitche sind am Ende nur 1/10 derer von fastd… (vgl. 100Mb download>dev/null 74000 zu 5600 )

weil man einen verschlüsselte Tunnel zu seinem Backend/freifunk-netz/exit will. Man kann auch die Server im Backend mit Wireguard verbinden statt dem anfälligen tinc, oder den unverschlüsselten Lösungen, das ist aber nicht was ich gerade hier meine.(Wireguard link auf Serverebene auf GB Link >800Mbit ).


Tinc - Erfahrungen / Probleme?
#9

das gleiche script für V6 in dem WG tunnel IF

#!/bin/sh

SERVERIPWG=fdf1::16:3e75:72af
MASK=128
SERVERIPEXT=136.243.153.228
SERVERPORT=10099
IP=fdf1::$(cat /sys/class/net/eth0/address|awk 'BEGIN{FS=":"}{print $1$2":"$3$4":"$5$6}')

# check if key exist
[ -f /root/wg_privatekey ] || wg genkey > /root/wg_privatekey && wg pubkey < /root/wg_privatekey > /root/wg_publickey

# del and make new wg0
ip link del dev wg0 2>/dev/null || true
ip link add dev wg0 type wireguard

# if conf not exist make 
if [ ! -f /root/wg_conf ]; then
cat<<EOF > /root/wg_conf
[Interface]
ListenPort = $SERVERPORT 

[Peer]
PublicKey = Gqntn/96zfRrz6SedcNXzw7b+vyjn6IfZlFM8+6U63E= 
Endpoint = $SERVERIPEXT:$SERVERPORT
AllowedIPs = 0.0.0.0/0,fe80::/0
EOF
fi

# addconf
wg addconf wg0 /root/wg_conf
wg set wg0 private-key /root/wg_privatekey
# ip addr add fdf1::$(cat /sys/class/net/eth0/address|awk 'BEGIN{FS=":"}{print $1$2":"$3$4":"$5$6}')/64 dev wg0
ip addr add fe80::$(cat /sys/class/net/eth0/address|awk 'BEGIN{FS=":"}{print $1$2":"$3$4":"$5$6}')/64 dev wg0
# <me> peer <the other>
# v4
# ip address add $IP/32 peer 192.168.99.1/32 dev wg0
# v6
ip address add $IP/$MASK peer $SERVERIPWG/$MASK dev wg0

ip link set up dev wg0

# grestuff
# v6
ip link add gre6 type ip6gretap remote $SERVERIPWG local $IP
ifconfig gre6 up
# v4 legacy
# ip link add gre4 type gretap remote $SERVERIPWG local $IP   
# ifconfig gre4 up

# batman
# or gre4
batctl if add gre6

echo $IP
cat /root/wg_publickey

edit: aktualisiert - fehler bitte als PM an mich , dann kann ich das korrigieren


#10

manche menschen haben gefragt warum nicht ein l2tp-eth Tunnel statt ip6 GREtap
nun, weil der insg.mehr Speicher als Paket braucht (l2tp-eth + l2tp vs nur GRE6 plus einiges an foo)
und weil der Langsamer ist, ich mach die Tage genauere Tests mit gre und l2tp-eth im wireguard tunnel wg0, aber im Grunde kann man dank justus Messungen schon erahnen das es um die 15-20% einbrechen würde.
https://justus.berlin/2016/02/performance-of-tunneling-methods-in-openwrt/comment-page-1/#comment-53065

hier aktuelle Paketgrößen von so üblichen Verdächtigen

/tmp# ls -la *ipk
…12038 kmod-gre6_3.18.44-2_ar71xx.ipk
…8615 kmod-gre_3.18.44-2_ar71xx.ipk
…3635 kmod-l2tp-eth_3.18.44-2_ar71xx.ipk
…13942 kmod-l2tp_3.18.44-2_ar71xx.ipk
…12809 kmod-tun_3.18.44-2_ar71xx.ipk
…66837 kmod-wireguard_3.18.44+0.0.20161230-1_ar71xx.ipk
…53236 fastd_17-1_ar71xx.ipk
105319 ip-full_4.0.0-1_ar71xx.ipk
…76352 kmod-batman-adv-legacy_3.18.44+2016-05-31-1_ar71xx.ipk
…72499 kmod-batman-adv_3.18.44+2016.2-1_ar71xx.ipk

sehr einfacher Test

50Mbit anschluss, 2 router parallel an Fritzbox direkt nacheinander getestet.
ibss0 abgeschaltet. bei etwa 80-120kbit Grundrauschen - livebedingungen
(Geschwindigkeit = 100MByte*8 => 800Mbit / Anzahl_Sekunden = xy Mbit/s)
pingzeiten sind beide bei so 35 ms

direkter vergleich
time -v wget http://10.60.5.110/random100M -O /dev/null
time -v wget http://[fdf0:9bb:7814:a630::7]/random100M -O /dev/null
[freifunk server am anderen ende der galaxie - unserem Freifunknetz]
gretap4 : 73s - 1:13m - 10,9Mbit
gretap6 : 70s - 1:10m - 11,4Mbit
l2tp-eth : 90s - 1:30m - 8,8 Mbit

time -v wget http://192.168.99.1/random100M -O /dev/null
time -v wget http://192.168.100.23/random100M -O /dev/null
time -v wget http://[fdf1::16:3e75:72af]/random100M -O /dev/null
[direkt im tunnel das gegenüber am server]
gretap4 : 39 s - 20,5Mbit
gretap6 : 50 s - 16Mbit
l2tp-eth : 50 s - 16Mbit

time -v wget http://[fdf0:9bb:7814:a630:1c61:19ff:fefd:3ed2]/random100M -O /dev/null
[definitiv batman wegen subnetz, aber direkt am wireguard server]
gretap: 74s (1:14m) - 10,8Mbit
l2tp-eth: 107s (1:47m) - 7,4Mbit
im Vergleich ein 841v9 gretap : 1:50 - 7,2Mbit
sonst alles mit 841v11 getestet

mit ibss0 an scheint die verbindung so träge zu sein, das oft trotz eigenem direktlink traffic über ibss0 geht : zumindest deutet das iftop am anderen Ende darauf hin. Ein initialer Ping dauert auch erst immer x sekunden, und der erste hat 1000ms die folgenden sind dann mit 35ms “normal”.


#11

irgendwie is das hier verloren gegangen, entweder ich hab mich “verklickt”, oder jemand anders, oder hier is nen serious bug - however, sehr guter Überblick :

Wireguard auf der Fosdem Febr. 2017:

Paper/slides https://www.wireguard.io/talks/fosdem2017-slides.pdf
Video https://data.zx2c4.com/fosdem-video-fix-audio-video-sync/wireguard.mp4
und nochmal der Link zu HP https://www.wireguard.io/presentations/

(slightly older ones https://www.youtube.com/watch?v=eYztYCbV_8U )


#12

gluon-mesh-wireguard Paket rc

vorbehaltlich einiger Bugs - hier ein Paket das komplett fastd ersetzen kann/ die Funktionalität bisheriger VPN Tunnel abdeckt

dazu auch die README.md lesen. Wo ich noch Hilfe gebrauchen könnt’, wäre den lua Code dahin bringen, dass man beliebig viele Server in die site.conf schreiben kann. Bzw den überhaupt zum laufen bringen (400-wireguard) - bisher ist das mit shell “gehackt” (404-wireguard und 405-wireguard).
Auch Menschen die das mal bauen, sei es als eigene Firmware, oder die Pakete bei sich installieren und dies in ihren Netzen als direkten Vergleich probieren.

lazy 3.18.44 Pakete

solltet ihr einen Kernel 3.18.44 haben (uname -a) hier die pakete zum direkt installieren (dazu keinen support von mir)

http://www.openfreiburg.de/freifunk/firmware/modules/gluon-fffr-v2017.1.0.b-wg_pack_v14/ar71xx/generic/kmod-gre6_3.18.44-2_ar71xx.ipk
http://www.openfreiburg.de/freifunk/firmware/modules/gluon-fffr-v2017.1.0.b-wg_pack_v14/ar71xx/generic/kmod-gre_3.18.44-2_ar71xx.ipk
http://www.openfreiburg.de/freifunk/firmware/modules/gluon-fffr-v2017.1.0.b-wg_pack_v14/ar71xx/generic/kmod-wireguard_3.18.44+0.0.20161230-1_ar71xx.ipk
http://www.openfreiburg.de/freifunk/firmware/modules/gluon-fffr-v2017.1.0.b-wg_pack_v14/ar71xx/generic/kmod-ipt-hashlimit_3.18.44-2_ar71xx.ipk
http://www.openfreiburg.de/freifunk/firmware/ipk/gluon-mesh-wireguard_1_ar71xx.ipk
http://www.openfreiburg.de/freifunk/firmware/ipk/wireguard-tools_0.0.20161230-1_ar71xx.ipk
http://www.openfreiburg.de/freifunk/firmware/ipk/ip-full_4.0.0-1_ar71xx.ipk
http://www.openfreiburg.de/freifunk/firmware/modules/gluon-fffr-v2017.1.0.b-wg_pack_v14/ar71xx/generic/kmod-udptunnel4_3.18.44-2_ar71xx.ipk
http://www.openfreiburg.de/freifunk/firmware/modules/gluon-fffr-v2017.1.0.b-wg_pack_v14/ar71xx/generic/kmod-udptunnel6_3.18.44-2_ar71xx.ipk

lazy FW

dort sind ein paar Freiburger besonderheiten eingebaut - das ärgste dürfte bat-v14, ssh-keys und das emergency script sein. Muss man wissen wenn mann das benutzen wollt. Suche nach der FW v2017.1.0.b-wg_pack_v14
in http://www.openfreiburg.de/freifunk/firmware/support/

site.conf Beispiel

wird nicht gecheckt - aber das wäre dann in zukunft der Weg das zu Konfigurieren,
wie bei fastd beispielsweis auch

wireguard = {
                enabled = '1',
                iface = 'wg0',
                v6 = '1',
                v4 = '0', -- not implemented, and maybe never because of gretap complexity
                batman = '1', --  this may include all the gretap magic
                secret = '', -- set on demand on client
                port = '10099', -- s2p initiatet tunnel difficult because of nat
                limit = '1', -- actually unused
                peer = {
                        mesh1 = {
                                enabled = '1',
                                PublicKey ='Gqntn/96zfRrz6SedcNXzw7b+vyjn6IfZlFM8+6U63E=',
                                Endpoints ='136.243.153.228:10099',
                                gretapIP = 'fdf1::16:3e75:72af',
                                AllowedIps ='0.0.0.0/0,::/0',    -- this has to be more narrowed with more mesh-xy
                        },
                },
        },

modules

GLUON_SITE_FEEDS='blablablaanderepakete meshwireguard'
PACKAGES_MESHWIREGUARD_REPO=https://github.com/viisauksena/gluon-mesh-wireguard.git
PACKAGES_MESHWIREGUARD_COMMIT=cb77788ee49fe5b81789d01eed49aa30e971dd8e
PACKAGES_MESHWIREGUARD_BRANCH=master

debughilfe: falls das nicht baut hier meine “overkill” lines aus der site.mk

        wireguard-tools \
        ip-full \
        gluon-mesh-wireguard kmod-ipt-hashlimit kmod-gre6 kmod-wireguard kmod-udptunnel6 kmod-udptunnel4 \

debughilfe: hier dependencies der openwrt - Pakete

0 root@fffr-486-wg14:/tmp# opkg depends kmod-wireguard
kmod-wireguard depends on:
	kernel (= 3.18.44-2-44f588bc55955a8e9f1f3a9388b3e4a4)
	kmod-udptunnel6
	kmod-udptunnel4
	kmod-ipt-hashlimit
0 root@fffr-486-wg14:/tmp# opkg depends gluon-mesh-wireguard
gluon-mesh-wireguard depends on:
	libc
	gluon-core
	micrond
	kmod-gre
	kmod-gre6
	ip-full
	kmod-wireguard
	wireguard-tools
0 root@fffr-486-wg14:/tmp# opkg depends wireguard-tools
wireguard-tools depends on:
	libc
	libmnl


#13

Gibt es eventuell auch eine Anleitung, wie man den Supernode dafür baut?


#14

@adorfer : wie im ersten Beitrag und zwischen den Zeilen immer wieder geschrieben unterscheiden die supernodes sich in keiner hinsicht zu den anderen (fastd,l2tp,offloader).
Ich gehe hier also davon aus, dass dort Magic-Magic ein Supernode ist, an dem mind. 1 batman interface rauskommt - das wird dann gefüttert ; das wie, steht bspw. im ersten Beitrag oben.
Auch mit dem beispiel script für v6 kommt man schon weit.

Letztendlich immer : wg0 if aufmachen fdf1:: Adresse dazu und Tunnel aufmachen, ip6gretap drüber und das gretap if in batman mit reinhängen.

Die Server config is hier out of scope für mich, zumal da noch ne menge anderer Fragen aufkommen würden.
dennoch hier 3 skripte die ich benutze für die serverseitigen wg geschichten
wobei ich peers im moment per hand hinzufüge, das würde aber auch automatisiert gehen ./peeradd6 <wgpubkey> <ipv6>

initialize wg0

(bspw. nach reboot oder initial)

#!/bin/bash

# before we check if config and key exist
## key         
[ -f wg_privatekey ] || wg genkey > wg_privatekey && wg pubkey < wg_privatekey > wg_publickey
## conf - empty
if [ ! -f wg_conf ]; then
cat<<EOF > wg_conf
       [Interface]
       ListenPort = 10099
EOF
fi 

ip link del dev wg0 2>/dev/null || true
ip link add dev wg0 type wireguard

wg set wg0 private-key /home/freifunk/wg_privatekey
wg addconf wg0 wg_conf
ip addr add fe80::$(cat /sys/class/net/eth0/address|awk 'BEGIN{FS=":"}{print $1$2":"$3$4":"$5$6}')/64 dev wg0
ip addr add fdf1::$(cat /sys/class/net/eth0/address|awk 'BEGIN{FS=":"}{print $1$2":"$3$4":"$5$6}')/64 dev wg0
# <me> peer <the other>                                 
ip address add 192.168.99.1/24 dev wg0
ip link set up dev wg0

# make all wg if as gretap
/home/freifunk/gretap_up 

exit 0

gretap_up

(nötig wenn man im livebetrieb nicht keys hinzufügt, also nach reboot bspw.)

#!/bin/bash
#set -x

#legacy v4
SERVERIPV4=192.168.99.1
# fdf1::16:3e75:72af
localip=fdf1::$(cat /sys/class/net/eth0/address|awk 'BEGIN{FS=":"}{print $1$2":"$3$4":"$5$6}')

#sleep 1
/sbin/ifconfig bat0 up
/usr/local/sbin/batctl if add eth1
# ensure this ipv6 on bat0 and start mini_http for speedtest
# randomfiles
ip -6 addr add fdf0:9bb:7814:a630:1c61:19ff:fefd:3ed2/64 dev bat0
/usr/sbin/mini_httpd -d /home/freifunk/http/ -p 80

# try to automate
for ip in $(wg|grep "allowed ips"|cut -d":" -f2- |cut -d"/" -f1|tr -d " "); do
        echo $ip |grep -q -v fdf1 && \
                ip link add gre$(echo -n $ip|cut -d"." -f3-4) type gretap remote $ip local $SERVERIPV4 && \
                /sbin/ifconfig gre$(echo -n $ip|cut -d"." -f3-4) up && sleep 0.5 && \
                /usr/local/sbin/batctl if add gre$(echo -n $ip|cut -d"." -f3-4)
        echo $ip |grep -q fdf1 && \
                ip link add G$(echo -n $ip|grep -o fdf1[a-f0-9:]*|cut -d ":" -f 3-|tr -d ":") type ip6gretap local $localip remote $(echo -n $ip|grep -o fdf1[a-f0-9:]*) dev wg0 && \
                /sbin/ifconfig G$(echo -n $ip|grep -o fdf1[a-f0-9:]*|cut -d ":" -f 3-|tr -d ":") up && sleep 0.5 && \
                /usr/local/sbin/batctl if add G$(echo -n $ip|grep -o fdf1[a-f0-9:]*|cut -d ":" -f 3-|tr -d ":")
        # sleep 0.5
done

peer add im livebetrieb

#!/bin/bash

# fdf1::16:3e75:72af
localip=fdf1::$(cat /sys/class/net/eth0/address|awk 'BEGIN{FS=":"}{print $1$2":"$3$4":"$5$6}')

# we want 
# check <key> <ip>

## some easy check
# we want two arguments
[ $# != 2 ] && exit 89
# check length of key
[ ${#1} != 44 ] && exit 88
# legacy poor man ipv4 check
# [[ ! $2 =~ ^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$ ]] && exit 87
# check if ip already in wg0
wg |grep ip |grep -q "$2"
if [ $? -eq 0 ]; then
        wg |grep ip |sort
        echo ip already found - see list above
else
# write in conf
cat<< EOF >> wg_conf
[Peer]
PublicKey = $1
AllowedIPs = $2/128
EOF
fi

# live add peer to wg
wg set wg0 peer $1 allowed-ips $2/128
# add gretap
# hack us a number based on mac like Gaabbccddee
gimmegre=$(echo $2|cut -d":" -f2- |tr -d ":")
ip link add G$gimmegre type ip6gretap remote $2 local $localip ttl 255
ifconfig G$gimmegre up
# add to batctl
batctl if add G$gimmegre

#15

Hi Fuzzle,

großartig was du da machst, da möchte ich demnächst auch mit rumspielen, denke dass das wenn wir es robust haben viel besser als fastd ist.

Einen Gedanken habe ich noch, aber noch nicht praktisch ausprobiert:

Soweit ich weiss kann VXLAN im vgl. zu GRETAP auf einem Interface mit mehreren Peers sprechen, so dass ein Overlay-Netzwerk aus beliebig vielen Peers automatisch über Multicast gemanaget werden kann.

Man kann aber auch die Forwarding-DB von VXLAN manuell bearbeiten, also statisch eintragen, welche L2-Peers (MAC-Adressen) über welche IP erreichbar sind:

cumulus@switch1:~$ sudo bridge fdb add <mac addr> dev <device> dst <ip addr> vni <vni> port <port> via <device>

Howto: https://docs.cumulusnetworks.com/display/CL22/Configuring+a+VXLAN+without+a+Controller

Damit müsste es doch ggf. möglich sein, anstatt für jeden Peer ein Gretap-Interface anzulegen ein einziges VXLAN-Interface anzulegen und beim anlegen eines Peers nur einen Eintrag in die FDB vorzunehmen. Somit hätte man für beliebig viele Peers nur ein WG und ein VXLAN Interface.

Edit: Offizielle Doku: https://www.kernel.org/doc/Documentation/networking/vxlan.txt


#16

@markusl, klingt extrem spannend und kannte ich vorher nicht. kurz nachgesehen und festgestellt das gre+gre6 zumindest mal in etwa gleich Groß sind, und ich vermute auch ähnliche Dependencies haben.
wäre spannend das im direkten Vergleich zu haben, für den Plasterouter ändert sich denk ich nix, spannend wirds am Server
und ob ich das so einfach in bat0 einhängen kann.
das würde dann mehrere “probleme” lösen, bspw die vielen gretunnel und das einhergehende batman-iface Limit am Server.
Der direkte Vergleich ist dann noch spannend - l2tp war bspw. 10-20% langsamer (auf den plastekisten)
vielleicht möchte @adorfer oder co das ja auch testen : vergleichende Geschwindigkeit von Plaste auf Server unterschiedlicher Protokolle innerhalb eines Wireguard tunnels.

wenn du hilfe brauchst sag bescheid - ich weis nicht wie stark ich dazu komme die Tage,
unter http://openfreiburg.de/freifunk/firmware sind auch die kmod für 3.18.29 3.18.36 3.18.44 oder lede 4.44.36 zu finden, falls es daran mangeln sollt.

letztendlich ist ein Austausch gre > vxlan recht trivial, da es scheinbar equivalent zu gre aufgerufen wird. (also ändern des package und der scripte)

edit erste Test deuten darauf hin das man das nötige MAC festtackern bei bridge fdb add nicht mit v6 machen kann.

ip link add vxlan0 type vxlan id 42 local fdf1::16:3e75:72af dstport 4789 nolearning
bridge fdb add to 7A:33:1F:92:08:61 dst fdf1::ec08:6b56:cf84 dev vxlan0
# vis versa auf dem Knoten, dort gibt es schonmal dank openwrt busybox kein "bridge"

jedenfalls sagt er mir bei der bridge des Server,
RTNETLINK answers: Address family not supported by protocol


#17

Warum erwägt Du überhaupt noch (womöglich dynamisch) Tunnel auf ein batman-interface/eine batbridge einzuhängen?

Wir hatten doch nun schon geklärt, dass das nicht nur wegen eines Zahlenlimits, sondern auch wegen der Stabilität dringend zu vermeiden ist.


#18

l2tp macht nix anderes, nur das das nicht in nem extra tunnel steckt und das die dort nen evtl problematischen umweg über ne bridge machen … aber das - in diesem thread - ist dann wieder out of scope.
konkret ist die schlechte idee mit den vielen if auf batman von mir bisher beobachtet und auch nachgelesen nur bei solchen Setup die den umweg über eine bridge gehen. Ich finde die Probleme hier so nicht wieder, ich weis nich warum du das hier wieder von der Seite einwirfst - und das dachte ich, hatte ich schonmal geklärt. (soviel zu “wir hatten doch geklärt” gerüchteküche)
(und als erinnerung ist fastd eben ein solcher tunnel der in batman eingehangen wird…)


#19

Der Umweg ist nicht problematisch sondern notwendig. Ab einer gewissen Anzahl Interfaces in bat0 gibt es Kernel Panics, Freezes und anderes seltsames Verhalten sobald man Interfaces ändert (z.b. ein Client der die Verbindung trennt).
Ich glaube du verstehst die zu Grunde liegenden Mechanismen nicht gut genug um das Problem zu sehen.

Und ja Fastd macht das genau so wie L2TP, es ist nur ein Interface was in bat0 hängt.
Wir simulieren bei l2tp dieses Verhalten mit einer Bridge auf der Port-Isolation aktiviert ist damit eben nicht dieser Bug auftritt. Hier übernimmt dann Batman das Verteilen der Frames, daher ist die Port-Isolation auch wichtig da sonst jedes Frame auch noch mal von der Bridge repliziert wird.


#20

nicht ganz on-topic : im Moment testet Mullvad wireguard Tunnel, wer also einen Exit zum Testen mit Wireguard aufsetzen will - der möchte diese Mail hier lesen :
https://lists.zx2c4.com/pipermail/wireguard/2017-February/001076.html

We're doing this so that people might try Wireguard more easily, as
well as for us so that we can learn. We're supporting it on a purely
experimental basis, so no guarantees on uptime or anything. Sometime
soon we'll install a 10 Gbit card to see where things break first.
Enjoy :)