Voorstel moet WireGuard aan Linux-kernel toevoegen voor beveiligde vpn-tunnels

Jason Donenfeld, de bedenker van WireGuard, stelt voor om zijn software op te laten nemen in de Linux-kernel. Hij omschrijft WireGuard als een next generation kernel network tunnel die een sneller en eenvoudiger alternatief moet bieden voor IPsec en OpenVPN.

In een bericht op de Linux-kernelmailinglijst schrijft Donenfeld dat zijn project het resultaat is van ongeveer drie jaar werk. Hij introduceerde WireGuard in 2016 als een nieuwe vpn-tunnel. In een nadere uitleg schrijft hij dat de door hem toegevoegde commit WireGuard implementeert als een eenvoudige netwerkdriver. Er zijn inmiddels verschillende clients voor de software, bijvoorbeeld voor verschillende Linux-distributies, macOS en Android. Een officiële Windows-client ontbreekt momenteel nog.

In een bijbehorende whitepaper legt hij uit dat WireGuard uit ongeveer vierduizend regels code bestaat en dat de software gebruikers beschikking moet geven over een virtuele netwerkinterface genaamd wg0, die te configureren is via ip of ifconfig. Het enige wat gebruikers hoeven te configureren is het toevoegen van een privésleutel en ip's met 32 byte-publieke sleutels van peers waarmee gecommuniceerd mag worden.

Het uitwisselen van sleutels, het maken en verbreken van verbindingen en soortgelijke activiteiten moeten daarbij buiten het zicht van de gebruiker op de achtergrond plaatsvinden. Donenfeld trekt de vergelijking tussen de eenvoud van het configureren en opzetten ssh en die van WireGuard. De geringe omvang van de software moet bovendien een zo klein mogelijke attack surface voor aanvallers bieden en het uitvoeren van een audit vergemakkelijken.

De broncode van de software is online te vinden. Op de officiële site stelt Donenfeld wel dat het momenteel nog om een work in progress gaat. Zo zijn er nog geen beveiligingsaudits doorgevoerd en wordt er nog gewerkt naar een stabiele 1.0-release. Linus Torvalds zegt in een eerder bericht op de mailinglijst dat ernaar gestreefd zou moeten worden WireGuard in de kernel op te nemen.

Reacties (68)

[True]

Nog geen beveiligingsaudits gedaan en er wordt nog gewerkt voor de v1 release. Leuk maar dan komt die dus echt niet in de Linux-kernel op het moment. Ik dacht dat dat OpenVPN niet eens in de Linux-kernel zit en ik twijfel ook aan IPsec IPsec zit er al wat langer in, dank @CAPSLOCK2000. Maak het gewoon goed beschikbaar via de repositories en werk de stable releases eerst even goed uit.

[Reactie gewijzigd door True op 27 juli 2024 20:34]

[vDorst]

WireGuard komt mogelijk niet in de kernel door regel lengtes en dat er een nieuwe crypto library wordt toegevoegd. Maar niet door dat het maar v1 is.
Jason heeft zich goed voorbereid en veel gecommuniceerd met de diverse sub groepen van de linux kernel om te bepaalde hoe dingen aan te pakken om WireGuard goed te integreren in de linux kernel.

Er is bewijs geleverd dat het protocol veilig is. https://www.wireguard.com/formal-verification/
Implementatie zelf is zover ik weet niet door externe partij gecontroleerd.
Er hebben ondertussen al veel ogen naar gekeken die er veel over weten.

Tevens is WireGuard ook al een tijd bij een paar VPN diensten af te nemen.

Zelf heb ik een bijdragen geleverd door de chacha20/poly1305 in mips32r2 assembler te schrijven.
Hierdoor is het versleutelen van de pakketjes toch 1,5x sneller geworden.
Want WireGuard draait ook goed op de simpele mips routers.

[Jerie]

Is die optimalisatie van jou er ook voor MIPS64? In dat geval heb ik namelijk dankzij jou 1,5 snellere performance!

WireGuard packages zijn werkelijk voor allerlei apparaten en OSen te verkrijgen. Check de website. macOS, Linux (van Alpine tot NixOS), OpenWRT, Synology, noem maar op. Je zou het zelfs in Docker kunnen draaien.

[vDorst]

Nee, MIPS64 gebruikt de code uit OpenSSL.

Ik heb helaas ook geen hardware, het lijkt me nog steeds leuk om te doen.

