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:
1 „Gefällt mir“
@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
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“.
5 „Gefällt mir“
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 Presentations - WireGuard
(slightly older ones [CB16] WireGuard: Next Generation Abuse-Resistant Kernel Network Tunnelby Jason Donenfeld - YouTube )
1 „Gefällt mir“
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 openfreiburg.de
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
4 „Gefällt mir“
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>
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
1 „Gefällt mir“
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
2 „Gefällt mir“
@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.
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…)
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.
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 :)
Gibt es hier irgendwelche neuen Erkenntnisse, oder ist das Thema eingeschlafen?