Ja bitte.
Ich verstehe vor allem nicht, was eine „VPN-Lösung“ sein sollte. Mit so einem Begriff „xyz-Lösung“ verbinde ich eher eine Applikation im direkten Zugriff des Nutzenden.
Für mich klingt das eher nach einem möglichen weiteren Meshvpn-Protokoll.
Und was die Abgrenzung zum Tunneldigger anbelangt: Kann es denn IPv6 direkt nutzen?
ich hab dort mal eine Mail direkt hingeschrieben … mal sehen was / ob da wa zurück kommt.
somebody post a hint of your project in Freifunk Forum
(https://forum.freifunk.net/t/wireguard-als-zukuenftige-vpn-loesung/12858 )
There are many Communities that actually run l2tp or fastd for many
nodes2server tunnel. Maybe you know something about Freifunk and its
infrastructure.
However, what is my interest here:
do you know fastd ? do you know how fastd compares to wireguard?
on of the downsides of fastd is that it runs in userspace, not
kernelspace - so there is big overhead on network/crypto while switching
between kernel/userspace.
For example, in Freiburg we are using encrypted fastd tunnel to connect
to our gateway servers. Around 300 Nodes. And we are really interested
in more performant ways of encrypted tunnel connections even for small
nodes (like TP Link 841 - 4 MB Flash, 32 MB Ram, Openwrt) - there we reach
with salsa2012+umac something between 12 and 20 Mbit (only).
thanks for hints and suggestions,
fuzzle/ Freifunk Freiburg
https://www.wireguard.io/
http://fastd.readthedocs.io/en/v18/devel/protocol.html
http://gluon.readthedocs.io/en/v2016.1.5/
https://cccfr.de/git/viisauksena/firmware
https://forum.freifunk.net/t/wireguard-als-zukuenftige-vpn-loesung/12858
seh ich nicht so, bzw. ungetestet hoff ich das nicht so , wg macht ein interface auf, das sollte ich doch genauso in bat0 mit reinhängen können. und die Server/pubkey geschichte ist ja vergleichbar mit fastd.
# ip link add dev wg0 type wireguard von Quick Start - WireGuard
nötig scheint ein Kernel >4.1 zu sein, bei gluon und dem dortigen openwrt derivat ists grad noch 3.18.29 wenn ich das richtig sehe.
Wenn es nur Layer2 macht, dann wird man halt nach wie vor den Tunneldigger brauchen, um das Interface dort draufzuklemmen.
Belastbare Aussagen zur Performance konnte ich auf den ersten Blick nicht finden. „Schneller als OpenVPN“…
Warum gibt’s dazu keine Werte für exemplarische Platformen, wenn sie doch getestet haben?
Ich hoffe mal, es entpuppt sich nicht als Schlangenöl.
ne, kein schlangenöl, nur sehr sehr sehr junges projekt . du bist doch in der lage belastbare tests zu machen und zu liefern … die Einladung zum selber machen und ausprobieren …
(der vollständigkeit halber noch die Antwort auf die Mail)
Hi Jens,
I have read fastd, and I think it's a neat project. I thought it was
cool to see it using FHMQV-C; WireGuard is based on Noise, which in
turn was heavily influenced by the [F]HMQV family. Fastd is a lot more
complex than WireGuard, and does a lot more -- cipher agility, layer 2
-- things that WireGuard has deliberately left out. Fastd has also
been around longer, and they actually have a release >= 1.0 (18!),
whereas WireGuard is still in an unreleased experimental phase.
Generally fastd looks cool. I haven't audited their code thoroughly,
so I can't speak to the code quality, implementation security status,
or crypto particulars.
WireGuard will definitely be faster, by virtue of being in kernel
space and possibly other general performance improvements, and I think
you might benefit from the simplicity of WireGuard too. If you're
using OpenWRT, I think a package for there is in the works, and the
package maintainer will probably inform the list when it's ready. Keep
in mind that WireGuard is experimental, but if you would like to try
it out, I'd be very interested to learn your experience with it --
what worked, what didn't, the performance characteristics, and so
forth. We're a new project here, so feedback like that is very useful
for shaping our direction.
Keep me posted!
Jason
Nee, ist wohl nicht so. Laut Doku matcht der auf dem Interface IP (v4 und v6) Adressen auf angegebene Netmasken:
[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24
Damit können auf einem Interface mehrere Peers angesprochen werden, alle Pakete die mit einer Zieladresse aus dem Interface rausgeschickt werden, die eine der in AllowedIPs eingetragenen Netzmasken matchen werden mit dem Key des Peers verschlüsselt und dort hin geschickt, alle anderen Pakete werden verworfen.
Eingehend werden alle Pakete verworfen, die von einem Peer kommen aber als Quell-IP nicht in die Netzmaske(n) des Peers passen.
Heißt, es wird nur IP weitergeleitet.
Für Freifunk-Nodes mit L3-Routing müsste also jeder Peer ein eigenes Interface mit Netzmaske 0.0.0.0/0 bzw. ::/0 (oder eingeschränkt auf das Mesh-Prefix) bekommen, damit man belieibge Ziele die Babel oder OLSR announcen darüber routen kann.
Wenn die Tunnel vollautomatisch funktionieren sollen bräuchte man mit der jetzigen implementierung ein externes Key Exchange Protokoll, um den Tunnel auf dem Supernode auf Anforderung eines Nodes anzulegen, ähnlich wie Tunneldigger fúr L2TP. Der Autor von WireGuard hat eine ganz simple Demo in BASH mitgeliefert die das macht.
zum testen gibt es ja bereits openwrt lösungen, für die server sollte das bauen kein problem sein …
wer für gluon bauen will … dem kann der hinweis hier helfen
zum selber bauen …
at this moment i add manually openwrt/packages@35cb289
https://github.com/openwrt/packages/commit/35cb289
( just add directory and Makefile gluon/packages/openwrt/net/wireguard/Makefile and than build fw or/and modules )
und man sollte die Version noch pimpen
PKG_VERSION:=0.0.20160708.1
derzeitiges problem kernel >4.1 : #error „WireGuard requires Linux >= 4.1“
# aus dem make log
make[5]: Entering directory '/media/freifunk/firmware/gluon/packages/openwrt/net/wireguard'
rm -f /media/freifunk/firmware/gluon/build/ar71xx-generic/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/stamp/.wireguard_installed
/media/freifunk/firmware/gluon/build/ar71xx-generic/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/WireGuard-experimental-0.0.20160708/src/wireguard.h:11:2: error: #error "WireGuard requires Linux >= 4.1"
make[5]: Leaving directory '/media/freifunk/firmware/gluon/packages/openwrt/net/wireguard'
package/Makefile:191: recipe for target 'package/feeds/module_openwrt/net/wireguard/compile' failed
make[4]: *** [package/feeds/module_openwrt/net/wireguard/compile] Error 2
im moment geh ich davon aus, das erst der kernel in gluon auf 4.1++ gebracht werden muss, soweit ich das verstanden hatte, sollte das mit v2016.2 kommen
Wenn ich das Gluon-Issue richtig verstehe:
Dann hat Wireguard (als L3-Protokoll „nativ“ auf einem 841er netto 40MBit/s.
Man könnte dann also anfangen zu überlegen, ob man das „statt Tunneldigger“ benutzt, um L2TP da durchzuschleusen und L2TP „mit Verschlüsselung“ zu bekommen.
streiche anfangen zu überlegen , ersetze beginnen 
- also mal real Dinge bauen
40mbit aber nur ohne encryption, oder?
Ich denke dass Wireguard erst mit Babel zum Einsatz kommt. Inzwischen gibt es sogar einen Babel Push Request für Gluon:
@fuzzle das „blanko“ interpretiere ich jedenfalls so, dass die 40 MBit/s ohne Verschlüsselung gemessen wurden.
@Handle bitte diesen Thread auch lesen und dann interpretieren oder glauben - was soll das sein blanco?
@CyrusFox wireguard ist erstmal nen l3 tunnel … was man da dann mit macht - mal sehen, wir wollten probieren ob man damit fastd ersetzen kann, dazu braucht man on top l2tpv3 und dann wie bei fastd auch batman. Wenn man das netz so behalten will wie es ist.
@CyrusFox wireguard ist erstmal nen l3 tunnel … was man da dann mit macht - mal sehen, wir wollten probieren ob man damit fastd ersetzen kann, dazu braucht man on top l2tpv3 und dann wie bei fastd auch batman. Wenn man das netz so behalten will wie es ist.
Das wäre natürlich eine Möglichkeit, aber sinn machen tut das nicht. Da dann eher darauf hin arbeiten das Wireguard auch Layer2 Tunnel unterstützt. Tunnel in Tunneln ist generell keine gute Idee da man später mit einer MTU unter 1300 arbeiten muss da heute oft DS-Lite verwendet wird. Für Unitymedia nutzen wir schon eine MTU von 1364, davon 32 Bytes abgezogen für den Batman Header und man landet bei 1332.
IPv6 braucht mindestens 1280 Bytes, kleiner als das sollte man also nicht gehen. Wenn man Gretap im Wireguard Tunnel verwendet würde es gerade noch so passen mit 14 Bytes übrig. Mit L2TPv3 via UDP klappt es nicht ohne das aller IPv6 Traffic fragmentiert.
Hier mal eine kleine Übersicht:
Gretap:
20 bytes (IP-Header)
4 bytes (GRE-Header)
14 bytes (Ethernet header)
Gesamt: 38 bytes
L2TPv3 via UDP:
20 bytes (IP header)
8 bytes (UDP header)
4 bytes (L2TPv3 Session ID)
4 bytes (L2TPv3 Cookie)
4 bytes (L2TPv3 Pseudowire CE)
14 bytes (Ethernet)
Gesamt: 54 bytes
L2TPv3 via IP:
20 bytes (IP header)
4 bytes (L2TPv3 Session ID)
4 bytes (L2TPv3 Cookie)
4 bytes (L2TPv3 Pseudowire CE)
14 bytes (Ethernet)
Gesamt: 46 bytes
Du hast das doch selbst geschrieben im von @adorfer verlinkten Github-Issue:
es gibt neues zu berichten, unter anderem testet jason (wireguard dev) das nun selbst an einem 841 und wir sind einige weitere Schritte gekommen mit den MIPS oom Problemen, und bekommen im Moment blanko 40 Mbit mit wireguard durch die leitung.
@rubo77 kam auf das „ohne encryption“ vermutlich, weil man die bei fastd ja deaktivieren kann und man im Kontext von fastd wesentlich geringere Geschwindigkeiten bei aktivierter Verschlüsselung im Hinterkopf hat. Du schreibst dann, was Wireguard ist, aber nicht, ob der Test nun mit Verschlüsselung durchgeführt wurde oder ohne (ob man die bei Wireguard überhaupt deaktivieren kann, weiß man als jemand, der nicht in der Materie drin steckt, erst einmal nicht).
Vor dem Hintergrund ist mir nicht direkt klar gewesen, was du mit deinem
blanko 40 Mbit
ausdrücken wolltest.
Anstatt das kurz für jeden klarzustellen, kommst du in dem gleichen ruppigen Tonfall daher, mit dem du auch schon im verlinkten Github-Issue angeeckt bist und der Leser ist nach der Lektüre deines Beitrags genauso schlau wie vorher. Für sonderlich zielführend halte ich das nicht.
@handle ich weis ja nicht, will niemandem auf die Füße dappen - allerdings find ich komisch das dir nichtmal klar zu sein scheint was wireguard überhaupt ist. hier mal erster Satz wireguard.io Seite WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography - meine Kritik geht dahin das du scheinbar nicht gelesen hast was geschrieben wurde und dann glaubst/vermutest/whatever. Das du dir ein themenfremdes Anecken aus dem github-issue hier zu eigen machst um dein Argument zu stützen gibt dir auch nicht mehr recht. (dort ging um „Mißverständnisse“ welcher Durchsatz auf welchen Geräten erreicht werden kann mit der damaligen Version - unaligned Memmory, Mips32c)
Wie gesagt, ausser zu sagen mach deine Hausaufgaben - will ich niemanden auf die Füße dappen.
edit Das mein letzter nicht inhaltlicher comment dazu
Ich schließe daraus nun einfach mal, dass man bei wireguard die Verschlüsselung gar nicht deaktivieren kann.
Wenn das richtig ist, dann: WoW!!! Will haben!!! 
@fuzzle ich weiß nicht, warum du dich scheinbar schwer damit tust, thematisch weiterführend auf die Beiträge einzugehen und abermals das Äquivalent von „RTFM“ herunterbetest. Würde dir ein Zacken aus der Krone brechen, wenn du inhaltlich auf @rubo77 oder meinen Beitrag eingehst? Was WireGuard ist hat in groben Zügen hier glaube ich jeder verstanden. Hier ging es aber um eine kleine Detailfrage, die du mit ein paar Worten hättest beantworten können, was du aber immer noch nicht getan hast.
Mit deiner Art tust du aber genau das.
für inhaltliches und zum selbertesten … gestern kam ein neues Tag
https://git.zx2c4.com/WireGuard/tag/?h=experimental-0.0.20161116
den kann man ähnlich einbauen wie hier - dort ist noch 1110
https://github.com/openwrt/packages/blob/master/net/wireguard/Makefile
(Mensch kann auch den Patch zu dem PR auf 1116 mit in aktuelle Openwrt einbauen und dann wireguard (und l2tpv3 und batman-adv) über make menuconfig mit reinladen)
vermutlich ist die Diskussion um Geschwindigkeit etc. eh besser hier aufgehoben, dort sind auch scripte um mit 2 laptops/computern und 2 routern wie dem 841 und iperf eigene Tests zu machen.
edit: @Mitsch wir testen nur auf 841 , da das eh auf diesen schwachen kisten laufen können muss - das ist auch gut so, so sind Fehler die andere mit den 1043 nichts hatten überhaupt erst aufgefallen (siehe Mips 74k 32k ) - evtl machen wir noch 940 und 842 - wenn du das machen willst bin ich sehr auf deine Zahlen gespannt.
edit: @Handle … blanko geht durch das kabel etwa 93Mbit mit reinem Routing (was nix mit wireguard zu tun hat). Mit Wireguard scheints 40 aktuell - wireguard kann nur 1 Art von Crypto die is ähnlich zu chachapoly1305 in fastd und ist nicht optional.
Testet Ihr das mal noch mit z.B. einem dicken 1043 v2?
Würde mich wirklich interessieren, was dabei rum kommt…
Hab jetzt schon Angst, dass die 50MBit/s VDSL bald mit Freifunk gefüllt werden könnten… 