Chacha20 code heb ik vooral winst behaald door de gegeneerde chacha sleutel te laten staan in de registers ipv op te slaan in het geheugen. Op een gegeven moment gaat elke instructie in een loop zwaar meetellen, door xor loop te vervangen door een jumptabel heb ik ook weer wat weten te besparen. Dit alles levert 14-17% verbetering op in de chacha20 encryptie in houding tot de generic C variant.
MIPS64 gebruikt generic C variant voor chacha20. Dus hier valt ook nog winst te behalen.

Poly1305 is bijna een op een kopie van de C code. Welke een paar aanpassingen om het vlotter te maken. Maar vooral slimmer om te gaan met de 32-bit multiplicatie instructie en de laatste carry mee te nemen naar de volgende keer in de loop, heeft ongeveer 2,7x verbeterd geleid.

Ik weet niet hoe goed poly1305 op de mips64 is. Daar is vooral echte hardware voor nodig om dat te testen.

[xback]

Mag ik je vragen om een link naar je commits te posten?

Dit lijkt me zeer leerrijk

Bedankt!

edit:
gevonden

[Reactie gewijzigd door xback op 27 juli 2024 20:34]

[SirNobax]

geen beveiligingsaudits gedaan [..] Leuk maar dan komt die dus echt niet in de Linux-kernel

Tja, SPECK, een door NSA ontwikkelde crypto, waar geen audit voor nodig was om te weten dat deze lek is, is ook in de Linux kernel terecht gekomen, dus dat kan nog alle kanten op.

[Reactie gewijzigd door SirNobax op 27 juli 2024 20:34]

[totaalgeenhard]

Userspace tunnels zijn veiliger omdat je bij incidenten niet verder komt.

Kernel blijven vullen maakt het alleen maar groter.

3 jaar is wel erg weinig. Ipsec is zeker al iets van 20 jaar oud en weinig problemen. Alleen ssl kind.

[kozue]

Ipsec weinig problemen? Ipsec is nodeloos complex en een draak om degelijk werkend te krijgen. En als je een wat complexere setup hebt en verkeer uit de tunnel weer verder moet sturen over andere vpn’s heen kom je helemaal in een hel terecht omdat ipsec niet netjes via de standaard routering werkt, in tegenstelling tot openvpn, dat bij ons nog nooit problemen heeft gegeven. Een vpn systeem dat betere performance geeft en makkelijker op te zetten is zou een hoop mensen het leven veel makkelijker maken.

[totaalgeenhard]

Mensen hadden problemen met freeswan.

Maar waar het op neerkwam dat men te weinig kennis van kernel, tcp/ip snack, routing, SSL, VPN en dat geheel binnen linux omgeving.

Met GUI click generatie zal het alleen nog maar erger worden. RTM doen men niet.

En aangezien ik nooit Xwindows gebruik vraag ik me Of er een xMAN bestaat

[Gravit0n]

Die vergelijking is niet helemaal eerlijk, omdat IPSec geen protocol is en SSL wel.

[True]

Dit klinkt mij ook meer als een publiciteitsstunt in de oren dan een serieuze vraag om toegevoegd te worden. Iedereen met een beetje inhoudelijke kennis over de procesvorming bij de Linux-kernel voelt aan z'n water dat dit niet wat gaat worden.

[nopcode]

Ik heb met Jason gesproken en het doel is echt wel om dit in de kernel te krijgen, het is niet efficiënt om alle packets te kopiëren tussen userspace en kernel.
Kijk naar de performance tussen wireguard/ipsec en openvpn...

[totaalgeenhard]

Heb je ergens vergelijkende benchmark gezien?

[nopcode]

Ja,

Jason heeft ook live demo gegeven om de cijfers in deze slide te bevestigen:
https://benjaltf4.me/wp-c.../12/34c3-Wireguard-30.jpg

[totaalgeenhard]

Dit plaatje zegt niet meer dan 1000 woorden.

Eerder meer vragen.

Test opstelling, verbinding en resources overhead (nic/memory/cpu).

Ik mag niet hopen dat op basis van die slide beslissingen nemen

Ik ken het niet heb helaas ook geen tijd er in te duiken (geen noodzaak daartoe).

[Kain_niaK]

Als Wiregaurd echt veel betere performance geeft dan is het gewoon een betere oplossing en zou het heerlijk zijn dat het in de kernel terecht komt. Gigantisch veel gebruikers kunnen er dan gebruik van maken met betere performance dan huidige oplossingen.

[MadEgg]

En hou het gewoon in userspace... Ik zie geen reden om VPN-clients in de kernel te gaan zetten, die is al dik genoeg van zichzelf.

[nopcode]

