Wireguard - technische Diskussion

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?

Inwiefern? WireGuard an sich ist »nett«, müßte rein technologisch ein paar Zyklen hinter reinem L2TP hängen. Aber WireGuard ist halt L3, wo das batman-adv-Setup L2 benötigt …

im Moment halt nur für babel nutzbar, aus dem Grund den wusel nennt. (und babel wiederum nur für IPv6 bisher)

VXLAN fällt vermutlich heraus, weil der source port der VXLAN Pakete anhand eines Hashes der Payload berechnet wird, also stark fluktuiert, was inbesondere mit NAT nicht gut funktionieren kann.

      -  Source Port:  It is recommended that the UDP source port number
         be calculated using a hash of fields from the inner packet --
         one example being a hash of the inner Ethernet frame's headers.
         This is to enable a level of entropy for the ECMP/load-
         balancing of the VM-to-VM traffic across the VXLAN overlay.
         When calculating the UDP source port number in this manner, it
         is RECOMMENDED that the value be in the dynamic/private port
         range 49152-65535 [RFC6335].

das verstehe ich nicht. was genau stört? wir machen doch nat erst hinter dem layer 2 im backbone. Weiter ist es möglich feste ports zu nutzen. weniger entropy sollte bei unscegal sein. batman routet ja

das NAT am Standard-Home-Internetanschluss meint er

ist der Thread noch aktuell ? ich hätte mal eine frage zu wireguard ich betreibe eine GL-net mango und nach dem 24 stunden autoreconnect stellt sich die verbindung nicht automtisch wieder her ich habe es schon mit dem wireguard_watchdog script versucht. muss ich den an dem server oder dem client aktivieren.

Der Reconnect muss von der Seite her angestoßen werden, die auch die Verbindung aufbauen kann. Bei einem klassichen „Server mit public-IPv4 vs Server hinter NAT/CGN ohne fixed address“ ist es der hinter dem NAT der den ConnectionLoss (oder beständig failendes Handshake z.B. nach Source-IP-Änderung im CGN) a) bemerken und b) ein reconnect einläuten muss.

Also vom client? :joy:

Ich verstehe das Emoji in diesem Kontext nicht.
Mag aber sein, dass Du auf den running-gag der notorischer Falschnutzung der „Client-Server“-Terminologie bei serverlosen Architekturen anspielst.
Daher: Nein
Sondern das was ich geschrieben habe: Es muss die Seite die Verbindung aufbauen, die 1) das ausbleibende erfolgreiche Handshake erkennt (turning on heartbeat: helps) und 2) dazu auch in der Lage ist, für den Fall, dass das Netzwerk nicht symetrisch ist.
(Fals ich die Ironie eines Trollversuches nicht verstanden haben sollte: Sorry.)

Es sollte immer der neu verbinden, der vom Anderen alle Daten hat. Also vermutlich in deinem Fall das was du „Client“ nennst, denn dieser hat vermutlich die wechselnde IP und der Server die statische.

Wie das aussehen kann in Gluon und mit 2000 Nodes kannst du in der Freifunk München Firmware sehen:
https://github.com/freifunkMUC/community-packages/blob/gluon-mesh-vpn-wireguard-vxlan/gluon-mesh-vpn-wireguard-vxlan/files/lib/gluon/gluon-mesh-wireguard-vxlan/checkuplink#L74

Rein theoretisch sollten nach der Neuverbindung Pakete mit der neuen öffentlichen Adresse bei der Gegenstelle ankommen und automagisch akzeptiert werden (da mit bekanntem Key und von korrekter innerer IP). Zumindest, wenn von der Seite hinter der dynamischen IP regelmäßig Daten in Richtung der Seite mit fester IP gesendet werden. Andersherum ist nach IP-Wechsel kein Datenfluß mehr möglich, bis seitens der dynamischen Seite die Verbindung erneut hergestellt wurde.