es scheint stabil zu laufen, da man aber nicht schneller ist als mit fastd (im Vergleich zu Wireguard plus l2tpv3) und fastd im Moment auch das kleinere Paket ist bleiben wir dabei.
von der crypto tun die beiden sich nichts.
wireguard frisst den ganzen Memory auf wenn man den mit udp in großem Maß beschiesst und der OOM Killer schiesst dann wahllos Programme ab. (auf den kleinen 32MB kisten, auf den Servern haben wir das nicht beobachtet, aber das liegt wohl daran das der irgendwas um die 90 Mb mximal buffern würde … nur ne Vermutung basierend auf Infos aus Wireguard Dev Liste )
Für die kleinen Geräte - kann man machen, hat aber keinen Vorteil. Bzw. wenn man Layer 3 Routing macht und eben kein Riesenbatman Layer2 Switch (sondern nur lokal Batman hat) dann ist das vielleicht ne saubere alternative.
für die Supernode < > Supernode geschichte sind wir noch dran, denn da ist die Performance sehr gut. Wir denken das wir Tinc damit austauschen werden.
nach dem neuen Wireguard mit Ankündigung von Speicher Alignment auf den kleinen Routerkisten … hab ich neu gebaut und getetestet.
Ich verstehs nicht ganz, aber wir bekommen in die eine Richtung 30Mbit und in die andere etwa 11-14 Mbit. Hatten gestern keine Lust das weiter zu debuggen - aber an sich sehr Bemerkenswert.
getestet 842v3 mit wireguard und gretap und batv14,
tests mit lede und 4.4 Kernel
irgendwas mach ich da noch nicht so ganz richtig, hier vergleichsergebnisse unter live test bedingungen. Freu mich über anregungen, nachmacher*innen und so. edit: backend lahmte … siehe Post3
# wg genkey > wg_privatekey
# wg pubkey < wg_privatekey > wg_publickey
# cat wg.sh
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 /home/freifunk/wg_conf
ip addr add fe80::$(cat /sys/class/net/eth0/address)/64 dev wg0
ip addr add fdf1::$(cat /sys/class/net/eth0/address)/64 dev wg0
# <me> peer <the other>
ip address add 192.168.99.1/24 dev wg0
ip link set up dev wg0
Wireguard - peer - 842v3
# wg genkey > wg_privatekey
# wg pubkey < wg_privatekey > wg_publickey
# cat wg.sh
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 /home/freifunk/wg_conf
ip addr add fe80::$(cat /sys/class/net/eth0/address)/64 dev wg0
ip addr add fdf1::$(cat /sys/class/net/eth0/address)/64 dev wg0
# <me> peer <the other>
ip address add 192.168.99.2/32 peer 192.168.99.1/32 dev wg0
ip link set up dev wg0
# it seems we need initializer like this
ping 192.168.99.1 -c2
Setup gretap tunnel
gretap: Server
# these are the ips from wg0 if
ip link add gre1 type gretap remote 192.168.99.2 local 192.168.99.1
sleep 2
ip link set up dev gre1
gretap Peer 842v3
# these are the ips from wg0 if
ip link add gre1 type gretap remote 192.168.99.1 local 192.168.99.2
sleep 2
ip link set up dev gre1
time -v wget http://192.168.99.1:80/random100M -O /dev/null
Downloading 'http://192.168.99.1:80/random100M'
Connecting to 192.168.99.1:80
Writing to '/dev/null'
/dev/null 100% |*******************************| 100M 0:00:00 ETA
Download completed (104857600 bytes)
Command being timed: "wget http://192.168.99.1:80/random100M -O /dev/null"
User time (seconds): 2.45
System time (seconds): 5.31
Percent of CPU this job got: 26%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 29.49s
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2912
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 44
Voluntary context switches: 4088
Involuntary context switches: 256
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
connect backbone
### fw server via batman - and gretap (lame backend)
fw server via batman - and gretap
# time -v wget http://[fdf0:9bb:7814:a630:1c61:19ff:fefd:3ed2]/random100M -O /dev/null
Downloading 'http://[fdf0:9bb:7814:a630:1c61:19ff:fefd:3ed2]/random100M'
Connecting to fdf0:9bb:7814:a630:1c61:19ff:fefd:3ed2:80
Writing to '/dev/null'
/dev/null 100% |*******************************| 100M 0:00:00 ETA
Download completed (104857600 bytes)
Command being timed: "wget http://[fdf0:9bb:7814:a630:1c61:19ff:fefd:3ed2]/random100M -O /dev/null"
User time (seconds): 2.51
System time (seconds): 6.10
Percent of CPU this job got: 15%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 53.87s
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2912
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 45
Voluntary context switches: 4637
Involuntary context switches: 229
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
compare fastd (lede build)
just as comparison
## time -v wget http://[fdf0:9bb:7814:a630::7]/random100M -O /dev/null
Downloading 'http://[fdf0:9bb:7814:a630::7]/random100M'
Connecting to fdf0:9bb:7814:a630::7:80
Writing to '/dev/null'
/dev/null 100% |*******************************| 100M 0:00:00 ETA
Download completed (104857600 bytes)
Command being timed: "wget http://[fdf0:9bb:7814:a630::7]/random100M -O /dev/null"
User time (seconds): 5.47
System time (seconds): 9.78
Percent of CPU this job got: 9%
Elapsed (wall clock) time (h:mm:ss or m:ss): 2m 39.03s
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2512
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 46
Voluntary context switches: 76215
Involuntary context switches: 55
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
jetzt hatte ich mich selber genatzt.
unser backend lahmt an dieser speziellen Stelle zwischen den Servern, leg ich mir die 100Mbyte Random Testdatei direkt auf den Uplinkserver mess ich folgendes.
(immer mehrere Messungen , hier ein mittleres Ergebnis)
(00:26:03) cccfr_fuzzle: yay ... irgendwas stimmt mit der backendanbindung des servers nicht :
(00:26:03) cccfr_fuzzle: ipv4 - nur wg - ca 30 sek.
(00:26:03) cccfr_fuzzle: ipv6 - wg+gre - ca 54 sek.
...
(00:27:00) cccfr_fuzzle: 54 sek sind etwa 15 Mbit (unter livebbedingungen (wie ich die gerade immer nenne))
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.
# 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
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) openfreiburg.de
(vorsicht da u.a emergency script (mit reboot wenn keine batgw für 10 min) darin und ssh keys von uns aus freiburg)
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 Protocol & Cryptography - WireGuard
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 ).
#!/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
FYI … 510 Gretap tunnel aufgemacht und in batman-adv eingehangen (unbenutzt soweit, wobei batman broadcast purzelt da schon real rein) - bis zum 127. soweit kein problem. - batv14
ab 127. dann Error - can’t write to file ‚/sys/class/net/gre128/batman_adv/mesh_iface‘: Cannot allocate memory
Dies als Test
Script dazu
# add one if per 3 second and give output, also monitor dmesg
dmesg -w &
for i in `seq 1 255`; do
# one interface
ip link add gre$i type gretap local 192.168.99.1 remote 192.168.3.$i ttl 255 dev wg0
ip link set up dev gre$i
batctl if add gre$i
# another inf
ip link add grex$i type gretap local 192.168.99.1 remote 192.168.4.$i ttl 255 dev wg0
ip link set up dev grex$i
batctl if add grex$i
echo -n $(uptime|cut -d"," -f4-) $(ifconfig wg0|grep TX\ p) $i
sleep 3
done
Ich verstehe nicht, was dieser Artikel erklärt. Für mich klingt das eher nach etwas, was gerade (so) nicht funktioniert
Oder warum steht der im Erklärbär?
Zumindest liest sich das für mich eher nach einer Frage.
(Und ohne dem Threadstarter direkt widersprechen zu wollen, aber so würde ich das nicht tun. Allein der Versuch, dynamisch Interfaces im laufenden Betrieb in Batman ein- und aushängen zu wollen erscheint mir sehr mutig, zumindest ist es meine Erfahrung, dass das der Stabilität eines Systems mehr als abträglich ist.
Vielleicht verstehe ich aber auch den Ansatz „Lernen durch abschreckendes Beispiel“ (?!?) nicht.)