3

I may be using the wrong tool, but network namespaces seemed like a near ideal fit.

I have 3 programs that don't have the ability to specify an listening interface or address (that only listen on "0.0.0.0"). I want to put those services in a netns where they only see the internal addresses (i.e. 192.168.3.0/24), preventing them from listening to external traffic.

I created a netns named 'Local' and created a veth to straddle the main and Local ns's, like: 

ip link add veth1 type veth peer name vpe1

I enslaved veth1 to a local bridge (br0) along with 2 other physical interfaces. "brctl show br0" now shows 3 interfaces: eth0, eth5, and veth1.

Next I set vpe1's IP to "129" on the local net. Testing showed I was able to ping it from other hosts and from a bash-shell in the Local-ns, I was only able to ping hosts on the local net.

However, the progs (one being xinetd) are meant to service calls at the server's local net address (the bridge addr of 192.168.3.1). Having a different IP in the 'local-only' namespace doesn't work for having them respond to services on the 'server'.

Trying a few other options -- I first tried giving the same hostname to the IP for 'vpe1' inside its namespace, then tried giving the same IP... nothing worked or had an effect.

Conceptually, I thought to have a sub netns duplicate the main name space and then drop the external interface from the from it -- leaving those procs only seeing the local interface and servicing requests just as they had before when they saw all the interfaces (and weren't in a namespace).

While this seems to be an ideal place for a separate namespace to give a different logical view of the server's interfaces to a group of processes, I am not seeing how to have the netns's simply provide a different "view" (to use 'bind/named-speak') to those "clients".

Is this possible with linux's net namespaces? Or what are they missing that could allow this? If this type of "sectioning" isn't provided by namespaces, is it possible to provide it without lots of iptable routing to simulate those client-progs being in the main namespace?

Thanks! A☆a

Improve this question

1 Answer 1

Reset to default
0

Linux network namespaces are, simply put, isolated IP stacks. Forgetting about virtual things like network namespaces, just ask yourself: how do I solve my task using routers, hosts, bridge boxes, and Ethernet cables? If you have your physical setup, then it translates almost naturally into its virtual twin. But don't forget about packet filter rules, they might be key.

I don't fully understand what your task really it. But one thing catches my eye, because it might not what you want at all: a bridge where you connect physical network interfaces to, as well as a veth cable into another network namespace (IP stack). That means full layer 2 access to anyone, because of the bridge. IP addresses are of no importance at this level. You give full direct network access to a separate network namespace. This isn't wrong in itself (in fact, I personally know of some extremely useful situations), but is that what you want in your case?

Improve this answer
4
  • I want certain programs to only see the internal nets. Unfortunately, some aren't configurable with addresses or devices to listen on and only listen on 0.0.0.0, or "all". If I put them in their own namespace where only the internal net is visible, I hoped to prevent them seeing outside nets. I mentioned I wanted to avoid iptable changes. I wanted the namespace to duplicate current namespace, and allow me to remove an interface (the outside) vs. creating a new, empty ns, where I can't exactly duplicate what I have due to name+addr conflicts. I'd like the inward-facing procs to use br0.
    – Astara
    Jun 27, 2018 at 22:31
  • That's not possible: you cannot duplicate network namespaces. The terminology might be slightly misleading because namespaces can be created with clone(), but refers to a process itself and not to the namespaces. Each network namespace starts anew with only a loopback interface present.
    – TheDiveO
    Jun 28, 2018 at 5:59
  • Um, if it was easy (generally recognized as and know to be possible), I would not have posted the question. Note, I explained my use case, then I also stated what I would really "want" (or what I "wanted" in italics) - and stated that I couldn't do exactly what I wanted to do due to name+address conflicts (first prob that came to mind). And now you are telling me that what I want isn't possible. I beg to disagree. It really is possible to want such a paradigm. Whether or not such a paradigm can be easily implemented on linux is another matter, which is why I asked here. ;^)
    – Astara
    Jun 29, 2018 at 6:59
  • 1
    It's not about preventing the ability to access other networks, given work, its about existing daemons that listen on 0.0.0.0 / all interfaces. By default those will listen to outside-network connections. If they are automatically isolated in a local namespace that only has internal connections, they won't "automatically" listen to outside connections. This is more about taking pre-existing "dumb" daemons built without interface specification abilities. dumping them into a local-only namespace was desired as a matter of convenience -- not hardenened security.
    – Astara
    Jul 13, 2018 at 21:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .