Wireguard selbst nicht aber mit dem Commit:
Probiert er bei jedem Connect ne andere Adresse vom Gateway.
Stimmt, war ich nur zu ungeduldig, über die Zeit tauchte auch die v4-IP auf; dann muß ich wohl mal die Serverseite angehen 
Ich finde aber nirgends, wie Wireguards Pakete an die Routingtable 1 gebunden werden, um über einen v6-WAN-Zugang rauszugehen? Sofern ich das richtig verstehe, muß v6-Kommunikation über’s WAN die Routingtabelle 1 nutzen, sonst geht’s über’s Mesh. Wireguard als Kernelmodul kann man aber wohl nicht mit libpacketmark beackern?
BTW: Ich wollte es auch mit gluon-ffmuc-v2020.3.1~exp12-x86-64-sysupgrade.img.gz ausprobieren, aber leider kommt nach <meta http-equiv="refresh" content="0; URL=/cgi-bin/config" /> ein 404 Not Found für /cgi-bin/config, sprich Configmode tut nicht. Ist das bekannt?
Laut Wireguard Doku kann man für ein WG Interface fwmark setzen.
1 „Gefällt mir“
Danke, das hatte ich übersehen.
Damit wir bald weiter machen können an dem Projekt und unsere neuen Gateways nicht mehr mit ifupdown und 200 Hacks aufsetzen müssen. Habe ich mal angefangen BATMAN Support in systemd-networkd einzubauen.
Wenn ihr C Kenntnisse habt, wäre es super wenn ihr auch was beitragt :).
4 „Gefällt mir“
@mpw Nein, das wollen wir nicht einsetzen. Da wir dann wieder eine nicht system eigene Lösung einsetzen. Das war bei ifupdown2 schon gruselig und hat immer wieder zu Ausfällen geführt.
systemd-networkd wird offiziell supported von Debian und ist kein Thirdparty Package bekommt dadurch auch Security Updates etc…
Vielleicht kommt das für ifupdown-ng auch irgendwann aber im Moment halt noch nicht. Und wir wollen nicht nochmal so ein Disaster wie ifupdown2.
Falls du den Sourcecode als Anlehnung verwenden meinst, da wird batctl gewrapped im Moment und kein Netlink gesprochen.
Die systemd-networkd Implementierung benötigt kein batctl um zu funktionieren nur das Kernelmodule batman-adv.
Ansonsten schönes Projekt.
@MoepMan, @hexa und ich haben heute ein renaming des Wireguard Brokers und Workers, mit Absegnung des Wireguard Machers, beschlossen.
Absofort heißt das Projekt wgkex und die einzelnen Komponenten wgkex-broker und wgex-worker:
Außerdem hat Moepman ordentlich losgelegt und einiges refactored :).
Des weiteren ging es auch mit systemd-networkd weiter.
https://github.com/systemd/systemd/pull/17252/commits/d77a3ad59df6f988bad75e9c35efcf31d788202e
Jetzt suchen wir nur noch jemand mit LUA Kenntnissen und Lust die/der sich am Nodeseitigen Setup beteiligen will :).
3 „Gefällt mir“
Das heißt aber auch, daß Eure Arbeit erst frühestens in Ubuntu-Next und Debian-Next sichtbar wird, konkret also nicht vor Ubuntu 22.04 LTS?
Es gibt ja die Debian Backports. Dort ist systemd momentan auch schon in der aktuellen Version 246 verfügbar für Buster. Wenn es also einen Release von systemd gibt, wird dieser sicherlich vergleichsweise zeitnah dort bereitstehen.
Aber klar, bis das in der normalen LTS Version von Debian und Ubuntu ist wird das noch etwas dauern. Das haben LTS Systeme so an sich.
1 „Gefällt mir“
Du brauchst systemd-networkd ja nicht zwingend für die Funktionalität ;). Kannst ja weiter ifupdown und co benutzen.
Das systemd-networkd Projekt entstand aus vielem Jammern auch hier im Forum dass Batadv damit nicht funktioniert. Und der Not dass ifupdown2 wireguard sowie vxlan über ipv6 nicht richtig kann. Und nachdem systemd-networkd alles kann bis auf batadv, war es logisch den Support einzubauen. Eigentlich ist das aber ein extra Projekt vielleicht verdient es eigentlich seinen eigenen Thread.
Und wie @TomH sagt wird es sicher was in Backports geben.
2 „Gefällt mir“
Ah, das freut mich zu lesen. Der systemd-Kram macht so schon mit jeder neuen Version genug Probleme, sich Eigenheiten einer zukünftigen Version auf laufende Systeme zu holen, erscheint da nicht zielführend.
Bislang hat ifupdown gereicht, auch wenn, zugegeben, die generierten Dateien etwas von Kurzgeschichten haben.
Ich benutze systemd ausm Master auf meinem Fedora und das läuft eigentlich immer gut :). Nur mit Debian habe ich immer Probleme :/.
Wie gesagt, systemd-networkd ist nur eine Randerscheinung die im Zuge des Projektes „dringlicher“ wurde um eben nicht mehr diese „Kurzgeschichten“ an ifupdown scripts zu haben :). Aber wird sicherlich keine Dependency :). Die Hoffnung ist aber dass es so oder so vielen Communities hilft networkd nutzen zu können :).
Ich habe mich vor >4 Jahren von allem, was nicht LTS-äquivalent ist, verabschiedet, privat wie beruflich. Und LTS bedeutet, gerade auch wegen schmerzhaften Erfahrungen im systemd-Umfeld, das generell nur noch Sicherheitsupdates eingespielt werden und erst nach dem EOL über Upgrade oder Neudeployment unter ›oldstable‹ nachgedacht wird. Jessie war damals ein Höllenritt, 20.04 ist auch laufend für eine Überraschung gut. Mit RHEL/CentOS habe ich glücklicherweise seit 4+ Jahren nichts mehr zu tun 
Soll heißen: bitte auch den Weg beschreiben, damit man das unter Ubuntu 16.04/18.04/20.04 oder anderen älteren Distributionen – die eben noch nicht veraltet sind, 16.04 bekomt noch ein paar Monate prinzipiell Securityupdates – mit Bordmitteln nachbauen kann, danke.
Mal sehen wie wir Zeit dafür haben ;). Prinzipiell ist es batman, vxlan und wireguard Interfaces anlegen den Rest übernimmt wgkex.
Wir nehmen gerne Doku auf, werden aber in erster Linie Beispiele für von uns verwendete Systeme anlegen. Das Projekt frisst so schon Wochenende nach Wochenende, die Beispiele werden leicht verständlich sein und damit auch Nachbaubar.
Und wir sind online mit neuem Rechenzentrum und direkt Vorbereitung für Wireguard!
Das ist jetzt bereits mit systemd-networkd und BATMAN Integration!
Gleichzeitig ist aber auch noch fastd dabei, so dass wir keine alten Nodes mehr abhängen. Zwischen den Gateways wird auch nur noch per Wireguard und vxlan kommuniziert.
5 „Gefällt mir“
Das ist äußerst hervorragend, die Sachen direkt Upstream einzupflegen. Sauber und elegant. So wie es sein soll.
Das ist einer der Gründe weshalb ich seit fast 15 Jahren bei Fedora Contributor bin. Upstream first ist die Devise. So können auch viele andere noch von den Verbesserungen profitieren!
4 „Gefällt mir“
Vielen Dank für das Lob :). Upstream first, habe ich seit meiner ersten Arbeitsstelle im Kopf, weil es einfach vieles leichter macht und umso mehr mitmachen umso besser gepflegt ist das ganze Projekt :). Nur jammern dass was nicht geht kann jeder, aber dafür Sorgen dass es nichts mehr zu jammern gibt wenige.
2 „Gefällt mir“
Wir sind wieder einen Schritt weiter, wir haben nun einen Broker der die Wireguard Keys entgegen nimmt und per MQTT an die Gateways weitergibt. Diese programmieren dann per Netlink ihr Wireguard, VXLAN und Routen:
https://github.com/freifunkMUC/wgkex/pulls
1 „Gefällt mir“
Wir haben erfolgreich die ersten 76 Nodes auf Wireguard migriert inklusive Broker und Autoupdate 
.
1 „Gefällt mir“