WireGuard-vpn 1.0.0 verschijnt in Linux 5.6-kernel

Versie 1.0.0 van de vpn-applicatie WireGuard is verschenen, tegelijk met de release van Linux 5.6, waar WireGuard nu onderdeel van is. WireGuard moet vpn sneller en makkelijker maken, met een kleine codebase.

Hoofdontwikkelaar van WireGuard Jason Donenfeld kondigt versie 1.0.0 van de software aan en meldt dat in aanloop naar de integratie in Linux 5.6, WireGuard een beveiligingsaudit heeft ondergaan en stabiliteitsverbeteringen heeft gekregen. Distributies als Arch, Gentoo en Fedora 32 ontvangen WireGuard automatisch bij de update naar kernelversie 5.6. De ontwikkelaars werken ook aan het backporten van de vpn-software voor distributies die nog op oudere kernelversies draaien. Windows- en macOS-versies van WireGuard hebben de 1.0.0-status nog niet bereikt.

WireGuard is vpn-software met een kleine codebase die het instellen van vpn makkelijk moet maken en voor snellere verbindingen moet zorgen, schrijft Ars Technica. De software kreeg al snel de goedkeuring van Linux-voorman Linus Torvalds, die het in 2018 a work of art noemde in vergelijking met de horrors van OpenVPN en IPSec.

De software is onderdeel van het zondag verschenen Linux 5.6. Volgens Phoronix gaat het om een relatief omvangrijke kernelupdate, met onder andere ondersteuning voor usb 4 dankzij Intels bijdrage op basis van zijn Thunderbolt 3-drivercode.

Ook biedt de kernel vroege Y2038-compatibiliteit voor 32bit-systemen. Het jaar 2038-probleem verwijst naar de datumaanpassing die 32-bits Unix-systemen op 19 januari 2038 om 03:14:07 utc maken. Ze zullen zonder aanpassingen op dat moment de datum 13 december 1901 aangeven. Dit komt omdat het aantal seconden dat is verstreken sinds 1 januari 1970 00:00:00 utc, het begin van de 'Unix-tijd', wordt bijgehouden in een integer van 32 bits. In 2038 is de maximale waarde bereikt en gaan de programma's die Unix-tijd gebruiken over op een groot negatief getal, wat ze interpreteren als 13 december 1901.

Reacties (77)

[Blokker_1999]

En dan vraag ik me af: hoort zoiets wel thuis in een kernel? Toegegeven, de Linux kernel is al een enorm project, maar moet iets dat al jaren door anderen perfect in user space wordt gedaan ineens deel gaan uitmaken van die kernel? En wat is daar dan de echt toegevoegde waarde van?

[The Zep Man]

En dan vraag ik me af: hoort zoiets wel thuis in een kernel?

@Tom Paris geeft een goed overzicht. Verder denk ik dat het antwoord 'ja' is. De kracht van WIreGuard is dat de code bijzonder compact en vlot is, en dat er behoefte is aan het simpelweg kunnen opzetten van VPN's met enkel standaard tools in user-space. Uiteindelijk is het de bedoeling om de functies van de 'wg' user-space tool te integreren in 'ip', zodat enkel met 'ip' een VPN verbinding opgezet kan worden.

Doordat WireGuard klein is en volledig in kernel-space kan draaien heeft het als voordeel dat het ook automatisch vernieuwd wordt bij het vernieuwen van de kernel.

Natuurlijk zijn er ook nadelen aan WireGuard. Als één van de cryptografische primitieven ondermijnt zou worden dan kost het wat moeite om een nieuwe protocolversie te introduceren, en backwards compatibility wordt dan ook een vraagteken. Deze situatie komt echter minder vaak voor als programmeer-/implementatiefouten. Doordat de code compact is, is het ook beter te onderhouden.

maar moet iets dat al jaren door anderen perfect in user space wordt gedaan ineens deel gaan uitmaken van die kernel? En wat is daar dan de echt toegevoegde waarde van?

Snelheid. Zie OpenVPN, die voornamelijk vanuit user-space werkt en enkel een TUN/TAP interface als doorgeefluik in de kernel gebruikt. Ultra-flexibel, maar probeer daarmee maar eens met beperkte hardware een Gigabit Ethernet-lijn vol te trekken. Dat gaat je niet lukken.

Let op dat WireGuard geen vervanger is voor OpenVPN. Elk product heeft zijn eigen optimale scenario waarin het gebruikt wordt.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 15:56]

[pennywiser]

Hoe verhouden wg en ovpn dan zich met elkaar? Ik dacht juist wel dat wg een vervanger was, als je alleen al kijkt naar de keuze optie welke pivpn biedt (of wg of ovpn)..

[The Zep Man]

Hoe verhouden wg en ovpn dan zich met elkaar? Ik dacht juist wel dat wg een vervanger was, als je alleen al kijkt naar de keuze optie welke pivpn biedt (of wg of ovpn)..

WireGuard kan OpenVPN niet in alle situaties vervangen. Een lijstje:

• OpenVPN ondersteunt public-key infrastructure. WireGuard niet. Voor ad-hoc en kleine installaties is dit geen nadeel, maar wel op enterprise-niveau.
• Door het gebruik van TLS kan OpenVPN draaien over TCP. WireGuard kan dit niet. TCP is soms noodzakelijk, met name wanneer UDP verbindingen geblokkeerd worden of als men een proxy wilt gebruiken om bijvoorbeeld het netwerkverkeer te obfusceren.
• WireGuard wordt nog niet overal (goed) ondersteund. Denk aan VPN providers.
• WireGuard heeft maar één vorm van authenticatie en autorisatie (asymmetrische sleutels), terwijl OpenVPN meerdere vormen ondersteunt en makkelijker is om uit te breiden met nieuwe vormen.

Ik denk dat er plek is in de wereld voor beiden, en dat het "WireGuard gaat OpenVPN vervangen"-verhaal een hersenspinsel is van clickbait sites en onervaren netwerkbeheerders. In sommige situaties kan WireGuard zeker OpenVPN vervangen, maar het is niet alsof OpenVPN overbodig is geworden.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 15:56]

[morphje]

Verder is wireguard ook zwaar afhankelijk van handmatige configuratie. Er is geen DHCP en dynamische configuraties mogelijk. Key uitwisseling gebeurd vooraf, niet tijdens het opzetten van de verbinding.

OpenVPN is veel meer een gebruiker georienteerd systeem. Wireguard moet je zien als een point-to-point netwerk verbinding die toevallig ook nog eens encrypted is. Maar net zoals elke netwerkverbinding moet je die grotendeels handmatig zelf configureren. Denk dan aan de diverse tunnelprotocollen.

(ja, een lokaal netwerk kent DHCP, maar dat maakt gebruik van broadcast en dat is niet mogelijk in een point-to-point oplossing)

[The Zep Man]

Verder is wireguard ook zwaar afhankelijk van handmatige configuratie. Er is geen DHCP en dynamische configuraties mogelijk.

Met IPv6 maakt dat niet veel uit. Nodes kiezen dan hun eigen IP adressen m.b.v. SLAAC. De kans dat dan twee nodes conflicterende adressen hebben is oneindig klein. Routing tussen nodes kan dan plaatsvinden op een enkele node die als default gateway en router dient. Het Neighbor Discovery Protocol doet dan de rest.

Key uitwisseling gebeurd vooraf, niet tijdens het opzetten van de verbinding.

Hetzelfde als met OpenVPN.

Verder ben ik het wel met je eens. WireGuard neemt de gebruiker niet mee aan het handje zoals OpenVPN dat doet. Vanuit de ene kant is het simpeler doordat er minder opties zijn, vanuit de andere kant is het complexer omdat soms juist opties missen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 15:56]

[arianvp]

Zo ver ik brgijp werkt dit helaas nog niet op Wireguard. Wireguard doet crypto-key routing, dus elke key is verbonden aan een vaste IP Range. je moet dus elke node een statische IP range alloceren.

Maar ze zijn met een DHCP-achtig mechanisme voor wireguard bezig over IPv6 link-local adressen: https://github.com/WireGu.../blob/master/docs/idea.md


Misschien begrijp ik het verkeerd en kan je wel gewoon SLAAC on top of wireguard doen, maar dan snap ik niet wat het doel is van dit wg-dynamic project

[Jerie]

WireGuard heeft maar één vorm van authenticatie en autorisatie (asymmetrische sleutels),

Nee hoor, je kunt (ook) een PSK gebruiken.

Ik denk dat er plek is in de wereld voor beiden, en dat het "WireGuard gaat OpenVPN vervangen"-verhaal een hersenspinsel is van clickbait sites en onervaren netwerkbeheerders. In sommige situaties kan WireGuard zeker OpenVPN vervangen, maar het is niet alsof OpenVPN overbodig is geworden.

WireGuard is al jaren bezig marktaandeel af te snoepen van met name OpenVPN.

Het is niet zo dat wanneer een beter product op de markt is gekomen, deze meteen al het oude vervangt. Alleen al een eventuele migratie is duur...

[Jerie]

OpenVPN is meer LOC dus hogere attack surface, WireGuard is eenvoudiger op te zetten (zie de quickstart op de homepage), de latency en throughput is stukken beter van WireGuard, en tenslotte de opbouw van de verbinding is stukken sneller bij WireGuard (enkele ms ipv 7+ sec).

[Reactie gewijzigd door Jerie op 23 juli 2024 15:56]

[johnbetonschaar]

moet iets dat al jaren door anderen perfect in user space wordt gedaan ineens deel gaan uitmaken van die kernel? En wat is daar dan de echt toegevoegde waarde van?

Volgens mij gebruiken zo ongeveer alle andere VPN oplossingen ook gewoon kernel infrastructuur die specifiek voor VPN is. Toen ik jarenlang geleden nog mijn eigen kernels compileerde was er een ellenlange lijst in de netwerk support sectie die alleen maar voor allerhande VPN gerelateerde features nodig was: TUN/TAP, IPSec, PPTP, etc. Dat moderne distro's met kernels komen die dit standaard allemaal aan hebben staan wil niet zeggen dat zoiets als OpenVPN 'perfect in user space' draait. Wireguard werkt anders dan bestaande VPN oplossingen, het is onstaan precies omdat bestaande VPN oplossingen te ingewikkeld te configureren, te intrusief/heavyweight en te inefficient waren. Blijkbaar kon dat alleen met behulp van kernel-level infrastructuur die er nog niet was.

[nvaert1986]

[...]


Volgens mij gebruiken zo ongeveer alle andere VPN oplossingen ook gewoon kernel infrastructuur die specifiek voor VPN is. Toen ik jarenlang geleden nog mijn eigen kernels compileerde was er een ellenlange lijst in de netwerk support sectie die alleen maar voor allerhande VPN gerelateerde features nodig was: TUN/TAP, IPSec, PPTP, etc. Dat moderne distro's met kernels komen die dit standaard allemaal aan hebben staan wil niet zeggen dat zoiets als OpenVPN 'perfect in user space' draait. Wireguard werkt anders dan bestaande VPN oplossingen, het is onstaan precies omdat bestaande VPN oplossingen te ingewikkeld te configureren, te intrusief/heavyweight en te inefficient waren. Blijkbaar kon dat alleen met behulp van kernel-level infrastructuur die er nog niet was.

Klopt helemaal wat je zegt. Ik compileer mijn kernels nog steeds zelf en gooi alle meuk die ik niet nodig heb eruit en bouw enkel wat ik nodig heb (waar WireGuard OpenVPN zal vervangen, omdat het voor mijn thuisomgeving meer dan voldoet). Mijn kernel is 6,6MB en m'n OS vebruikt 62MB zodra het gestart is in < dan 2 seconde zonder xorg-server) :-) Met xorg-server en KDE geladen zo'n 690 - 710MB geheugen in gebruik (zonder extra pplicaties geladen). Voor WireGuard ga je misschien TUN/TAP nodig hebben, maar veel meer zeker niet en vermoed dat je deze niet eens nodig hebt (heb me er nog niet in verdiept, maar ga ik zeker wel eens doen). Naast het feit dat het sneller is, heb ik al gezien dat het ook nog eens veel eenvoudiger te configureren en beheren is ten opzichte van OpenVPN / IKEv2, alleen maar pluspunten al zeg ik het zelf. Zeker in kleinschalige omgevingen.

[arjankoole]

