Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's all good news.

I'm aware that them blackholing all UDP traffic is always going to be an issue, but it's good to hear that Wireguard recovers gracefully. So, too, does Shadowsocks.

Alternatives are always good, and having something more reflecting a true VPN rather than a SOCKS proxy will be useful once it makes it to Windows.



The really nice thing about WireGuard on Linux is that it acts like a regular network device and thus you can use iptables or network namespaces for free with it. Very clean and genius design that eradicates the need for any client support as well as removing the potential for leaking at the network device level (if you configure it in the "container" mode where you move your host network devices into an inaccessible network namespace and only provide wg0 on the host).


At lot of Linux VPN creates network interfaces (tap/tun), and support namespacing them - you can do the same thing with OpenVPN .

The really nice thing is the full in-kernel implementation, and the lack of configurability.


Right, sorry. I was comparing it to the shadow-socks project GP was referring to. (And the userspace WireGuard implementation uses TUN/TAP. In fact one of the rootless containers subprojects I've worked on is using TAP to allow for unprivileged network bridge emulation for rootless containers.)


I was wondering if the behaviour of recovering gracefully or not gives away if its a (specific) VPN?


VPN fingerprinting is simple in most cases. The preamble to stateful VPN session initiation is generally trivial to detect. WireGuard does not (at this time) attempt to obfuscate itself, but it’s more resistant to that particular type of detection since it does not do such negotiation. So yes, this behavior could be potentially used as a heuristic distinguisher for a deep packet inspection tool.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: