Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuard is now in Linus' tree

lists.zx2c4.com

Post reply on HN
Print view View original

161–170 of 293 posts

Re: WireGuard is now in Linus' tree

#161

Post by 867-5309 »

wbl wrote: post #70
lvh wrote: post #40

Earlier quoted context omitted.

The tunnel does not have to encapsulate messages at the same layer as the tunnel itself. Consider this thought experiment: if you send Ethernet frames over WebSockets, what layer is the protocol? My understanding is the Wireguard messages are IP (L3) but the protocol messages itself are UDP (L4) and it seems reasonable to describe Wireguard as a session layer over UDP given how much state and connection information i…

The internet does not use OSI.

this is subject to interpretation

Re: WireGuard is now in Linus' tree

#162

Post by 3xblah »

dirkt wrote: post #158
braindeath wrote: post #25

Earlier quoted context omitted.

In the US for home connections (cable, fiber, DSL) everybody gets an accessible IP address pretty much -- the worst is that some ports are blocked like port 80 or 25. Phones don't get a dedicated IPv4.

In other parts of the World that didn't get as many IPv4 addresses as the US, the standard for home connections is that you DON'T get a public IP address, you get a private IP address behind carrier grade NAT And that's really NAT, not a firewall, so nothing is "blocked". You do get public IPv6 addresses from some ISPs, though.

Finally some truth.

Re: WireGuard is now in Linus' tree

#163

Post by Denvercoder9 »

sammorrowdrums wrote: post #137
numbsafari wrote: post #59

As someone who regularly deals with IPSec in conservative network environments, Wireguard can’t gain broad adoption soon enough, in my opinion. Now that it’s merged into Linus’s tree, any word on it getting an official release and the “this isn’t production ready, so no CVEs” disclaimer going away? EDIT: Further back in the thread, Donenfeld says “Please note that until Linux 5.6 is released, this snapshot is a snaps…

Most likely it'll drop at the kernel release in April I believe.

Yeah, 5.6 will probably be released on the 28th of March or the 5th of April (depending upon whether Linus feels a -rc8 is needed).

Re: WireGuard is now in Linus' tree

#164

Post by acqq »

ZiiS wrote: post #120
johnebgd wrote: post #83

Earlier quoted context omitted.

If you value WireGuard and can spare a few bucks the inventor/maintainer is getting about 1/10th what they publicly ask for to maintain: https://www.patreon.com/zx2c4

I do rely on Wireguard for some personal projects and I can spare a few bucks. However the reality is I can't get to $15/month the minimum tier. I rely on thousands of opensource projects. Upstreaming should help my arguments for adoption at work; they wouldn't think twice.

Apart from knowing that 15 USD monthly is not a minimum possible donation there, please see other possibilities to donate on the official link for donations (also posted here). Patreon is only one of the options.

Re: WireGuard is now in Linus' tree

#165

Post by 3xblah »

marcan_42 wrote: post #84
3xblah wrote: post #79

Earlier quoted context omitted.

Can you be sure that during 4yrs it never changed >1 even for a short time, maybe hours or days, then reverted back

That's not really a thing. The pools are large-ish; the chances of winding back on the same IP after a change are tiny.

Not speaking for all ISPs worldwide.

Re: WireGuard is now in Linus' tree

#167

Post by mongrelion »

ghthor wrote: post #154
adevx wrote: post #150

Fantastic news. I deploy WireGuard to provide a private network (mesh) between VPS servers. Each VPS instance has each other vps as peer. So no single source of failure. I run PostgreSQL with Patroni and GlusterFS over this mesh with no issues. When I add or destroy a VPS with Ansible all VPS nodes get an updated config and reload. This way I don't rely on a single cloud provider because I do not use their private ne…

That's really interesting. So you essentially implemented a Virtual Private Cloud(VPC) on top of the "PHY" network of your hosts? Does that mean that all your nodes have to be accessible to the public internet?

Not necessarily, no. All hosts talk to each other on their private (v)NIC.

Re: WireGuard is now in Linus' tree

#168

Post by ZoomZoomZoom »

imiric wrote: post #138

This is great news, and I'm looking forward to giving it a try once it's released as part of the kernel. I've been using tinc[1] for several years now, and it's been very simple to configure and use. Similarly to WG, it can tunnel over UDP, but also over TCP, supports router or switch modes, NAT traversal, etc. It's a great project, but not very popular and I'm concerned about its maintenance and security issues movi…

As far as I understand, the killer feature of Tinc is automatic mesh routing. You can add a node to one instance and the information spreads through the network, wireguard doesn't do that.

Also, I heard maintainers were contemplating replacing the protocol with Wireguard.

https://www.tinc-vpn.org/pipermail/tinc/2017-February/004755...

Re: WireGuard is now in Linus' tree

#169

Post by tpetry »

bauerd wrote: post #159
adevx wrote: post #150

Fantastic news. I deploy WireGuard to provide a private network (mesh) between VPS servers. Each VPS instance has each other vps as peer. So no single source of failure. I run PostgreSQL with Patroni and GlusterFS over this mesh with no issues. When I add or destroy a VPS with Ansible all VPS nodes get an updated config and reload. This way I don't rely on a single cloud provider because I do not use their private ne…

I used to do the same thing, but adding one node meant I had to reprovision all other nodes so each had an updated config file written and reloaded. I decided I want something akin to DHCP, which seems to be worked on here: https://github.com/WireGuard/wg-dynamic It's still WIP though.

This problem has be prevented me all the time from rolling out wireguard. But how dows wg-dynamic help which seems just to be a DHCP on wireguard implementation? You still have to sent every existing node and updated configuration because you provisoned a new one.

An overlay network on top of wireguard would be really nice. For example you are running a wireguard network on 169.254.0.0/16. So every peer which is assigned an ip address within this range is by configuration of the network allowed to forward packets to another peer in the 169.254.0.0/16 network. So the only things needed to be implemented would be: * an internal routing system to forward packets on some way to the destination * a concept on how peers are found and how they build a secure channel (pre-shared key?)

Edit: A better way would be to have multiple shared secrets for every server. So you could basically assign roles to every server. So if a server has the keys "db" and "middleware" he can communicate with every same in the network for forwarding but the final destination can only be a server which has also one of the keys "db" od "middleware". Maybe such a server would have 2 virtual ips within the subnet, one for it's role for db and for middleware.

Re: WireGuard is now in Linus' tree

#170

Post by rkangel »

_8j50 wrote: post #18

So,curious here: I'v been reading about how the focus these days is to move networking code to userspace because you can squeeze out more PPS performance,does the fact that WC makes use of kernel code heavily give it a performance disadvantage?

You're only half right - projects attempting to achieve very high speed networking (packets per second) go to great lengths to remove the traditional syscall per packet that normal linux networking involves.

One approach to this is to move everything into userspace and take the kernel out of it completely. Another approach used by some projects is to put everything into the kernel and take userspace out of it completely. Either of these approaches remove syscalls.

The kernel isn't an inherently slower place (in some cases it can be faster as you have more control), it is having your network stack split across the kernel/userspace boundary that is slow.

Post reply on HN