Volgens mij heb je voor wireguard niet eens tun/tap nodig. Het levert zijn eigen interface. (Die je ziet als wg<N>

[grasmanek94]

Mijn kernel is 6,6MB en m'n OS vebruikt 62MB

Mooi "omdat het kan" neem ik aan? Niet negatief bedoelt maar waarom zou je daar blij mee zijn?

1TB HDD's voor 50 euries, meeste computers hebben 4GB RAM tegenwoordig (zelfs de Raspberry Pi), en de norm gaat richting 8GB. Enthousiast builds hebben vaak tussen 16GB - 128GB. Ik snap het nut niet tenzij je op een embedded platform iets draait, maar dan is 6.6MB met 62MB ram veel te groot.. ook daar zijn oplossingen voor: https://store.arduino.cc/arduino-yun?from=Main.ArduinoYUN

[Reactie gewijzigd door grasmanek94 op 23 juli 2024 15:56]

[Tom Paris]

Het gelinkte artikel van ArsTechnica biedt iets meer uitleg hierover:

WireGuard will now operate as either a Loadable Kernel Module (LKM) or built statically into the kernel itself. But whether static or loadable, it will be "in-tree"—which means it's provided ready to go with the vanilla kernel itself, with no need for repackaging by the various distros. This puts it on the same footing as other supported drivers.

The shift from third-party to first-party LKM also means no more Dynamic Kernel Module Support builds will be necessary. DKMS is a convenient framework that allows a kernel module to be automatically rebuilt from source against each new Linux kernel as it is installed—but it's not bulletproof. A user with a single computer might go years without seeing a DKMS hiccup, but a sysadmin with tens of machines and critically important DKMS packages will probably have to poke at a botched kernel upgrade once or twice a year.

DKMS builds add a significant amount of extra time to routine kernel upgrades even when they go well, since the system is actually recompiling the source code itself against the new kernel's headers. Although WireGuard is a relatively small and clean project, the DKMS build time is generally in the "several minutes" range even on relatively fast servers. This wasn't enough extra time to be a big factor in automated upgrades, but it was enough to cause some frustrated toe-tapping in manual installations and upgrades.

[RedPixel]

Voornamelijk vanwege de performance. WireGuard is een (virtuele) netwerkadapter, en gedraagt zich als zodanig, en heeft dus ook een driver. Die draait dus in kernel space. Als je dit niet in-tree doet, moet je van systemen als DKMS gebruik maken (wat dingen bij de Linux-kernel instopt, achteraf). Dat DKMS is traag, complexer om bij te houden en gaat wel eens mis.

Merk op dat dingen die in-tree zitten niet per sé geladen hoeven te worden (je kunt bij het compilen kiezen voor static of loadable). Het maakt je kernel wel iets groter, maar ik denk dat dat nadeel niet opweegt tegen de voordelen. Overigens kun je alsnog wel een lean-and-mean kernel compileren zonder WireGuard (of alle andere drivers), mocht je ergens toch echt een superkleine kernel nodig hebben.

[ShellGhost]

Geen idee waarom je van een +2 naar een 0 bent gegaan aangezien je punt zeer valide is.
Hoeveel additionele "troep" wil je in een kernel hebben? Linux was toch altijd van het lean & mean?
Op deze manier worden ze erger dan Microsoft... Slechte zaak.

[Eonfge]

De kernel in Linux is een vaag begrip. Om te beginnen bestaat de kernel uit duizenden losse modules welke je kunt in en uitschakelen naar eigen inzicht. Heb je geen storage of netwerk support nodig? Zet je het uit.

Hier het bestand van mijn systeem instellingen:
https://src.fedoraproject...86_64-debug-fedora.config

Edit:

Dit betekend dus ook dat 'bloat' een beetje een vaag begrip is. Het klopt inderdaad dat er allemaal verschillende hardware drivers, storage drivers, crypto, en netwerk drivers in de kernel zitten, maar is dat bloat? Dat is ook meteen waarom Wireguard in de kernel gaat: Het maakt al gebruik van kernel-crypto en kernel-networking. Het kleine beetje Wireguard dat nog geen onderdeel was van de kernel, zit er nu ook in.

[Reactie gewijzigd door Eonfge op 23 juli 2024 15:56]

[aequitas]

Linux is volgens mij nooit alleen van het lean en mean geweest. Maar altijd modulair en compatible. Je moet het ook niet zien dat Wireguard nu standaard in het geheugen geladen wordt op elke Linux machine. Maar dat je het zonder extra stappen 'aan' kan zetten als je dat wil. Net als al die andere drivers en modules. Je kan ook altijd nog je eigen modulaire of statische kernel bouwen zonder Wireguard en andere "troep" die je niet nodig hebt als je dat nodig hebt. Maar voor de meeste mensen is het fijn dat ze zonder te veel moeite dit kunnen gebruiken.

[OMX2000]

Klopt niet. Linux is begonnen als een kernel zonder module support. Dus als ik vroeger Wireguard nodig had in kernel moest ik een nieuwe kernel compileren. Later kwamen er modules, die het mogelijk maakten om tijdens “runtime” bijvoorbeeld een driver te laden.

Maar dus niet altijd compatible, tenzij je de kernel zo bakte

Is niet de micro- vs monolitische kernel discussie.

[Dorank]

Linux is begonnen als een kernel zonder module support. Dus als ik vroeger

Dat vroeger is dan wel meer dan 20 jaar geleden.

Maar linux is altijd modulair geweest omdat je zelf kon kiezen welke stukken code in je statisch gebouwde kernel terecht kwamen. Het resultaat was dat je voor de distros verschillende bootmedia (lees floppies) had die kernels hadden met bepaalde hardware support (ide/scsi/de verschillende cd controllers/netwerkkaarten). Tijdens/na installatie had je de keuze om een beter passende kernel te kiezen of zelf te tweaken door zelf te compileren. Heel normaal in die tijd.

[Jerie]

Je hebt geen idee waar je het over hebt. Je kunt WireGuard als module laden, zonder dat je IPsec of OpenVPN gebruikt. Welke beiden veel meer LOC bevat, en dus een grotere attack surface, en ook lelijker geschreven, dus meer "troep". De volgende stap is massaal afstappen van IPsec en OpenVPN, en die troep uit de kernel en OS verwijderen. Maar dat duurt nog wel even want backwards compatibility.

[WhatsappHack]

Mwah. Pas als wireguard dezelfde of betere prestaties biedt als IKEv2 (dat ook op ipsec leunt) én standaard ondersteund wordt door alle OS’es zal ik ‘t misschien eens gaan overwegen om over te stappen. Tot die tijd is WireGuard nog altijd inferieur in mijn ogen... Op het moment ben ik er nauwelijks van onder de indruk en snap ik de hype echt niet. Leuk dat ‘t nu in de kernel zit, maar daar is de strijd echt nog niet mee gewonnen of klaar.

Het is zeer veelbelovend, maar we zijn er wmb nog niet.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 15:56]

[tweaknico]

