Ich habe auf gelesen das das VPN schnell sein soll, vergleichbar mit OpenVPN ohne Verschlüsselung!
Ein OpenWRT Packages sollen schon in Vorbereitung sein.
Ja das Performance-Problem mit OpenVPN und auch Fastd ist dass die im Userspace laufen und daher viele Kontextswitche erzeugen. Daher ist WireGuard vermutlich/hoffentlich (ich hab das noch nicht getestet) mit Crypto schneller als Fastd oder OpenVPN mit null Crypto.
Das ein OpenWRT-Package in Arbeit ist habe ich auch schon gelesen, bin gespannt. Das Modul lässt sich aber auch auf Debian sehr problemlos kompilieren und testen.
L2TP verschlüsselt nicht, für viele Leute ist das aus verschiedenen Gründen nicht tragbar bzw. nicht in jedem Fall tragbar. Das wurde ja schon lang und breit diskutiert und ich möchte das für und wieder von Verschlüsselung in diesem Thread nicht thematisieren.
Ach so, na dann änder doch den Betreff mal passend, denn als zukünftige VPN-Lösung
für die meisten Leute die L2TP verwenden, dürfte dies absolut nicht zutreffen.
Trotzdem sehr interessant das Ding, danke für den Hinweis darauf!
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
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
( 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
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.
@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.
- also mal real Dinge bauen