Re: OpenVPN isolation using NetworkNamespaces



On Tue, 2016-03-29 at 13:13 +0200, Stjepan Groš wrote:
On 29.03.2016 12:52, Thomas Haller wrote:
On Sat, 2016-02-27 at 09:34 +0100, Stjepan Groš wrote:
Hi!
Hi Stjepan,

after the changes done to master, I took your MIF branch, and re-
merged 
master into it. The result is here:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=t
h/mif

I didn't actually test it, so don't expect it to work.


Anyway, I hope it might be useful for you.
Thomas
 
Hi Thomas,

thanks for the merge. I'll take a look at it.

In the last few days I also managed to merge HEAD with MIF branch and
to remove some stuff that probably will not be needed (like
activating specific network namespaces from within
NMNetnsController). I have to admit that on several occasions I was
thinking of throwing everything away and starting from scratch, but
that wouldn't take me far...

I think for prototyping this is fine. We should identify places that
can be individually fixed on master to prepare master for namespace
support. Kinda making small steps on master to move it towards the
namespace branch.


Anyway, I just pushed all the changes I have to GitHub. Quick test
shows that NM works. 

I hit the following obstacles/problems/things:

Oh, I see.



1. I have yet to try to figure out how did you intend
NMPlatform/NMPNetns to work in order to better integrate that into
MIF Branch. (maybe your merge will help here)

2. You create singleton NMPlatform object while network namespace
support needs many. So, how/where/what to do.

Currently on master there is only one NM_PLATFORM_GET instance. But in
your branch, you will create multiple platform instances.


3. How to create new network namespace from outside of NMPlatform
object.

There are two separate things: NMPNetns and NMNetns.

NMPNetns is a very simple object to hold the file descriptor of the
namespace, it does setns() and you can use nmp_netns_new() to create a
new namespace (unshare).

NMNetns is a higher level object to represent the namespace. It is not
concerned with unshare()/setns() or the file descriptor. It consists of
instances of NMPNetns, NMPlatform, NMRouteManager, NMPolicy(?), etc.
As in your branch, it also takes over some work from NMManager.

On the higher layer you don't need to switch to a namespace -- that's
why I dropped nm_netns_controller_activate_netns(). When a lower layer
object does something for which it needs a certain namespace, it must
switch itself (via its NMPNetns instance).


4. When creating new network namespace in NMPlatform NETLINK sockets
are created, but before they are created network namespace has to be
switched.

NMPlatform *
_create_new_platform_in_new_namespace ()
{
    NMPNetns
*netnsp;
    NMPlatform *platoform;

    /* create a new namespace and switch to it */
    netnsp = nmp_netns_new ();
    if (!netnsp)
        return NULL;

    /* create a new platform instance in the new namespace */
    platform = nm_linux_platform_new();

    /* return to the previous namespace: */
    nmp_netns_pop (netnsp);

    /* The namespace is also referenced by the platform instance.
       Depending on what we want, we can drop our reference at this 
       point. It's still accessible via nm_platform_netns_get(). */
    g_object_unref (netnsp);
    return platform;
}



5. NMPolicy isn't singleton any more, and it is not tied to NMManager
object but to the NMNetns object.

I didn't really understand what to do with policy. NMPolicy is mostly
concerned about the default-route and resolv.conf. Do you even need
that in other namespaces? Maybe it should only exist in the main
namespace.



6. Certain aspects of NMManager are global for every network
namespace, others are not. For example, sleeping state (or should it
be separate for every network namespace so that some network
namespaces can be suspended?).

7. Related to 7, the best approach would be to refactor NMManager
itself, but that would make very hard to keep HEAD and MIF branches
in sync.

Right, this was the biggest confusion I had. Your NMNetns takes over
some work of NMManager, while NMManager is global. I guess that makes
sense.
But currently it's unclear which instance (NMManager,
NMNetnsController, NMNetns, NMPolicy) does what, and how the interact
with namespaces.

I think this is difficult to get right. I think that NMNetns should be
as simple as possible and more tell NMManager what to do.



Anyway, I got to the step where I can invoke D-Bus method to create
new network namespace and I have to debug that use case now.


Thomas

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]