netconfig: Add support for configuring tun/tap interface in a Linux network namespace (netns)

[orivej]

This was submitted to [email protected], but was not discussed.

---

I would like a Linux system using OpenVPN client to support:

1. Running applications that have network access via OpenVPN tun/tap interface, but no network access via the underlying interface (when OpenVPN interface goes down for any reason and brings down its routes).
2. Running applications that have network access only via the underlying interface, even when OpenVPN tun/tap interface is up.
3. Chaining OpenVPN clients (tunnel in tunnel).

All this is easily achievable with the help of Linux network namespaces: one just needs to run OpenVPN in the namespace with the underlying interface, but configure tun/tap in another namespace. Then applications in the first namespace will not see OpenVPN at all, and applications in the second namespace will not see the underlying interface; and to chain OpenVPN clients, one just runs the second client in the second namespace with its tun/tap in the third one, and so on.

Here is an almost complete implementation of this idea. The only thing missing is that redirect_default_route_to_vpn() fails because it "Cannot read current default gateway from system" and I am not sure about the proper fix. (It should just set the new gateway as the default.)

To use OpenVPN with namespaces, just add some, and specify --dev-netns option. Assuming VPN server provides internet access:

ip netns add abc
openvpn --config CONFIF --dev-netns /run/netns/abc
# List routes.
ip -n abc route
# Add default, as long as redirect_default_route_to_vpn() cannot do it.
ip -n abc route add default via XXX
ip netns exec abc ping 8.8.8.8

---

I am aware of http://www.naju.se/articles/openvpn-netns and http://www.naju.se/articles/openvpn-netns, but these scripts are very ad-hoc and fragile, e.g. they do not support buth tun and tap devices, and their only purpose is to reimplement what do_open_tun() does after the kernel wipes all its work when the interface is moved into another namespace.

[orivej]

This can be regarded as the continuation of #13

[cron2]

Hi,

On Tue, Aug 09, 2016 at 05:48:16AM -0700, Orivej Desh wrote:

This was submitted to [email protected], but was not discussed.

Because it does not belong to the users list.

If you want feedback from developers, please use [email protected]

gert

USENET is not the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected]

[cron2]

On the technical merits: I can see that it would be nice to have something like that, but the implementation needs to be flexible enough to handle other platforms and/or other approaches on Linux as well (like, routing tables as in #13, or the equivalent on OpenBSD and FreeBSD, etc.).

This is basically why nothing much has happened in that area yet - proposed patch sets where much too narrow minded ("it works for MY use case"), and none of the core developers had enough spare time to pick it up and make generic enough that it's worth supporting in the future.

New code of such complexity will need to be maintained and tested(!!) for the future lifetime of the project, so it needs to serve more than a single use case/single platform.

(In the end it would be me or @schwabe who gets to maintain this)

[orivej]

When you say that the implementation needs to be flexible enough for other platforms and approaches, I am not sure implementation of what are we talking about, since this patch implements network interface configuration in a separate Linux network namespace, and AFAIK there are none of them on other platforms. If OpenVPN would support setfib on FreeBSD that (on the first glance) is used much like setns on Linux, it would be integrated into the same two places of the do_open_tun and do_close_tun functions, but the configuration option would be named differently from dev-netns. If OpenVPN would support distinct routing tables on Linux, that option could be named the same as on FreeBSD, but the implementation would have nothing in common with that of setns and setfib. (Except that the changes for redirect_default_route_to_vpn() to support empty routing tables would be useful in that case too.) So, is there a path forward with this patch?

[cron2]

Hi,

On Wed, Aug 10, 2016 at 01:05:09AM -0700, Orivej Desh wrote:

When you say that the implementation needs to be flexible enough for other platforms and approaches, I am not sure implementation of what are we talking about, since this patch implements network interface configuration in a separate Linux network namespace, and AFAIK there are none of them on other platforms.

This squares the issue nicely: it's quite a bit of code to solve the problem ("put applications into a separate routing 'thing'") in a very specific way ("linux name spaces").

We should see that this can be implemented in a way that linux routing table instances, FreeBSD fib setting, etc, are all covered (or "can be added") so it would solve the "problem" on a wider range of platforms.

gert

USENET is not the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected]

[dsommers]

I agree that we should aim for generic cross-platform approaches, but Linux and *BSD are not developed along the same goals. And considering the adoption of Linux containers (and in particular Docker), we should consider better support for netns - which is what Linux containers do use to provide separate network stacks in each container. Having a possibility to manage VPN tunnels for containers outside the container is something which allows transparent cross-data-centre links for hosting providers.

I have not had enough time to dig into these patches in this PR yet, so I can't say much more. But we do need to have a more thorough discussion of features future OpenVPN releases should include. That is something we can start looking into after 2.4 is out the door, though.

[cron2]

hi,

On Wed, Aug 17, 2016 at 09:59:57AM -0700, David Sommerseth wrote:

I agree that we should aim for generic cross-platform approaches, but Linux and *BSD are not developed along the same goals. And considering the adoption of Linux containers (and in particular Docker), we should consider better support for netns - which is what Linux containers do use to provide separate network stacks in each container. Having a possibility to manage VPN tunnels for containers outside the container is something which allows transparent cross-data-centre links for hosting providers.

I'm not saying we should not support netns - but we must do it in a sane way, so that other platforms with different approaches to network isolation/virtualization (like BSD) can be implemented without making the code more of a mess than it already is.

In #13, work is already going on, anyway :-)

gert

USENET is not the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected]

[ordex]

supporting net namespaces would be very nice! However this PR is now obsolete and should be reimplemented. We now have a networking API which could be extended for the purpose.

Should anybody be willing to work on this task, please send the resulting patch to the mailing list.