Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OpenVPN3 support #47

Open
jamesmcm opened this issue Nov 23, 2020 · 2 comments
Open

Add OpenVPN3 support #47

jamesmcm opened this issue Nov 23, 2020 · 2 comments
Labels
enhancement New feature or request important An important issue that should be resolved quickly

Comments

@jamesmcm
Copy link
Owner

--auth-user-pass is no longer supported: https://openvpn.net/openvpn-3-linux-and-auth-user-pass/

Beta available in AUR as openvpn3

@jamesmcm jamesmcm added enhancement New feature or request important An important issue that should be resolved quickly labels Nov 23, 2020
@meldafert
Copy link
Contributor

It might make sense to build against openvpn3, and call it directly: https://github.com/OpenVPN/openvpn3#calling-the-client-api-from-other-languages
(Or possibly dynamically link against it)
That might make the code more readable and/or performant, as we don't have the indirection of having to call bash commands as much.
Also, openvpn3 does not need sudo - if a solution for netns can be found for that too, vopono in general would not require sudo anymore.

@jamesmcm
Copy link
Owner Author

Thanks, I started a backend crate to try to move everything to that approach but haven't had much time to solve the issues atm: https://github.com/jamesmcm/libvopono/blob/master/src/lib.rs (obviously it's nowhere near production-ready or usable, but the network namespace creation via forking works).

I had some difficulties getting rtnetlink to work (to replace the ip link calls), since it uses async Futures, but we need to run it on a forked process to be able to call it inside and outside of the network namespace.

The idea would be to eventually do everything like that, from managing the networking with rtnetlink, network namespaces with unshare() etc. so it can be a much more independent binary. See this issue: #49

Unfortunately I think sudo will still be required (or equivalent capabilities or an suid binary) to set up networking in the namespace with rtnetlink (just like we need it for ip link at the moment), see: https://man7.org/linux/man-pages/man7/netlink.7.html

Only processes with an effective UID of 0 or the CAP_NET_ADMIN capability may send or listen to a netlink multicast group.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request important An important issue that should be resolved quickly
Projects
None yet
Development

No branches or pull requests

2 participants