Het is veel sneller in de kernel.

IMO is encryption in de kernel is een goede reden om de codebase groter te maken.
Dat ze hun drivers is wat opkuisen...

[MadEgg]

Encryptie kan in de kernel, en wordt ook door processors ondersteund (AES-NI extensies). User space hoeft echt niet veel onder te doen. VPN-toepassingen zijn I/O-bound en daarmee voornamelijk afhankelijk van de bandbreedte en latency van het transportmedium, niet van de CPU.

Ik gebruik al jaren OpenVPN wat ook niet in de kernel draait en daarbij is de bandbreedte van de fysieke verbinding beperkend, niet het VPN-protocol.

[Zer0]

Ik gebruik al jaren OpenVPN wat ook niet in de kernel draait en daarbij is de bandbreedte van de fysieke verbinding beperkend, niet het VPN-protocol.

Ik gebruik ook al jaren OpenVPN, en de bandbreedte wordt vaak beperkt door de processing power van de VPN server, niet de fysieke bandbreedte (op wat dikkere lijnen), omdat het protocol in userspace draait kost het meer CPU resources.

[nopcode]

Ik gebruik al jaren OpenVPN wat ook niet in de kernel draait en daarbij is de bandbreedte van de fysieke verbinding beperkend, niet het VPN-protocol.

Ja maar dat is nu net aan het veranderen. Een gemiddelde (lower-end) server of laptop kan geen 1gbit/s over OpenVPN sleuren, met wireguard wel.

[grasmanek94]

Met openVPN haal ik maar 30 mbps over een 500/500 <=> 500/500 (NL <=> NL) lijn met een kant en klare router die dat kan. Sowieso dat OpenVPN wel CPU-bound is (in mijn ervaring dan).

[Reactie gewijzigd door grasmanek94 op 27 juli 2024 20:34]

[CAPSLOCK2000]

Ik gebruik al jaren OpenVPN wat ook niet in de kernel draait en daarbij is de bandbreedte van de fysieke verbinding beperkend, niet het VPN-protocol.

In mijn (beperkte) ervaring is de CPU de bottleneck, ook met AES-NI. Op lage snelheid is het allemaal wel te doen, maar als je meer dan 100mbit/s wil doen met AES256 dan moet je een flinke CPU meenemen. (Ik ben zo'n idioot die dan ook eens probeert om z'n hele interne netwerk via OpenVPN te laten lopen, inclusief NAS. Nadruk op proberen )

Wireguard is aanzienlijk sneller, dat zie je met het blote oog, maar eigenlijk denk ik dat het vooral ligt aan dat ze andere encryptie-protocollen gebruiken dan OpenVPN, en niet zo zeer met de kernel.

Volgens mij komt de behoefte om in de kernel te zitten meer voort uit het idee dat versleutelde verbindingen standaard zouden moeten zijn. Als je netwerk hebt dan moet de versleuteling ook beschikbaar zijn, is de geloof ik gedachte. (Of je het daar mee eens bent is een andere vraag )

[CAPSLOCK2000]

En hou het gewoon in userspace... Ik zie geen reden om VPN-clients in de kernel te gaan zetten, die is al dik genoeg van zichzelf.

Maar die functionaliteit zit er al sinds jaar en dag in, verschillende keren zelfs. Een ip-tunnel is op zich dan ook best wel simpel. Alles wat je er voor moet doen (data in pakketje stoppen en er weer uit halen) moet je toch al doen voor je regulier netwerkverkeer. Dat je data toevallig bestaat uit netwerkpakketjes die je na het uitpakken nog een keer door de netwerkstack moet halen maakt daarvoor weinig uit.
Encryptie en routering zitten ook al lang in de kernel.

De WG-code is zo klein omdat het vooral gebruik maakt van bestaande functionaliteit.

[MadEgg]

Verschillende keren zelfs, dat is toch een teken dat er iets niet goed gaat? Waarom niet één VPN-interface in de kernel en de specifieke implementaties in user space houden? Werkt voor pak 'm beet fuse met file systems ook prima.

[CAPSLOCK2000]

Verschillende keren zelfs, dat is toch een teken dat er iets niet goed gaat?

Omdat het zo ontzettend simpel is, omdat verschillende mensen onafhankelijk van elkaar hetzelfde bouwen, en omdat er verschillende netwerk-technologien zijn, bv IPv4 en IPv6.

Waarom niet één VPN-interface in de kernel en de specifieke implementaties in user space houden?

