Onion routing wireguard

[JeWe37]

One of the things that are made especially easy by using namespaces is to layer multiple wireguard connections inside of one another. Normally stacking VPN connections like this is done through things like having multiple separate VPN gateways that are each using each other, but namespaces make this far simpler and eliminate the need for having multiple VMs or the like.

Stacking VPN connections like this allows for potentially enhanced security, as there are now additional points of failure.

This PR adds this functionality to the services. It can be used by simply adding further wireguard connection information to the first 5 keys in the config file, each being separated by a space.

Submitting this as WIP as I have yet to fix up the documentation, but as my bash is... lacking to say the least I'd appreciate some comments wrt any potential issues that might arise from this implementation.

My branch also includes the deactivation of the tunnel from your other branch, as that would be handy for my usecase. If there is any reason you do not want to merge that alongside this functionality already I can rebase everything. Same applies if you require a cleaner commit history.

Performance is not horrible with good VPN providers actually. 250Mb/s+ are possible(My home connection is 1Gb/s). It could be better and I do think some tuning to the MTUs could further improve what I'm seeing but it's certainly far better than the likes of TOR even when also using 3 layers.

[JeWe37]

Previously the speeds were rather bad as a result of incorrectly set MTUs, that has now been resolved. Everything is handled automatically and you can set the top level MTU in the config file. This way I am seeing a very reasonable amount of overhead, around 10% per additional VPN layer, on my connection something like 600Mbps for 3 layers.

[chrisbouchard]

Finally getting a chance to look this over. Thanks for the contribution and for being patient. 👍

[chrisbouchard]

I've looked over the code changes, and they seem reasonable. Just a couple small comments.

One higher-level thought: Do we need to solve the onion routing configuration with shell script, or could we solve it more generally by making the systemd config more generic. E.g., if we turned the service into a template service, could we create a set-up where each layer depends on the netns created by the previous layer.

If we could solve the problem that way, I feel like it would be nicer. That would give each layer its own config, rather than having to line up values by index.

[JeWe37]

I think an architecture relying more heavily on systemd is definitely possible... I suppose you could have the part that creates subsequent namespaces be executed inside of the previously created namespaces. Main issue I can think of is that the MTUs couldn't be set automatically as they are currently, but that would be a rather minor drawback. Perhaps this is an idea for the future, but I think I'll fix up this version here first of all.

[chrisbouchard]

Would you be willing to make a merge request with just the MTU changes for a one-layer VPN? I'd be very willing to merge that, and I think it will be necessary with any approach. I'll also merge my open pull request to disable the tunnel. I'd like to think a little more before committing to a path with onion-layering.

[chrisbouchard]

Thanks for splitting that off. I'll try to wrap my head around onion routing.

[JeWe37]

Now testing with actual VPNs I've noticed a few issues still. I've got it fixed and will see about cleaning up the fixes and committing them.

I've looked over the code changes, and they seem reasonable. Just a couple small comments.

One higher-level thought: Do we need to solve the onion routing configuration with shell script, or could we solve it more generally by making the systemd config more generic. E.g., if we turned the service into a template service, could we create a set-up where each layer depends on the netns created by the previous layer.

If we could solve the problem that way, I feel like it would be nicer. That would give each layer its own config, rather than having to line up values by index.

This is somewhat complicated by #9, because we cannot use the namespace joining anymore, after all many VPN providers give domain name end points. Therefore I'm not fully sure that solution is all that viable.