Thread (5 messages) 5 messages, 3 authors, 2011-06-29

Re: [PATCH] iproute2: Add processless network namespace support.

From: Eric W. Biederman <hidden>
Date: 2011-05-27 00:45:17

Chris Friesen [off-list ref] writes:
On 05/26/2011 02:58 PM, Eric W. Biederman wrote:
quoted
The goal of this code change is to implement a mechanism such that it is
simple to work with a kernel that is using multiple network namespaces
at once.

This comes in handy for interacting with vpns where there may be rfc1918
address overlaps, and different policies default routes, name servers
and the like.

Configuration specific to a network namespace that would ordinarily be
stored under /etc/ is stored under /etc/netns/<name>.  For example if
the dns server configuration is different for your vpn you would create
a file /etc/netns/myvpn/resolv.conf.
That would be interesting.  Currently I use dnsmasq to keep my DNS servers
straight when connecting in to two different corporate VPNs simultaneously.

I could see it being interesting trying to remember which shell sessions were
running in which network namespace...
Keeping shells straight is keeping shells straight, and I haven't had
an particular trouble with that.  I can always look at ifconfig or
/etc/resolv.conf if I am wondering which namespace a shell is in.

Now that I think about it there is some ongoing work to test two
network namespaces for identity and as that matures it probably
makes sense to extend this code to add a "ip netns id" command.

For me there has been real benefit in not having to deal with
conflicting default routes, conflicting ip addresses, or conflicting
hostnames (assuming you put all of the right domain names in your search
path), and I don't have to worry about accidentally bridging traffic.

In general I think it is simpler model to get right than natting remote
networks into my own network, using multiple ip tables so I can cope
with multiple default routes, and setting dnsmasq, and a long search
path in resolv.conf so I can resolve host names that are not fully
qualified that might come over the vpn.  Not that there aren't
benefits to doing all of that.

In practice after I had ip patched all it took was a longish openvpn
up-script (an afternoons hack) (so I could move the tap device to the
new network namespace and intercept all of the ifconfig or ip commands
that openvpn would normally run and run them instead in the network
namespace).

Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help