Vita: simple and fast VPN gateway
github.com
github.com
I used the mode where it supports Ethernet frames to merge the VLANs of two datacenters across the WAN (with some additional ebtables to prevent some kinds of frames) to add the ability to migrate systems from one datacenter to another during a partial outage.
They are documented towards the bottom of http://tinc-vpn.org/security/
Good things take time.
It would also help to know how different it is from OpenVPN, for example, and other VPN options including WireGuard.
I mean it's nice to see another VPN, but it'd be useful to know right off the bat how it compares to existing options.
“~2.5 Mpps (or ~5 Gbps of IMIX traffic) per core on a modern CPU”
Note CPU unspecified in above.
A Xeon-D 1541 (2.1GHz) will do 2.44 Mpps, (Simple IMIX) and a i7-6950X will do 3.27 Mpps running AES-GCM-128 and VPP.
A kernel-based Linux implementation will do a bit under 500 Kpps running the same algorithm.
The keying algorithm seems interesting, and is vaguely Wireguard-like (would be more if it used a public-private keypair).
OpenVPN is slow.
Once I tried to set up a VPN using some odd Windows software (OpenVPN, maybe?) and the results were disastrous. I didn't understand any of the jargon the program used, and I think I didn't get what was its main use case (most certainly it wasn't what I was trying to do, that was creating a local subnet between two computers or two LANs).
Then some months later I tried ZeroTier and was able to understand everything, it seemed a perfect fit.
But still, people call ZeroTier a VPN. So why is it so different? And why does it use a jargon so different?
One use case of a VPN is to connect two local networks together. Another is to have your traffic appear to be coming from a different geographical area.
In some cases you wouldn't want the local networks to be able to speak, like commercial VPN services, for security reasons.
All kinds of "oops" edits: https://github.com/cjdelisle/cjdns/commit/3abe50b8e744f72696... https://github.com/cjdelisle/cjdns/commit/feabb1970fbaecf65c... https://github.com/cjdelisle/cjdns/commit/c51d89431f1fa42955... https://github.com/cjdelisle/cjdns/commit/1b0c999bd2e5988c3f... https://github.com/cjdelisle/cjdns/commit/355d7d77cc82c52bf1... (function args passed in the wrong order)
Some are about extra traffic: https://github.com/cjdelisle/cjdns/commit/8bcfbf227a87020931... https://github.com/cjdelisle/cjdns/commit/0ee9cb7f45b466232b...
Also it's ipv6 only, which took some fussing. Performance was fine, even on rpi. Reestablishing links was slow and sometimes required restarting of the daemon. Daemons would occasionally get wedged. Log output is unconventional and uses a special reader tool (a la adb for android). Occasionally routes wouldn't be chosen right (two home computers would route via an external cloud box), which I'd fix by restarting the right daemons.
I laboriously switched to openvpn (two networks) and haven't worked out all the routing and hotswitching for my roaming phone+laptop yet. Now I'm considering vita, tinc, zerotier, or wireguard. Probably I'll try out zerotier to see if it works out of the box, then try wireguard if I'm going to have to configure it a lot, since it seems like WG is the most unix-toolbox-do-one-thing out of all of them.
cjdns always seems so intimidating when I look at it, Yggdrasil looks super friendly and easy.
Actually, I don't know what are people trying to achieve when they run these things.
Did you had a problem cjdns was solving?
Before, I had to act differently on the laptop based on where I was, and the raspi nodes on my guest wifi couldn't reach the influxdb server that was not exposed to the wifi net.
Hardware:
* Cisco: https://www.cisco.com/c/en/us/td/docs/net_mgmt/vpn_solutions...
* Juniper: https://www.juniper.net/documentation/en_US/junos/topics/top...
Cloud:
* AWS: https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connect...
* Azure: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gatew...
* gcloud: https://cloud.google.com/vpn/docs/concepts/overview
Also, some software environments have better support for IPsec than Wireguard; a glance at the Algo docs (https://github.com/trailofbits/algo) suggests that Windows and OpenWRT are both in this category today.
FWIW, I work for Google, I haven't configured IPsec in forever, and I'll probably reach for Algo first the next time I think I need IPsec; I don't think I have enough endpoints in my home network to need hardware offloading :)
$ cloc WireGuard/ 214 text files. 199 unique files. 73 files ignored.
http://cloc.sourceforge.net v 1.58 T=0.5 s (358.0 files/s, 127864.0 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- C 71 2632 1397 33397 Perl 7 1598 1084 10797 Assembly 5 215 218 3608 C/C++ Header 45 569 544 3159 Bourne Again Shell 6 183 52 1570 Bourne Shell 12 81 97 652 make 7 94 11 576 ASP.Net 14 1 0 254 Go 1 11 5 171 Haskell 3 50 6 170 Javascript 1 15 4 165 HTML 1 20 0 158 Rust 1 13 1 123 C++ 1 3 0 87 Python 1 22 8 64 YAML 2 5 0 37 IDL 1 0 0 5 -------------------------------------------------------------------------------- SUM: 179 5512 3427 54993 -------------------------------------------------------------------------------- $ cloc vita 2309 text files. 2150 unique files. 777 files ignored.
http://cloc.sourceforge.net v 1.58 T=4.0 s (387.5 files/s, 87054.8 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- Lua 730 13869 10822 126870 C 265 6868 5197 72704 Bourne Shell 107 5310 5226 31016 C/C++ Header 218 3439 5976 22485 m4 16 1167 110 10958 Assembly 10 304 14 6802 HTML 14 334 8 5709 Pascal 25 961 54 3519 make 23 367 198 1835 Expect 56 4 0 1042 Python 13 219 174 919 Bourne Again Shell 43 131 72 761 XML 4 0 0 756 CSS 3 21 25 567 Teamcenter def 1 0 0 558 SQL 6 36 54 176 DOS Batch 5 16 4 138 C++ 1 14 0 115 ASP.Net 2 25 0 110 YAML 6 22 2 97 Perl 1 5 3 19 Visual Basic 1 1 0 11 -------------------------------------------------------------------------------- SUM: 1550 33113 27939 287167 --------------------------------------------------------------------------------
These commenters are potential or existing users of X, not the authors of X. The people writing X would never try to argue that people should not write Y.
As for the psychology that drives these sort of statements from HN commenters, that is left as an exercise for the reader. One theory is that some people do not like to make choices. They would rather be told what to do. Alternatives may mean choices must be made.
In this case, Snabb discloses that Vita was funded by NLnet. NLnet once wrote an alternative DNS library and various programs (nsd, drill, unbound, etc.) that I would bet many former BIND users are now happily using. OpenBSD made the switch years ago and NetBSD is making the transition as well.
I think these "Why not use X" comments are a sign of users who dislike decision-making and want to be told what to do. I would bet some commenter was asking "Why not use IPsec?" when Wireguard was being introduced.
Wireguard is of course very Linux-specific. As of today, I still cannot use it reliably on BSD. What that means is that in order to experiment with Wireguard, 3xblah's router has to run Linux not BSD, 3xblah's preferred router OS. I am not anti-Linux, but that choice, being made for me, is significant.
I interpret the configuration choices that GNU/Linux distributions make as being told what to do. With BSD, NetBSD for example, programs that interact with the network are generally off by default. It is up to the user to decide which ones to start. IME, this is different from the Linux distros where programs are pre-configured to start without any input from the user.
Alternatives that work on a variety of OS are helpful for some users.
I think the "Why bother..." questions come from users who cannot be bothered with decision-making. More alternatives may mean more decision-making.
The reaction of these users might be "Why bother developing..." in which case they are upset that now with the arrival of new software they feel there is a choice to be made, or it could be "Why should I switch to..." which signifies they want someone else to make the decision for them.
1. "Why not use [X]" is a perfectly valid question for gaining insight into the merits of new tech. If I have problems that I've solved with [X] and you're now implying that I should use [Y], I want to know what makes [Y] different or better than [X] in your opinion. I want to know what problems you're solving, so I can compare them to mine. I want to know what benefits you're getting that I may not have considered. That's a totally valid approach to understanding a new product.
2. Assuming you aren't solving new problems with [Y] and you're really just directly competing with [X] and I already use [X]... I may be inclined to think it's a waste of effort because I won't get any benefit from your work (I'm already using [X]!). Worse, you could have been making [X] better instead of just competing with [Y]!
Of the two, I think both play a role in the mindset of people making that argument. I'm not very sympathetic to the second, but the first is fine.
You perceive someone is "implying that [you] should use" [Y].
It is as if you believe the mere publication of software is somehow didactic.
As if the author by the mere act of writing and sharing a program is telling you what to do.
If the question in 1. were phrased as something like "How does Y compare with X" then that is not what I am addressing.
I am addressing this idea that someone (who?) is "implying" that you should use Y. What if that was not actually the case and it was just your interpretation?
What if the authors are not telling you what software to use.
What if it was simply a case of a person or group writing some software, e.g., maybe to scratch their own itch, and then publishing it in case others may want to use it.
Keep in mind I am now referring to the general case, e.g., each program source published on Github, not Vita.
It would be interesting if users, without any financial contribution, could tell software authors what programs to write or refrain from writing, but that is not what I see when I look at the large amount of software published on the internet.
If the authors of Vita were getting paid to write it, then I doubt they would view it as "wasted effort".
you got stuck on the work imply and just couldn't come back.
Even assuming they're just sharing their work with the world entirely for generosity (and they're not, it's sitting in a company owned repo and the tag line is literally "Software Bureau. Hire us to work on code.")
Then yes, I'd still say espousing the merits of your product publicly is a pretty strong implication that I should use it. That's also why I expect you to have shared it.
SQLite has 711 times more lines of tests as it does of code.
Does that make it a worse software product?
In security, defects have serious consequences, so it is in best interest of everyone to have the lowest possible complexity, much more so than for other types of software. The only "stricter" category would be software related to operation of equipment whose failure could cause direct physical harm.
Lets look at your counter example. It's smaller than most databases as I advise. Following the other rule, it was untrustworthy by default with developers adding piles of tests to uncover bugs, increase confidence, and make changes with less breakage.. Nonetheless, CompSci papers I read on static analysis and fuzzing often test SQLite finding bugs. Even such a well-tested application still had plenty of bugs over time due to its complexity. Most of which might be just intrinsic to the kind of features they're developing.
Back to VPN's, you want to know it will maintain security policy (esp correct info flows) under all inputs in all states, normal and failure. And if no progress can be made, you want it to fail-safe. So, making it six times larger without a need to is definitely worse than not making it six times larger. The larger product will, based on empirical data like SQLite, have more bugs with more code injections or data leaks following from that. I advise minimal, careful, rigorously-evaluated implementation of a formally-verified protocol. Wireguard is closest to that right now.
[0] http://www.tinc-vpn.org/pipermail/tinc/2017-February/004755....
First while the control plane would be TCP (since it's low traffic), the data plane would then be UDP-only leading to issues where the data plane would not work even though the control plane did. tinc currently starts the data plane out over TCP and migrates it to UDP if it finds it works, and later migrates it back if it discovers it stops working.
Second, wireguard only supports Ethernet frames, while tinc supports Ethernet frames or IP packets depending on the mode. This is useful for, for example, sending a bunch of IEEE 802.1Q VLAN tagged things over the VPN interface. This use case could be migrated to be VXLANs, but it would require breaking the existing tinc contract with its users.
Third, RSA keys are not supported and that is the primary mechanism used in tinc 1.0, it would be a breaking upgrade for all users or require a long migration time where RSA keys were replaced with wireguard compatible ones but both were still supported while wireguard was not used.
ZeroTier is great, but hosting the server is very complicated (I'm not going to stop using it now, since it's so easy and is already set, but it's good to know of alternatives).
Woof, not asymmetric? Is that normal for IPSec? I realize it's never sent over wire, but still makes me nervous.