Het meeste is al gedeelde code. Ik weet niet helemaal wat de stand van zaken is. Fuse was er ook niet vanaf dag één, dat is pas ontstaan toen duidelijk was welke stukken code er makkelijk gedeeld kunnen worden. Zo ook met netwerkonderdelen.

[batjes]

Ach ondertussen zit de kernel stampvol troep die volgens de originele visie nooit de kernel in zou moeten zitten.

Maar tijden veranderen.

[CAPSLOCK2000]

Nog geen beveiligingsaudits gedaan en er wordt nog gewerkt voor de v1 release. Leuk maar dan komt die dus echt niet in de Linux-kernel op het moment.

Waarom niet? De regel is dat andere onderdelen van de kernel geen last van je moeten hebben. Werkende of veilige code is geen eis. Linus zelf lijkt geen bezwaren te hebben.

Ik dacht dat dat OpenVPN niet eens in de Linux-kernel

OpenVPN heeft geen kernel-component. Wel kan het gebruik maken van de encryptie support in de CPU.

zit en ik twijfel ook aan IPsec. Maak het gewoon goed beschikbaar via de repositories en werk de stable releases eerst even goed uit.

IPsec zit er al een jaar of 15 in. Ik kan zo snel niet meer vinden wanneer het is verschenen, het kan nog langer gelden zijn.

[Reactie gewijzigd door CAPSLOCK2000 op 27 juli 2024 20:34]

[Jerie]

Zegt niks hoe lang het in de kernel zit. IPv6 zat ook jarenlang in de kernel, zat ook RCE in eind 2005/begin 2006. IPsec is nodeloos complex. Met zoveel LoC is het smeken om problemen. Zoals je zelf elders stelt, WireGuard gebruikt bestaande standaarden. Je kunt het ook prima userspace draaien, als je dat wilt. Dat kan nu al, ook op Android. Maar je krijgt betere performance met de kernel modules.

[CAPSLOCK2000]

Zegt niks hoe lang het in de kernel zit.

Precies, dat is het punt. De drempel om in de kernel te komenis nogal laag. Dat iets in de kernel zit betekent nog niet dat het ook van goede kwaliteit is. Of, andersom, slechte/onwezen kwaliteit is niet automatisch een reden om code te weigeren voor de kernel.

[Jerie]

OpenVPN en IPsec bieden een belabberde throughput. WireGuard saturate een 1 gbit verbinding makkelijk waar OpenVPN en IPsec met moeite 200 mbit halen.

Verder zegt Torvalds zelf hierover:

So let's try to fix the iscsi and ipsec issues. Not that anybody sane
should use that overly complex ipsec thing, and I think we should
strive to merge WireGuard and get people moved over to that instead,
but I haven't heard anything from davem about it since I last asked..
I have some hope that it's slowly happening.

IPsec is nodeloos complex. WireGuard is zeer eenvoudig op te zetten (ZeroTier trouwens ook). Heb je het zelf ooit gebruikt?

[Luminarium]

Linus heeft al aangegeven interesse te hebben om WireGuard in de kernel op te nemen.

[job_h]

Geen audits, maar dit staat al wel op de website

It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.

[Verwijderd]

"The primary pathology of this patchset is the very long lines; I have
3840 horizontal pixels on my laptop, and I enjoy using all of them."

[falcon1]

Dan wordt hij zeker niet aan de kernel toegevoegd.
https://www.kernel.org/do...process/coding-style.html

https://github.com/torval...ter/scripts/checkpatch.pl
Is een van eerste dingen die door maintainers word gebruikt en die valt daar meteen over.

Die 80 karakters per regel is er niet zomaar. Op die manier kan de code op de mailinglist ook gewoon in-line reacties krijgen.

En mensen zijn niet gebouwd om hele brede regels te lezen. Dan verlies je overzicht.

[batjes]

Regellengte aanpassen is het probleem niet.

[Verwijderd]

Die 80 karakters per regel is er niet zomaar. Op die manier kan de code op de mailinglist ook gewoon in-line reacties krijgen. En mensen zijn niet gebouwd om hele brede regels te lezen. Dan verlies je overzicht.

Tjee dan heeft de boekdrukkunst het al fout sinds 1837. Om in 2018 ontwikkelaars te vertellen dat code langer moet worden omdat je niet meer dat 80 char op een 4k scherm mag tonen is onzinnig. Een goede developer bepaald dat zelf (en ik ken er geen die die 80 char regel nog als richtlijn ziet).

Kan ik veronderstellen dat jij niet 22 jaar oud bent?

[graey]

Sorry, ik ben wel jong, maar 22 karakters complexe code met ook maar enige vorm van bijvoorbeeld cryptografie kan al genoeg zijn om je in te verslikken. De complexiteit van zinnen in het gemiddelde gedrukte boek is wel een tikje lager dan de het aantal complexe constructies per aantal karakters dat je in de Linux-kernel ziet, om maar eens wat relevants te noemen.

[ari3]

Als er een regellengtelimiet ingesteld is dan is er iets mis met de toolset die gebruikt wordt. Als ontwikkelaar verbaas ik me al 20 jaar over het feit dat diff-tools witruimte die geen syntactische betekenis hebben als verschil aanmerken. Mijn stelling: twee broncodebestanden die semantisch identiek zijn mogen door een diff-tool niet als verschillend aangemerkt worden. Hieronder vallen ook dingen als accolade-open-altijd-op-een-nieuwe-regel en andere onbenullige eisen die ik vaak ziet langs komen.

We moeten ophouden dit soort onnodige limieten op te leggen en onze diff-tools fixen zodat iedereen gewoon vrij is om de code formatting te gebruiken die hij prettig vind.

[Verwijderd]

80char. richtlijnen zoals ook PEP 8 (Python) beschrijft zijn niet verkeerd, en maakt het makkelijk code naast elkaar te vergelijken.
Wanneer strikt aangehouden wel wat vervelend mij betreft,
Het mag wel mee groeien met de doorsnee resoluties. 80char op UHD lijk me inderdaad een kwelling als het om docstrings e.d gaat.

Uitzonderingen daar gelaten, HD is toch toch wel het minimum waarachter men zit, waarmee dit onderhand wel naar 120char gebracht zou kunnen worden.
Zelf negeer ik de lengte ook door rond de 120/240(afhankelijk van waar het script zich in begeeft) te gaan zitten.
Ook omdat het voornamelijk line continuations voor een paar stdout strings zijn die voor de code zelf niet boeien, of het maar een ~20 extra chars. extra betreft. daar ik een nieuwe regel voor één variabele storend in het lezen vindt.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 20:34]

[neographikal]

