I guess the main question is why should I use/trust this above OpenVPN/Tinc or WireGuard etc?
Because you can easily read and understand the code.
Show HN: Encrypted VPN in 2k lines of Go
31–40 of 66 posts
Re: Show HN: Encrypted VPN in 2k lines of Go
#32I guess the main question is why should I use/trust this above OpenVPN/Tinc or WireGuard etc?
Because you can easily read and understand the code.
For what it’s worth, this only really applies to a comparison against OpenVPN or IPSec. WireGuard has similar code complexity and size, and is approximately the same when compared against the incumbent VPN options.
Re: Show HN: Encrypted VPN in 2k lines of Go
#33Earlier quoted context omitted.
Genuine question as I've only dabbled in Go, but I've heard complaints from other dabblers that Go seems to encourage large files rather than breaking things up in a more modular fashion. Is that a reality? Or has the complainer just been unlucky in the code they've viewed?
I have been using Go for about 4 years at work and I would say they have been unlucky with the code they have looked at. You have the freedom to organize your code as you wish, you can easily go from one extreme to the other, one function per file to 1000 in one file. The only thing that isn't encouraged is to have very small packages, for example, if your project ends up split into 10 packages, but each of them is j…
To add some meat onto that: a package should be usable (and reusable) on its own. If you have a package that is a single function or struct, it is unlikely (but still possible!) to be useful on its own and likely requires the context of your other packages to be useful.
Re: Show HN: Encrypted VPN in 2k lines of Go
#34The project structure is fighting againts norms. The author should not have src checked in. They should have their package as the root so it is "go get-able" and does not require the user to alter their GOPATH. To ensure that the proper dependency versions are present, they should vendor the dependencies. I would have opened an issue on GitHub for them, but I am not signed in currently. Cheers on releasing a neat tool.
EDIT: got off my mobile and to a laptop and submitted https://github.com/twitchyliquid64/subnet/issues/3.
Re: Show HN: Encrypted VPN in 2k lines of Go
#35Does this work on Windows? I see the TODO item "Get working on OSX", but if this project could bring x-compatibility on the big 3 platforms (thanks Go!), that could really set it apart.
Re: Show HN: Encrypted VPN in 2k lines of Go
#36Am I reading this correctly in that this uses TLS - and ends up tunneling TCP and UDP over TCP?
Re: Show HN: Encrypted VPN in 2k lines of Go
#37The project structure is fighting againts norms. The author should not have src checked in. They should have their package as the root so it is "go get-able" and does not require the user to alter their GOPATH. To ensure that the proper dependency versions are present, they should vendor the dependencies. I would have opened an issue on GitHub for them, but I am not signed in currently. Cheers on releasing a neat too…
Good job! I'm looking into trying Go soon, is there something you'd recommend looking at for learning the Go ecosystem norms?
Re: Show HN: Encrypted VPN in 2k lines of Go
#38Earlier quoted context omitted.
When I first saw Go I was put off by its syntax, but after giving it a chance I very quickly fell in love with it. I've used C#, Python, Ruby, Java, C, Obj-C, JS and Go for mid-large scale projects. Go is the only language I've ever truly loved; sometimes I even feel like I'm writing poetry (as ridiculous as that may sound). The community is really incredible^, I've yet to encounter anything that didn't have great do…
Genuine question as I've only dabbled in Go, but I've heard complaints from other dabblers that Go seems to encourage large files rather than breaking things up in a more modular fashion. Is that a reality? Or has the complainer just been unlucky in the code they've viewed?
Go definitely prefers modular fashion. But definitely no gratuitous files/packages structure like Java where a dozen packages each with 2-3 files having nothing more than 50 lines of code out of which 30 are comments and imports of another dozen packages.
Unlike Java, Go does not have limitation of having each public class in its own file. So public symbols of any type can be put together in same file if it makes sense. Go prefers arranging code what makes sense for application functionality instead of auto-generated scaffolding like 'handlers', 'utils', 'assets', 'entities' etc like I do in my Java code.
Re: Show HN: Encrypted VPN in 2k lines of Go
#39Does this work on Windows? I see the TODO item "Get working on OSX", but if this project could bring x-compatibility on the big 3 platforms (thanks Go!), that could really set it apart.
I'm afraid not :/ Windows is a whole new kettle of fish to get working - you need a device driver to emulate TUN/TAP.
That said, I'm using a library called Water for the low-level networking, and that library just added support for Windows. Implementing full windows support only requires you to implement a few network methods (such as helpers_linux.go) - PRs welcome :)
Re: Show HN: Encrypted VPN in 2k lines of Go
#40Related: Wireguard is a new VPN for linux in 4k lines of C https://www.wireguard.com/ the model of wireguard has been proven correct by formal methods. Builds on modern crypto, and they kept code short for auditing purposes.
My concern is that 'built on modern crypto' and 'reviewed by cryptographers' amounts to 'rolled our own crypto'. IMHO history has shown us time and time again that this is a bad idea - we should use the protocols and ciphers that have stood the test of time. Building subnet using TLS was an architectural choice to avoid playing the role of cryptographer and inevitably getting it wrong.