Richting mobile telefoons is er een wezenlijk verschil accu leeftijd is duidelijk beter dan met Openvpn en IPSEC. (er is dus duidelijk minder energie nodig voor verwerking van WG.

[Jerie]

Exact mijn ervaring, en dan hebben we het (helaas) niet eens over de kernel C implementatie maar over de userspace Go implementatie.

[Jerie]

Dit is vooral interessant omdat je hierdoor native performance krijgt (kernel-based in C ipv de user-space Go implementatie), en geen DKMS. Hierdoor zit het standaard in 5.6 en alle kernels daarna, zonder dat je er moeite voor hoeft te doen.

WireGuard biedt een betere throughput en latency dan IKEv2, maar het verschil is miniem. Het voordeel zit 'm vooral dat het veel eenvoudiger is om op te zetten. Als je al IKEv2 gebruikt, hoef je het ook niet op te zetten, maar je moet het wel blijven onderhouden, en misschien ook af en toe een nieuwe client opzetten. Het is verder eenvoudig te installeren, en ook eenvoudig in gebruik. Eenvoudiger ook dan OpenVPN. OpenVPN is al eenvoudiger op te zetten dan IKEv2. Beide bevatten veel meer LOC.

Voor roaming ("roadwarrior") vind ik WireGuard ideaal. Algo heeft er ook ondersteuning voor.

[pennywiser]

Ik dacht dat ik met Openvpn nog cutting edge bezig was, maar niet dus? (Btw wat is loc?)

[Reactie gewijzigd door pennywiser op 23 juli 2024 15:56]

[Jerie]

Lines Of Code, https://en.wikipedia.org/wiki/Source_lines_of_code

[tweaknico]

LOC = Lines of Code.
OpenVPN is usermode en alle pakketten moeten tweemaal door de volledige netwerk stack verwerkt worden. Een maal als encrypted en een maal als un-encrypted.
Daar is een voordeel met Wireguard: eenvoudige setup (eenvoudige keyexchange). en packet transform dus een maal door de netwerk stack heen.
IPSEC is ook in kernel transformatie maar heeft een uitgebreide Key exchange (IKE) in userspace nodig.

[teek2]

Je hoeft de kernel module toch niet te laden? Dan heb je er helemaal geen last van, ik zou wel eens willen weten hoe dit jouw leven nou echt slechter maakt...

[CAPSLOCK2000]

Voor de Linux-kernel is de regel dat anderen geen last mogen hebben van de troep. Een slechte driver is nog altijd beter dan geen driver. Als jouw "troep" zo kan bouwen dat anderen er geen last van hebben dan is het prima en mag je er bij. Zodra jouw code overlast geeft die er niet zou zijn zonder jouw code is het weer gedaan. De meeste drivers leven echter in volledige isolatie van elkaar en dan is het allemaal niet zo'n probleem.

[Sandor_Clegane]

Als je het niet gebruikt, wordt het niet geladen.

Dit betekend alleen maar dat je DKMS niet meer nodig hebt om het te recompilen als je je kernel wijzigt.

[Reactie gewijzigd door Sandor_Clegane op 23 juli 2024 15:56]

[84hannes]

hoort zoiets wel thuis in een kernel?

Als je het niet gebruikt, wordt het niet geladen.

Dat het niet geladen wordt als je het niet gebruikt vind ik een zwak argument: daarmee kun je alles in de kernel proppen. SQLite bibliotheek? Stop maar in de kernel, als je het niet gebruikt...
Ik denk dat je een VPN op een heel laag niveau wilt hebben zodat eventueel alles, bijvoorbeeld tijd ophalen bij opstarten via VPN verloopt.

[Reactie gewijzigd door 84hannes op 23 juli 2024 15:56]

[Sandor_Clegane]

Yup, want alles is zwart-wit. Een kernel driver voor een netwerk adapter of een filesystem is wat anders dan een SQLite bibliotheek.

[84hannes]

Precies en dát zou een goed antwoord mee moeten nemen!

[i-chat]

VPN hoort in de network-stack omdat je anders alles 10x overnieuw moet doen...

programma data -> [network stack] -> #fake adaptor -d encryptie -> [network stack] -> gateway -> internet <- gateway en visa-versa.

in plaats van : programma data -> [networkstack die encryptie regelt] -> gateway -> internet <- Gateway en visa-versa

hoe minder stappen hoe minder overhead, hoe minder belasting op cpu en i/o hoe lager de latency en tegelijk hoe hoger de bandbreedte

[Blokker_1999]

Dat klopt natuurlijk voor elke laadbare module die met de kernel wordt meegeleverd. Maar waar ik mij zorgen om maak is: waar gaan we de grens trekken als we steeds meer in de kernel gaan inbouwen? En lopen we niet het risico dat bepaalde software die 1 persoon (Linus Torvalds) goed vindt, bevoordeelt gaat worden ten aanzien van andere software?

[Sandor_Clegane]

Als het laadbaar is, zit het buiten de kernel. Dit betekend alleen maar dat het standaard meegeleverd wordt met de kernel mocht je het willen.

Het andere dat je noemt is eigenlijk een andere discussie en lijkt een beetje op het ZFS verhaal.

[Qalo]

Ik ben het met je eens dat er zéér terughoudend gedaan moet worden als het gaat om het "opblazen" van de kernel en het liefst zoveel als mogelijk zaken in user-space op te lossen. Maar in dit specifieke geval snap ik wel waarom de keuze is gemaakt om dit op kernelniveau in te bouwen.

Dus ja, ik sta hier wel achter. Mijns inziens wegen de voordelen niet op tegen de nadelen. Ik kan eigenlijk ook geen reden vinden waarom ik dit niet zou willen.

[storeman]

Goede vraag. Ik denk wel dat het een manier is om een bepaalde standaard te pushen. Ik ben zelf net sinds gisteren wat aan het klooien met Wireguard. Het werkt inderdaad erg goed, het is makkelijk op te zetten en te configureren. De performance is fantastisch en de codebase schijnt ook heel goed te zijn.

Lijkt mij wel goed om wireguard te pushen. Bovendien wordt vpn toch steeds belangrijker en hebben steeds meer mensen er behoefte aan.

[Verwijderd]

Lijkt mij wel goed om wireguard te pushen. Bovendien wordt vpn toch steeds belangrijker en hebben steeds meer mensen er behoefte aan.

Dat is wel een beetje het punt: lijkt mij wel goed. Je dringt andere mensen dus een beetje jouw (in dit geval de ontwikkelaar van WireGuard) mening op.

Ik kan het op zich wel snappen, maar ik snap de reacties m.b.t. userspace ook wel. Als de normale distros het gewoon in hun default set van applicaties zetten ben je ook een heel eind toch?

Wat mij betreft is het prima hoor. Ik denk dat de gedachte er achter inderdaad is om iedereen simpel de mogelijkheid te geven om een VPN op te zetten, zonder extra pakketten te hoeven installeren. Daarintegen: als je over 10 jaar de opvolger van WG krijgt: zet je die dan ook in de kernel? En haal je WG er dan uit? Slippery slope...

[tweaknico]

IPSEC zit ook in de kernel. Alleen de key exchange ervan niet.

[MarcoC]

Anderzijds kun je ook redeneren dat er heel veel fragmentatie in het Linux-landschap is waardoor de beperkte resources in de open-source wereld heel vaak bezig te zijn dezelfde functionaliteit te realiseren in verschillende distributies. Haal je zo echt het maximale uit de tijd die vrijwilligers in het onderhouden en verbeteren van de codebase steken?

[Blokker_1999]

Fragmentatie los je hier natuurlijk niet mee op. Dit is gewoon een bijkomende oplossing bovenop de reeds bestaande alternatieven.

https://xkcd.com/927/

[rob12424]

Daar had je in het verleden gelijk in. Maar met de LSB (Linux Standard Base) is daar wel verandering in gekomen.

Behalve de discussie's tussen Wayland en andere zooi (al is Ubuntu ook al van Mir afgestapt)

Init Vs upstart enz.

Sterker nog apt kun je ook gewoon installeren in fedora (of je het wil is een ander verhaal)

[PerlinNoise]

Wireguard moet juist in de kernel draaien vanwege: (oa ook in custom roms in Android Kernel)

• sneller kunnen opzetten van verbinding
• snellere verbinding dan openVPN
• verminderd batterij verbruik
• wisselen tussen wifi/data gaat seamless zonder handmatig opnieuw opzetten verbinding

[aliencowfarm]

Phoronix schrijft vandaag dat WireGuard ook in de standaard Android kernel komt.

[CAPSLOCK2000]

En dan vraag ik me af: hoort zoiets wel thuis in een kernel? Toegegeven, de Linux kernel is al een enorm project, maar moet iets dat al jaren door anderen perfect in user space wordt gedaan ineens deel gaan uitmaken van die kernel? En wat is daar dan de echt toegevoegde waarde van?

Performance.
Je zegt wel dat het perfect in user space is gedaan maar dat is niet zo. Alle vergelijkbaare bestaande VPN-oplossingen zijn significant langzamer en zijn een zware aanslag op je CPU.
We kunnen het er nog over hebben of dat iets te maken heeft met kernel vs userspace, maar ik geef Wireguard hier het voordeel van de twijfel. Dingen in de kernel krijgen is moeilijk, daar begin je niet aan als het niet hoeft.

[Maurits van Baerle]

Ik denk dat er ook sprake is van veranderende ideeën hierover. Nog niet zo heel lang geleden vonden we compressie en encryptie iets voor bestandsniveau, tegenwoordig vinden we het eigenlijk vrij normaal dat bestandssystemen (een niveau lager dus) al compressie en encryptie aan boord hebben.

Aangezien we versleutelde communicatie steeds belangrijker gaan vinden is het helemaal niet zo'n slecht idee om dat op kernelniveau (een niveau lager dus) al te ondersteunen.

[BvdW1978]

Daarover zou je kunnen zeggen dat een goed IPSec-implementatie in de kernel thuis hoort want deel van een standaardconforme netwerkstack (althans voor IPv6). Wireguard staat op zichzelf net als OpenVPN en OpenConnect. Ik vind het een hellend vlak waar voorzichtigheid geboden is. Elke regel code in-tree is weer een potentieel point of failure en een regressierisico. Moet je dat willen? Nee, tenzij. En t.a.v. Wireguard heb ik nog geen heel overtuigende tenzij gehoord die niet buiten de tree oplosbaar is. Linux heeft bewust een instabiele ABI, dan zal het daar nadeel van ondervinden. Eén van die nadelen is de stabiliteit van DKMS. Misschien moet daar dan eens wat meer effort op i.p.v. meer code in-tree brengen die daar strikt genomen niet hoeft te zijn? Dat zou ook een forse vermageringskuur voor de tree kunnen gaan betekenen en dat zie ik persoonlijk wel zitten.

[Verwijderd]

Ik dacht eigenlijk hetzelfde, dit hoort mijn inziens niet in de kernel thuis. Ik vraag mij af wat straks de regel is om iets wel/niet in de kernel te plaatsen. Sterker nog: ik krijg het gevoel het door de strot gedrukt te krijgen.

[teek2]

Ik las dat het juist zo snel en stabiel is omdat het in de kernel zit. Voor sommige systemen is het ook gewoon iets wat er altijd moet zijn, zodra een systeem online gaat. Zoals misschien in een docker. Dan wil je het wel in de kernel, zonder user-land gedoe.

[Verwijderd]

Juist in de kernel maakt het idd zo stabiel. Maar ik vind het persoonlijk een stap te ver gaan. Waarom Wireguard en niet een ander programma? Niets verkeerd over Wireguard, maar Linux heeft nu een stap gemaakt om een Third party te laten samensmelten met de kernel, dus het is nu één geheel. Volgens mij was het gedachtengoed om programma’s naast de kernel te laten lopen in plaats van erin.

[hackerhater]

Voor een VPN heb je sowieso een kernel-deel nodig om alle verkeer over te routen.
Het beheer-deel hoeft inderdaad niet in de kernel, en zal er waarschijnlijk ook niet in zitten, maar het deel dat de daadwerkelijke tunnel maakt?

[Verwijderd]

Een VPN verbinding heb je de kernel voor nodig, een VPN app/programma niet.

[hackerhater]

Klopt, maar onder WireGuard vallen dus beide
Een gui gedeelte dat het instellen doet (dit is userspace), en een kernel-deel dat de eigenlijke VPN-verbinding op zet

[Verwijderd]

Het deel van de kernel wat in staat is een VPN op te zetten zit er al jaren in. Het is wat meer omslachtiger, maar ik vind het prima.

[hackerhater]

Ja er zit al VPN functionaliteit in de kernel, wat een stuk slechter werkt en omslachtiger is.
Wireguard is bedoeld als vervanger voor dit.

[Verwijderd]

Dacht je wellicht dat ik niet kan lezen?

[i-chat]

wiregaurd is zo lean dat verreweg het grootste deel de verbding betreft en niet de vpn app/service.

wiregaurd is grotendeels zo'n app/implementatie die zodanig eenvoudig is dat de snelheidswinst door processor / geheuge / io - gebruik én de verlaging van latency enerzijds opwegen tegen de nadelen van meer software/code in de kernel.
daar kan geen userspace implementatie tegenop.

voor de meeste systemen is de network-stack een van de belangrijkste onderdelen van het OS en het doel waarvoor de machine gebruikt wordt.. denk aan web/mail etc servers die aanzienlijk beter gaan presteren als je ze via wiregaurd kunt verbinden tov ovpn.

een andere tak zou bij deze keuze ook veel baat hebben namelijk video-drivers maar daarvan gaan de ontwikkelingen veelal zo snel dat het teveel manuren zou kosten nom ze constant in tree te updaten. daar zie je dus dat de baten (helaas) niet opwegen tegen de kosten.

[Verwijderd]

Dat geloof ik allemaal wel en nogmaals: ik wil WireGuard helemaal niet afvallen, maar dit hoort mijn inziens niet in de kernel thuis. Een kernel bevat basisfunctionaliteiten, niet complete programma's. Maar goed, dat is de vrijheid van een Linux kernel, iedereen mag er wat van vinden. Ik snap eigenlijk alleen niet hoe Torvalds hier zijn koninklijke zegel op gestampt heeft, als er één is die de kernel zo basic mogelijk wilt houden dan is hij het wel.

[RoestVrijStaal]

Mooi, nu nog out-of-the-box ondersteuning voor defensieve configuratie van NetworkManager (helaas de facto netwerkconfiguratie en -beheer tool binnen linux) voor VPN tunnels.

Zodat je niet allerlei fratsen uit moet halen voor DNS leak preventie, het vermoorden van ipv6, auto-reconnect van VPN-tunnel bij verbinding verbroken en niet de reguliere networkinterface & routes gebruiken als de VPN-connectie faalt.

[Jerie]

Voor Android werkt dit al sinds jaar en dag.

Voor NetworkManager werkt het inmiddels ook: https://blogs.gnome.org/t...eguard-in-networkmanager/

DNS leak preventie kun je gewoon regelen door een DNS server te draaien op de VPN endpoint.

en niet de reguliere networkinterface & routes gebruiken als de VPN-connectie faalt.

Kwestie van firewall instellen.

[tweaknico]

IPv6 is ook ondersteund. En als je daar NAT op wil kan dat ook.
Mixed stack werkt gewoon. Ik draai het al een aantal maanden op m'n mobiel. OpenVPN vrat m'n accu's leeg dus alleen bepaalde toegang na aanzetten VPN en dan netwerk...
Wireguard kan permanent mee draaien.
Alleen heel recente Android heeft de neiging om "weinig" gebruikte software om zeep te helpen... Het frontend van WG is niet erg actief...., maar omleggen ervan stopt wel de tunnels.

[RinuX]

Is WireGuard eigenlijk al eens ge-audit door een betrouwbare partij?

Ik ben benieuwd of dit ook in (thuis) routers terecht gaat komen.

[Trestry]

Rechtstreeks uit het artikel:

"meldt dat in aanloop naar de integratie in Linux 5.6, WireGuard een beveiligingsaudit heeft ondergaan"

[RinuX]

Rechtstreeks uit het artikel:

"meldt dat in aanloop naar de integratie in Linux 5.6, WireGuard een beveiligingsaudit heeft ondergaan"

...and we also had a security firm audit the code. Er staat niet precies door welke partij. Is dat al ergens gepubliceerd?

[DRaakje]

Werkt top, ik gebruik het ivm met mijn pihole en een split tunnel, super snel en alleen dns verkeer (en evt lokaal verkeer gaat erover.)

Voor de mensen die het ook willen doen, ik gebruik een VM, maar heb het ook gebruikt icm een Rpi

1. Install pihole (https://github.com/pi-hol...ne-step-automated-install)
2. Install wireguard (https://pivpn.io/)
3. import the profile op je telefoon middels de qr code
4. pas de profile aan op je telefoon en verander je allowed ips (0.0.0.0/0 aan naar je eigen subnet , in mijn geval: 192.168.0.0/24)

En dan kan je met 1 druk op de knop op je telefoon op je eigen netwerk zitten, terwijl al het internet verkeer gewoon via de normale route gaat.

[johnbetonschaar]

Op iOS is het zelfs nog fraaier, daar heeft de WireGuard app een setting om de tunnel on-demand te activeren zo gauw je van de WiFi thuis afgaat. Ik heb het zo al bijna een jaar lang probleemloos draaien, zo gauw ik de deur uitga gaat de VPN automatisch aan en heb ik overal een versleutelde verbinding met ad-blocking, directe toegang tot mijn computer & NAS thuis, ik kan de lichten etc. aan en uit zetten, de tuin sproeien, enzovoorts. En als ik weer thuiskom gaat de VPN vanzelf weer uit.

Op Android is dit ook mogelijk geloof ik maar volgens een collega kost dat wat meer moeite omdat de WireGuard dit niet standaard ondersteunt en je weer een losse app nodig hebt om de VPN te triggeren als je van WiFi connect/disconnect.

[WoutervOorschot]

Ja dat is echt fantastisch, ik hoop dat dat snel aan de windows variant wordt toegevoegd!

[Mirano]

Ik gebruik het momenteel al i.c.m. Unraid, Wat een fijn pakket. het is binnen een minuut opgezet. Veel mogelijkheden omtrent verschillende connectie types:

https://ipsassets.unraid....3a35d11debf9ba1bf7e7a.png

Setup is makkelijk en veel configuratiemogelijkheden. Gebruik het op mijn telefoon inclusief de app, die kijkt naar de wifi netwerken, indien die ombekend is zet die een remote tunneled access op zodat ik en me adblock heb (Pi-Hole) en veiliger op een ombekend wifi netwerk zit

[Destroyer998]

Wireguard, nog nooit zo simpel tunnels gebouwd!

[TheCeet]

Hoe zit het dan eigenlijk als je momenteel Wireguard hebt draaien naast PiHole op een Raspberry PI?
Mogelijkheid om te updaten of pivpn opnieuw installeren?

[Lamah]

Toevallig gister avond WireGuard geinstalleerd op mn Pi. De installer vroeg of ik de pi-hole als dns wilde gebruiken! Hardstikke simpel.

[pingwim]

Heb WireGuard draaien op een VPS, server Ubuntu 18.04.
Eigen vpn server opgezet via AlgoVPN, inclusief ad-blocker.

Client op Android 8 mobiel. Werkt snel en simpel. Ècht the way forward imho.

[Mayonaise]

Hoe zit het met de privacy ondertussen? Naar wat ik ervan begreep, is dat VPN providers je IP-adres kunnen zien met WireGuard. Lijkt me niet echt slim als je logging wilt voorkomen.

One of the challenges WireGuard faces is to ensure anonymity for VPNs. No single user should be statically allocated a single IP address, neither on a public nor a virtual network. A user’s internal IP address might be discovered by an adversary (through WebRTC, for example), who might then be able to match it with records acquired from a VPN provider (through theft, sale, or legal seizure). A good VPN must be unable to match such an identifier to a single user. Currently, this setup is not easily achieved with WireGuard.

ExpressVPN will be supporting efforts to review and audit the WireGuard code, as we have done in the past with OpenVPN. We will contribute code and report bugs whenever we can and raise security and privacy concerns directly with the development team.

Is dit opgelost? Lijkt me wel belangrijk om dit te melden, want het gaat hier tevens om privacy.

Edit: Dit is dus een security vs privacy geval. WireGuard biedt sterke encryptie aan om je data in transport te beveiligen, maar kan je privacy en identiteit niet waarborgen.

[Reactie gewijzigd door Mayonaise op 23 juli 2024 15:56]

[pingwim]

Ik ben zelf mijn VPN provider.
De locatie (bijv. via ipleak.net) is de locatie van de VPS.

Met fingerprinting etc. kan ik vast worden herkend.
Maar dat is is niet het doel van WireGuard.

[Fuss!]

Jammer dat de Windows client Administrator-rechten vereist om de verbinding op te zetten.
Voorlopig niet echt bruikbaar dus voor gebruikers die beperkte rechten hebben.