Ik draai het al een tijdje naar tevredenheid op openwrt om twee netwerken aan elkaar te knopen. Relatief eenvoudig (even goed opletten dat als je wil routen je ook de interne ip's van het andere netwerk moet whitelisten) en tot op heden 100% betrouwbaar.

[johnny2000]

sorry niet goed gelezen.

[Reactie gewijzigd door johnny2000 op 27 juli 2024 20:34]

[neographikal]

Nee, dit artikel gaat over Wireguard... Ik draai Wireguard op openwrt.

[teun95]

Ik weet niet of zaken die nog niet af zijn of nog niet ge-audit normaal toegevoegd worden, maar ik hoop dat WireGuard over niet al te lange tijd de standaard is en onderdeel is van de Linux kernel. Ik gebruik WireGuard nu ongeveer een half jaar en het is een hemelse VPN ervaring in vergelijking met Open VPN. Het is totaal niet merkbaar als de VPN aan staat op het feit na dat intern netwerken wat lastiger is.

Een speedtest ter illustratie (Locatie Glasgow, Speedtest server Londen, Mbps):
Zonder WireGuard
Download: 219.49
Upload: 11.75
Ping: 18 ms

Met WireGuard:
Download: 211.80
Upload: 10.02
Ping: 19 ms

Speedtests met de VS en Hong Kong laten hebben zelfs een lagere ping en hogere snelheid voor WireGuard verbindingen.

[RGAT]

Dan doe je toch iets verkeerd in je metingen als een verbinding lagere latency en hogere bandbreedte heeft bij het gebruik van een tunnel, dat is namelijk onmogelijk tenzij je verkeerd test

[Jerryy]

Dat is niet helemaal waar, je hebt namelijk ook nog zoiets als throttling: https://en.m.wikipedia.org/wiki/Bandwidth_throttling

[RGAT]

Wat dankzij netneutraliteit nog altijd niet mag worden gebruikt per service, dus een VPN zou niet sneller mogen worden gemaakt door een provider.
Wel zou die provider bijv. een 100Mb/s limiet kunnen instellen, waarbij de bandbreedte dan 100Mb/s - tunnel overhead zal zijn: nooit hoger dan zonder de tunnel overhead.
Niet dat die overhead gigantisch groot is, maar lagere latency en hogere bandbreedte met een tunnel is niet mogelijk in de echte wereld, wel in een testlab waar je inderdaad met throttling en DPI aan de gang gaat om L2TP/OpenVPN/Wireguard tunnels 200Mb/s te geven en al het andere verkeer maar 100Mb/s bijvoorbeeld.
Dat zal echter ook nog niet de latency voor een tunnel lager krijgen.

[Jerie]

IIRC gebruikt WireGuard een andere MTU, zoals @teun95 aangeeft kan het verschil hem ook zitten in IPv4 vs IPv6 (IPv6 geeft ietsje meer overhead IIRC). Anyway, er zijn wel degelijk genoeg redenen waarom een tunnel sneller kan zijn. We hebben er zo al 2 te pakken, zonder al teveel moeite te doen.

[teun95]

Is dit altijd waar? Ik denk dat ik geen dingen ernstig fout doe met testen, al ben ik geen expert. Dus het kan goed zijn dat ik van alles fout doe. Als je advies heb post ik de resultaten hier

Het lijkt me dat er manieren zijn om om te gaan met packet loss die je kunt toepassen tussen twee WireGuard servers maar niet per se met third-party servers/websites. Je claim dat het onmogelijk is, is misschien wat sterk aangezien je daar alle mogelijke manieren van verbindingen voor moet overwegen. Het is niet alsof mijn testresultaten natuurwetten overtreden, het suggereert alleen op dat het mogelijk is om de efficiëntie van data-transport over grote afstanden op te krikken.

Mullvad, de aanbieder van mijn VPN adverteert hier niet mee maar schreef het snelheidsverschil bij navraag toe aan het gebruik van ipv6 verbindingen tussen de servers.

[RGAT]

Je latency zal niet sneller worden door het gebruik van meer diensten, het moet namelijk alsnog over dezelfde routers van jouw provider, waar het daarna heen gaat zal hooguit de latency verhogen.
Als jouw latency naar AMS-IX bijvoorbeeld 5ms is, dan zal een tunnel dus nooit onder die 5ms komen naar AMS-IX, die tunnel verpakt namelijk verkeer en stuurt het dan over diezelfde verbinding...
Vrijwel hetzelfde geldt voor de bandbreedte, tunneling voegt een kleine header aan packets toe, meestal ook encryptie maar laten we voor het gemak aannemen dat de encryptie de te versturen data niet groter maakt. Stel jouw bandbreedte is 100Mb/s, dan zal normaal verkeer ~100Mb/s aan bandbreedte hebben, tunnel verkeer heeft dan ~100Mb/s min de overhead van die tunnel, misschien dat Wireguard packets compressed? (geen idee), dat zou enorm zwaar op de CPU zijn maar theoretisch mogelijk, dan zou in sommige gevallen de bandbreedte technisch gezien iets hoger kunnen zijn, ten koste van een flink hogere latency.
Packet loss tussen jou en jouw provider blijft 'hetzelfde' met of zonder tunnel, dus als jij 10% packet loss hebt zonder tunnel dan heb je met tunnel alsnog 10% packet loss over die verbinding. De tunnel kan er slim mee omgaan maar het verkeer wat door de tunnel gaat houdt er verder geen rekening mee, als er een retransmit gevraagd wordt zal die dus verstuurd worden (met opnieuw 10% kans dat er packetloss optreedt)
Die tunnels zijn geen magie, ze gaan alsnog over dezelfde verbinding welke dus niet ineens groter/sneller/beter wordt als je er een bepaald protocol over stuurt

Edit: bij nader inzien zou het kunnen wanneer er bijvoorbeeld een proxy op jouw netwerk gebruikt wordt welke niet al te vlot is, dat die de VPN niet verwerkt, maar ik ga er vanuit dat je dat niet hebt draaien?

[Reactie gewijzigd door RGAT op 27 juli 2024 20:34]

[MadEgg]

Ik heb het in het verleden ook wel eens gehad hoor, er kunnen legio redenen zijn waardoor verkeer via een VPN sneller is. Je ISP zou andere routes kunnen gebruiken dan je VPN provider. Als die route inefficient is of als er ergens netwerkproblemen in die route zijn dan zou het via je VPN sneller kunnen gaan.

Verder zou je bestemming rate limitting oid kunnen toepassen op basis van je IP-adres en hierdoor zou het prioriteit kunnen geven aan verkeer via een VPN boven verkeer via je ISP.

Jaren geleden ook wel eens meegemaakt via AtHome - die routeerden verkeer naar een gameserver in Londen via de VS, for whatever reason. Een VPN via een server in Amsterdam routeerde netjes rechtstreeks naar het VK en had daarmee een veel langere ping dan via de VS. Een verschil van 20ms tegen 90ms merk je wel.

[teun95]

Ik snap wat je zegt, maar zou je me dan kunnen helpen deze resultaten verklaren? Ik impliceerde overigens in mijn vorige posts het gebruik van een dubbele tunnel, maar ik weet niet of dat duidelijk was.

Speedtest zonder WireGuard: http://www.speedtest.net/result/7517603210.png
Gemiddeld ping uit 20 tests: 261.342 ms
Download: 6.76 Mbit/s
Upload: 6.31 Mbit/s

Speedtest met WireGuard: http://www.speedtest.net/result/7517610846.png
Gemiddeld ping uit 20 tests: 214.286
Download: 19.18 Mbit/s
Upload: 7.95 Mbit/s

Ik heb alle tests via de terminal gedaan. Hier is de output met wat comments en verwijderde persoonlijke details. Ik hoop dat het goed te volgen is: https://jpst.it/1kFR6

edit: De lage snelheden zijn het resultaat van de lange afstand. Wellicht dat een directe speedtest met een server die dichtbij is helpt bij het interpreteren van de resultaten.

[Reactie gewijzigd door teun95 op 27 juli 2024 20:34]

[batjes]

Is niet onmogelijk. Je provider kan veel goedkopere connecties hebben. Zoals bv een ziggo welke 30ms ping toevoegd naar servers in Amsterdam vanwege goedkopere routes door Frankfurt. Dat terwijl Ziggo je best wel direct kan routeren naar de VPN provider voor dezelfde verbinding naar een server.

[Jerie]

Het is totaal niet merkbaar als de VPN aan staat op het feit na dat intern netwerken wat lastiger is.

Waarom?

[teun95]

Ik heb er nog niet naar gekeken, maar mijn apparaten zijn niet meer benaderbaar via UPnP als WireGuard aan is. Op Android waren er ook wat problemen met lokale IP adressen te benaderen terwijl WireGuard actief is.

[Jerie]

Ik heb er nog niet naar gekeken, maar mijn apparaten zijn niet meer benaderbaar via UPnP als WireGuard aan is. Op Android waren er ook wat problemen met lokale IP adressen te benaderen terwijl WireGuard actief is.

Klinkt als een routing issue.

Mogelijk gebruik je een range die al in gebruik is. Standaard suggereert men IIRC 192.168.1.0/24? Tja, die is nogal 'ns in gebruik. Bij ZeroTier is de GUI wat dit betreft gebruikersvriendelijker (en die haalt ook een zeer goede performance in vergelijking met OpenVPN en IPsec, zit tegen die van WireGuard aan) maar ja die heeft ook nadelen.

Heb op dit moment geen Android toestel om dit te testen, maar via macOS en Linux kan ik dit probleem niet reproduceren. Dit is bijv macOS:

$ ip route get 192.168.0.1
192.168.0.1 dev en0 src 192.168.0.4
$ ip route get 192.168.0.2
192.168.0.2 dev en0 src 192.168.0.4
$ ip route get 192.168.0.4
192.168.0.4 dev lo0 src 192.168.0.4
$ ip route get 192.168.30.1
192.168.30.1 dev utun1 src 192.168.30.4
$ ip route get 192.168.30.4
192.168.30.4 dev utun1 src 192.168.30.4

Routing klopt dus, en ja ze zijn allemaal te pingen en te benaderen. UPnP gebruik ik persoonlijk niet, beschouw ik als onveilig. Wat niet werkt is via bijv LTE het LAN bereiken, naar services die geen WireGuard draaien. Maar middels port forwarding (of een transparent proxy) moet dat wel aan de praat te krijgen zijn!

[Verwijderd]

Uhhh weet je zeker dat je die cijfers wilt gebruiken om je punt te maken?

[teun95]

Ja, hoezo? Mijn punt hier was dat ik het niet merk wanneer WireGuard actief is, in tegenstelling tot OpenVPN.

[CAPSLOCK2000]

Ik ben wel fan van Wireguard, ik vind het heerlijk werken. Het voelt als een hele stap vooruit ten opzichte van OpenVPN en IPSec. Het is eenvoudig op te zetten en de performance is geweldig.

De grote vraag is of het ook echt veilig is. Ik heb geen concrete reden om daar aan te twijfelen, de programmeur lijkt behoorlijk goed te weten wat hij doet, maar tot de eerste audit blijft het onduidelijk. Het risico bestaat dat het alleen zo snel is omdat er een essentiele stap wordt overgeslagen.

Ik ben er wel tevreden over. Ik durf het nog niet aan als enige VPN-oplossing voor al mijn problemen, maar op de plekken waar ik het gebruik voldoet het prima (wat snelheid en gemak betreft).

[Kain_niaK]

Hoe meer interesse er voor is, hoe groter de kans is dat andere network devs de code gaan bekijken en testen. En white hat hackers ze gaan proberen aan te vallen. Dan komt zo een goede audit er wel.

[kuurtjes]

En binnekort heb je dan de Kernel Store™

[Jerie]

Laat maar komen, dan zit het ook native in Android en hoef je die niet meer te rooten om de kernel module te gebruiken (userspace draait WireGuard al op Android). Wat ik fijn vindt is dat je de boel kunt scripten (de cmds), en je kunt gebruik maken van zowel een private als een public key of beiden. Ik gebruik WireGuard op een EdgeRouter-Lite (een MIPS64 Linux machine) die vervolgens 2 DNS servers draait: unbound en dnsmasq. De laatste blokkeert een scala aan ads en praat enkel met de eerste. De eerste praat enkel over TLS. Vervolgens worden alle requests naar port 53 tcp/udp geredirect naar dnsmasq. Het gevolg is dat alles dezelfde DNS server gebruikt, en ik minder ofwel geen last heb van DNS poisoning. Het scheelt ook veel data als je gebruik maakt van roaming. Een ander voordeel is dat behalve WireGuard niets open hoeft te staan naar de buitenwereld. Zelfs geen reverse proxy of SSH server (overigens draai ik wel een SSH server over Tor als backup).

[johnkeates]

Ik snap niet waarom iedereen zo veel moeite lijkt te hebben met IKE of OpenVPN, dat spul werkt echt prima. Stel dat je geen kaas gegeten hebt van cryptografie, PKI en netwerken, dan kan het lastig zijn om iets op te zetten, maar dan is zelf een gateway of een multihomes host met meerdere static routes ook lastig en heeft het ook vooral betrekking op de onderwerpen zelf en niet zo zeer de VPN technologie.

[_JGC_]

OpenVPN is simpel. IKE of ipsec daarentegen.... Alleen al het gekut met firewall en NAT is een drama.

Heb overigens bij een klant een OpenVPN tunnel moeten opzetten voor Zabbix. Die zet nogal wat TCP connecties op wat het Hitron modem van Ziggo niet leuk vindt, helft van de verbindingen wordt niet doorgezet. Met OpenVPN is het gewoon 1 stream met UDP packets.

[johnkeates]

Is het probleem in dat geval niet gewoon het modem? Ik ben zelf ook meer fan van OpenVPN dan IPSec en IKEv2, maar de strekking van dit artikel dat WireGuard automatisch de beste is en alles moet vervangen vond ik wat ver gaan. Net als tinc zijn dit soort technieken leuk, maar niet voor de meeste situaties. Stel dat je een eindgebruiker bent en een MITM partij wil betalen om dat je illegaal wil downloaden, dan maakt het protocol weer een heel stuk minder uit, en dat lijkt te zijn daar WireGuard ook vooral voor geschikt is.

[_JGC_]

Is een modem met de welbekende Puma6 chipset. Ziggo levert helaas alleen nog modems met die chipset. Puma6 staat bekend om random latency en hoge packetloss als je veel TCP verbindingen opent en sluit, door dat in een tunnel te wrappen los je dat op.

Verder nog niet veel naar wireguard gekeken. Lijkt veelbelovend omdat je minder data staat te verstouwen tussen userspace en kernelspace. Ipsec zou dit voordeel ook moeten hebben op linux, maar vind de latency daarvan niet echt beter dan met OpenVPN.

[johnkeates]

Dat is inderdaad wel een nadeel van OpenVPN, maar op het moment nog niet groot genoeg voor de setups (eigenlijk allemaal alleen maar VoIP, management / C&C en wat remote data transfer batches). Ik kan me voorstellen dat je een databasecluster of SAN liever niet op OpenVPN zou laten communiceren om maar wat te noemen

[GekkePrutser]

Inderdaad. IKEv2 is lastig maar er zijn pakketten die het je dat heel makkelijk maken.

Helaas is bovengenoemde algo ook aan het overstappen op Wireguard, voor Android ondersteunen ze niks anders meer. Ik ben het er ook niet mee eens, ik heb liever een protocol dat zich al jarenlang bewezen heeft. Plus dat Samsung apparaten er standaard ondersteuning voor hebben. Maargoed, het is maar een kleine aanpassing om terug te draaien.