Kannst du vielleicht nochmal kurz die Fakten zusammen fassen:
Gruß
Tarnatos
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 ).
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
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
# 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
Load average: 0.01, 0.00, 0.00 TX packets 80872676 bytes 43983093228 (40.9 GiB) 126Error - can't write to file '/sys/class/net/gre127/batman_adv/mesh_iface': Cannot allocate memory
[113990.684849] ------------[ cut here ]------------
[113990.684861] WARNING: CPU: 0 PID: 12430 at /build/linux-lIgGMF/linux-4.8.11/mm/slab_common.c:861 kmalloc_slab+0x90/0xa0
[113990.684867] Modules linked in: dm_mod ip_gre ip_tunnel gre xt_hashlimit wireguard(OE) ip6_udp_tunnel udp_tunnel intel_rapl x86_pkg_temp_thermal coretemp crct10dif_pclmul evdev crc32_pclmul pcspkr ghash_clmulni_intel batman_adv(OE) libcrc32c ip_tabl
es x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache crc32c_intel aesni_intel xen_netfront xen_blkfront aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd
[113990.684907] CPU: 0 PID: 12430 Comm: batctl Tainted: G W OE 4.8.0-2-amd64 #1 Debian 4.8.11-1
[113990.684914] 0000000000000200 0000000052b690a8 ffffffff813269f5 0000000000000000
[113990.684921] 0000000000000000 ffffffff8107c16e 0000000002080020 fffffffffffffc00
[113990.684929] ffffffffc017a804 fffffffffffffc00 ffffffffffffff80 fffffffffffffbf8
[113990.684936] Call Trace:
[113990.684942] [<ffffffff813269f5>] ? dump_stack+0x5c/0x77
[113990.684947] [<ffffffff8107c16e>] ? __warn+0xbe/0xe0
[113990.684955] [<ffffffffc017a804>] ? batadv_orig_hash_add_if+0x94/0x140 [batman_adv]
[113990.684961] [<ffffffff811a7b10>] ? kmalloc_slab+0x90/0xa0
[113990.684966] [<ffffffff811e08c5>] ? __kmalloc+0x25/0x580
[113990.684971] [<ffffffff815ef9d7>] ? _raw_spin_lock_irqsave+0x17/0x39
[113990.684977] [<ffffffff81432c11>] ? _crng_backtrack_protect+0x31/0x70
[113990.684981] [<ffffffff811e0ebc>] ? kmem_cache_alloc_trace+0x9c/0x540
[113990.684986] [<ffffffff814340b7>] ? get_random_bytes+0xe7/0x1c0
[113990.684991] [<ffffffffc017a804>] ? batadv_orig_hash_add_if+0x94/0x140 [batman_adv]
[113990.684999] [<ffffffffc01779ac>] ? batadv_hardif_enable_interface+0x1cc/0x2e0 [batman_adv]
[113990.685007] [<ffffffffc017f2c2>] ? batadv_store_mesh_iface+0xb2/0x150 [batman_adv]
[113990.685013] [<ffffffff8127fa98>] ? kernfs_fop_write+0x118/0x1a0
[113990.685018] [<ffffffff81202303>] ? vfs_write+0xb3/0x1a0
[113990.685022] [<ffffffff812036e2>] ? SyS_write+0x52/0xc0
[113990.685039] [<ffffffff815efa76>] ? system_call_fast_compare_end+0xc/0x96
[113990.685044] ---[ end trace 3e82ace6f98e8470 ]---
[113990.684849] ------------[ cut here ]------------
[113990.684861] WARNING: CPU: 0 PID: 12430 at /build/linux-lIgGMF/linux-4.8.11/mm/slab_common.c:861 kmalloc_slab+0x90/0xa0
[113990.684867] Modules linked in: dm_mod ip_gre ip_tunnel gre xt_hashlimit wireguard(OE) ip6_udp_tunnel udp_tunnel intel_rapl x86_pkg_temp_thermal coretemp crct10dif_pclmul evdev crc32_pclmul pcspkr ghash_clmulni_intel batman_adv(OE) libcrc32c ip_tabl
es x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache crc32c_intel aesni_intel xen_netfront xen_blkfront aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd
[113990.684907] CPU: 0 PID: 12430 Comm: batctl Tainted: G W OE 4.8.0-2-amd64 #1 Debian 4.8.11-1
[113990.684914] 0000000000000200 0000000052b690a8 ffffffff813269f5 0000000000000000
[113990.684921] 0000000000000000 ffffffff8107c16e 0000000002080020 fffffffffffffc00
[113990.684929] ffffffffc017a804 fffffffffffffc00 ffffffffffffff80 fffffffffffffbf8
[113990.684936] Call Trace:
[113990.684942] [<ffffffff813269f5>] ? dump_stack+0x5c/0x77
[113990.684947] [<ffffffff8107c16e>] ? __warn+0xbe/0xe0
[113990.684955] [<ffffffffc017a804>] ? batadv_orig_hash_add_if+0x94/0x140 [batman_adv]
[113990.684961] [<ffffffff811a7b10>] ? kmalloc_slab+0x90/0xa0
[113990.684966] [<ffffffff811e08c5>] ? __kmalloc+0x25/0x580
[113990.684971] [<ffffffff815ef9d7>] ? _raw_spin_lock_irqsave+0x17/0x39
[113990.684977] [<ffffffff81432c11>] ? _crng_backtrack_protect+0x31/0x70
[113990.684981] [<ffffffff811e0ebc>] ? kmem_cache_alloc_trace+0x9c/0x540
[113990.684986] [<ffffffff814340b7>] ? get_random_bytes+0xe7/0x1c0
[113990.684991] [<ffffffffc017a804>] ? batadv_orig_hash_add_if+0x94/0x140 [batman_adv]
[113990.684999] [<ffffffffc01779ac>] ? batadv_hardif_enable_interface+0x1cc/0x2e0 [batman_adv]
[113990.685007] [<ffffffffc017f2c2>] ? batadv_store_mesh_iface+0xb2/0x150 [batman_adv]
[113990.685013] [<ffffffff8127fa98>] ? kernfs_fop_write+0x118/0x1a0
[113990.685018] [<ffffffff81202303>] ? vfs_write+0xb3/0x1a0
[113990.685022] [<ffffffff812036e2>] ? SyS_write+0x52/0xc0
[113990.685039] [<ffffffff815efa76>] ? system_call_fast_compare_end+0xc/0x96
[113990.685044] ---[ end trace 3e82ace6f98e8470 ]---
Error - can't write to file '/sys/class/net/gre127/batman_adv/mesh_iface': Cannot allocate memory
load average: 0.01, 0.00, 0.00 TX packets 80874265 bytes 43983761422 (40.9 GiB) 127Error - can't write to file '/sys/class/net/gre128/batman_adv/mesh_iface': Cannot allocate memory
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.)
Wie viele Threads zu Wireguard möchtest du denn noch eröffnen?
https://forum.freifunk.net/t/wireguard-0-0-20161230-mit-linux-3-18-kernel-und-damit-gluon-v2016-2-2/14122
Das passt doch eigentlich alles in diesen:
@Handle : nö, dann wirds mega unübersichtlich und ich denk ich teil meine Erkenntnisse lieber, dann haben auch andere was davon - in diesem Fall (dieser thread) hätt ich das „(wireguard)“ auch weglassen können - nur das dafür eben dieser Test durchgeführt wurde.
genauer - der erste thread ist nicht von mir und diskutiert das generell, der andere baut mit lede und testet unter livebedingungen (generelle gedanken sind da latte) und der letzte baut mit aktuellem gluon (und chaos calmer) und geht konkreter in die Richtung ein eigenes Gluon Paket zu bauen um ähnlich fastd oder dem externen l2tp paket das direkt in die FW einbauen zu können.
aber das hätte auch ne PM getan, an mich - so gehts inhaltlich am Thema vorbei. 
@adorfer, wenn du eine bessere Kategorie hast , bitte - nur zu.
Und ja, das ist ein Test, dass das nicht funktioniert, die Frage konnten viele Menschen so nur mit hmmja, ich glaube … beantworten, daher hab ich ne vm angeworfen, die ans backend gehangen, ein paar reale knoten drangehangen mit Wireguard/gretap/batv14 und dann mal noch gekuckt … was geht denn da so - wenns viel viel viel mehr werden.
Das dynamische Einhängen generell ist kein Problem, damit hatten wir noch nie probleme - dafür ist das da.
und @adorfer, btw du hattest mich nach „überschaubaren“ aufgaben gefragt … dies sind 2 davon https://forum.freifunk.net/t/wireguard-0-0-20161230-mit-linux-3-18-kernel-und-damit-gluon-v2016-2-2/14122/4
Nunja, hier geht es um:
Was sollen wir denn hier begreifen? Dass fuzzle etwas versucht, was auch mit l2tp und prinzipell auch in Multi-batdomain-Servern ein Problem ist, auch mit neueren Batman-Versionen?
Nunja… dann hast Du schlicht Glück gehabt.
Das Standard-Tunneldigger-Setup schaltet da nicht aus reiner Gaudi eine Bridge dazwischen.
Aber wie gesagt, Du wirst Deine Gründe haben.
und da du das alles nicht nur andeuten magst, kannst du mir fundiert auch die l2tp probleme genauer mal verlinken und wo das diskutiert wird. Dann hätt ich (und andere) da auch mehr von, und „lernen“ so „häppchenweise“.
(und weiterhin, es steht dir frei die kategorie zu ändern, das ist in der regel erfolgreicher als mich zu belehren und (*verzeih) doof von der Seite zu kommen - und alles so derb ins OT zu schieben)
lese einfach die nächsten paar Beiträge ab diesem Posting von @Cyrusfox
Die Lösung ist die gleiche wie beim Tunneldigger oder für Multidomain-VMs: vswitch, also bridge anlegen!
@CyrusFox @adorfer … liest sich so als ob neben anderen Problemen dort auch das „Limit“ von 127 ein Problem sein könnte. Genauer steht das da auch nicht, eher sogar ein paar sehr unterschiedliche Fehlerbilder (im zusammenhang mit l2tp und vor allem Batman)
Wie auch immer, du schlägst vor also 200 If in eine Bridge zu legen und die Bridge in batman einzuhängen. Ich gehe dann davon aus, dass die Bridge dann keinen Traffic weiter zwischen den ganzen Endpunkten hin und herschiebt, ist dem so? Ich dachte sämtlicher Traffic auf einer Bridge ist für sämtliche IF in der Bridge transparent.
… das verwirrt mich jetzt irgendwo, gradeinfach zu spät
Moin,
ich hab das Thema mal in Technik verschoben. Finde es dort besser aufgehoben.
Wir nutzen auch eine Bridge um unsere ganzen L2TP-Interfaces zu bündeln. Batman 15+ legt sich in der Tat gerne mal auf die Nase, wenn man Interfaces rausnimmt. Wie du schreibst, einhängen ist kein Problem. Beim Entfernen besteht ein gewisses Risiko für eine Kernelpanik und das hatten wir dank der DSL-Zwangstrennungen dann so jeden zweiten bis dritten Tag.
Damit die Knoten nicht untereinander kommunizieren, haben wir folgende Restriktion auf die Netzwerkbrücke gelegt:
post-up ebtables -A FORWARD --logical-in $IFACE -j DROP
Das läuft bis etwa 400 Verbindungen ganz stabil. Danach stößt das System an seine Grenzen und trotz relativ niedrigem Durchsatz auf dem physikalischen Interface, bekommt der einzelne Knoten nur noch tröpfchenweise Pakete. Da scheint es eine Ineffizienz zu geben, die nicht richtig skaliert. Ob es am Tunneldigger, am L2TP im Kernel oder an dieser Brücke oder einfach am Batman liegt, wissen wir nicht und haben auch nicht wirklich eine Idee, wie man das eingrenzen könnte.
Grüße
Matthias
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
/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
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“.
irgendwie is das hier verloren gegangen, entweder ich hab mich „verklickt“, oder jemand anders, oder hier is nen serious bug - however, sehr guter Überblick :
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 Presentations - WireGuard
(slightly older ones [CB16] WireGuard: Next Generation Abuse-Resistant Kernel Network Tunnelby Jason Donenfeld - YouTube )
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.
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
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 openfreiburg.de
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
},
},
},
GLUON_SITE_FEEDS='blablablaanderepakete meshwireguard'
PACKAGES_MESHWIREGUARD_REPO=https://github.com/viisauksena/gluon-mesh-wireguard.git
PACKAGES_MESHWIREGUARD_COMMIT=cb77788ee49fe5b81789d01eed49aa30e971dd8e
PACKAGES_MESHWIREGUARD_BRANCH=master
wireguard-tools \
ip-full \
gluon-mesh-wireguard kmod-ipt-hashlimit kmod-gre6 kmod-wireguard kmod-udptunnel6 kmod-udptunnel4 \
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
Gibt es eventuell auch eine Anleitung, wie man den Supernode dafür baut?
@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>
(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
(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
#!/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
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
@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 openfreiburg.de 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
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.