You could do something like:
find -L /proc/[1-9]*/task/*/ns/net -samefile /run/netns/"$netns" | cut -d/ -f5
Or with zsh:
print -l /proc/[1-9]*/task/*/ns/net(e:'[ $REPLY -ef /run/netns/$netns ]'::h:h:t)
It checks the inode of the file which the /proc/*/task/*/ns/net symlink points to agains those of the files bind-mounted by ip netns add in /...
You can start the OpenVPN link inside a namespace and then run every command you want to use that OpenVPN link inside the namespace. Details on how to do it (not my work) here:
I tried it and it does work; the idea is to provide a custom script to carry out the up and route-up phases of the OpenVPN connection ...
I've always had issues with iptables redirections (probably my fault, I'm pretty sure it's doable). But for a case like yours, it's IMO easier to do it in user-land without iptables.
Basically, you need to have a daemon in your "default" workspace listening on TCP port 8112 and redirecting all traffic to 10.200.200.2 port 8112. So it's a simple TCP proxy.
Interconnecting network namespace with main namespace always bothers me.
The reason I usually create a namespace is because I want it isolated.
Depending on what it is you are trying to achieve with namespaces creating interconnects can defeat that purpose.
But even isolated I still want to poke it over the network, for convenience.
This solution lets you ...
It turns out that you can put a tunnel interface into a network namespace. My entire problem was down to a mistake in bringing up the interface:
ip addr add dev $tun_tundv \
local $ifconfig_local/$ifconfig_cidr \
broadcast $ifconfig_broadcast \
The problem is "scope link", which I misunderstood as only affecting routing. It causes ...
First: I don't think you can achieve this by using 127.0.0.0/8 and/or a loopback interface (like lo). You have to use some other IPs and interfaces, because there are specific things hardwired for 127.0.0.0/8 and for loopback.
Then there is certainly more than one method, but here's an example:
# ip netns add vpn
# ip link add name vethhost0 type veth peer ...
The best that I can offer is to execute the command in one namespace (using the -n shortcut), create each endpoint with the same name, and move one of them into a different namespace in that command:
ip -n mynamespace-1 link add eth0 type veth peer name eth0 netns mynamespace-2
You'll still need to do the other stuff like address assignment (the -n ...
The only bug I see with your code is that you're running the user's command unnecessarily through sh -c when you should just run it directly. Running it through sh -c buys you nothing but it destroys quoting that the user originally put into the command. For example, try this:
sudo /usr/local/sbin/_oob_shim ls -l "a b"
should list a file called a b inside ...
The issue is that you're trying to route a packet from namespace ns_snd through ns_mid to ns_rcv. The kernel is going to treat the namespaces as if they were separate hosts. Meaning you have to configure the kernel to act as a router.
This is rather simple to do:
sudo ip netns exec $NS_MID sysctl -w net.ipv4.ip_forward=1
So what am I missing?
What you're missing is that service communicates with init, essentially escaping the network namespace. The application ends up running in the same network namespace as the init system (by default).
At its core, the problem is that service doesn't just fork and exec the application daemon binary (which would preserve the namespace). ...
Here's the method I followed to find how to understand this problem. Available tools appear usable (with some convolution) for the namespace part, and (UPDATED) using /sys/ can easily get the peer's index. So it's quite long, bear with me. It's in two parts (which are not in the logical order, but namespace first helps explain the the index naming), using ...
ip link has a namespace option, which in addition to a network namespace name, can use a PID to refer a process' namespace. If PID namespaces are shared between the processes, you can move devices either way; it is probably easiest from inside, when you consider PID 1 being "outside". With separate PID namespaces you need to move from outer (PID) namespace ...
To complete the accepted answer, the bridge mode is the easiest way to go, but it's not enough to get the communication.
When the jail instance tries to ping the host, it sends an ARP request to get its IP. Because the host has no macvlan instance, the packet will be transmitted directly on the physical link (the corollary of the bridge mode definition). ...
You can use ip netns exec with bash instead of using nsenter, i.e.:
ip netns enter [namespace name] bash
This will allow you to enter an interactive shell session where the namespace-specific network configuration files are automatically bind-mounted to their default (global) locations (without affecting other sessions).
According to the manual, redirect-gateway def1 doesn't try to replace the default route, it just creates two new ones 0.0.0.0/1 and 184.108.40.206/1. How does not having a default route prevent these from being created?
If OpenVPN were only to override the default gateway it would no longer be able to get to its peer endpoint via that original gateway. So what ...
I was on a similar situation, here is how I work around it.
Some background: I had to span several selenium Firefox instances within namespaces for binding them with different IP addresses. But as you know I was having the error:
Error: Can't open display: localhost:10.0
Instead of working with unix sockets as Marius suggested I have just bound SSHD ...
The error on attempting to create the veth devices is caused by a change of how ip interprets the command line arguments.
The correct invocation of ip to create a pair of veth devices is
ip link add name veth0 type veth peer name veth1
(name instad of dev)
Now, how to get traffic out from the namespace to the VPN tunnel? Since you have only tun devices ...
Connecting to a DBus daemon listening on an abstract Unix socket in a different network namespace is not possible. Such addresses can be identified in ss -x via an address that contains a @:
u_str ESTAB 0 0 @/tmp/dbus-t00hzZWBDm 11204746 * 11210618
As a workaround, you can create a non-abstract Unix or IP socket ...
macvlan interface can be used in different modes which alter how data transmitted between two macvlan instances is treated. The default mode is vepa (Virtual Ethernet Port Aggregation), which possibly is why your setup doesn't work.
Short description of common modes you might want to configure:
vepa data is transmitted over physical interface, for ...
Just look at what is doing ip netns exec test ... in your situation, using strace.
# strace -f ip netns exec test sleep 1 2>&1|egrep '/etc/|clone|mount|unshare'|egrep -vw '/etc/ld.so|access'
unshare(CLONE_NEWNS) = 0
mount("", "/", 0x55f2f4c2584f, MS_REC|MS_SLAVE, NULL) = 0
umount2("/sys", MNT_DETACH) = 0
Let's look into man 5 sysfs:
Each of the entries in this directory is a symbolic link representing
one of the real or virtual networking devices that are visible in
the network namespace of the process that is accessing the directory.
So, according to this manpage, the output of ls /sys/class/net must depend on the network ...
It turned out the trick was to disable ufw:
sudo ufw disable
And then I flushed the iptables and re-added the rules, and re-wrote /etc/resolv.conf after NetworkManager overwrote it for some reason.
Now it all works perfectly.
No, there is not a way to do that. That would break the very concept behind separation of network namespaces. There is one and only one way to "escape" that separation, and it's veth interfaces.
In a little bit more detail, it wouldn't just be a matter of somehow "sharing" a loopback interface between network namespaces. Each network namespace is logically ...
Linux network namespace ip-netns does separate the unix socket and as dbus uses it, it's then not accessible from the new namespace, we could imagine a feature that would leave access to unix socket but this is not implemented as of 05/2019. Unix socket can be watched with netstat -a -p --unix
Alternative solution using socat to proxy the dbus socket, this ...
If you access X11 over UNIX sockets then it should "just work". Apparently UNIX domain sockets are not segregated by network namespace.
Since you are getting an error, then I guess you are using TCP, not UNIX sockets.
To connect to X11 with TCP, you will have to proceed the same way you would in order to access any other network service across network ...
For deluge here is my solution. No need for iptables. Here are the steps:
Start your openvpn tunnel
Create namespace and bring your openvpn tunnel there:
ip netns add $NS
# Wait for the TUN to come up
while [[ $(ip route|grep $TUN|wc -l) == 0 ]]; do sleep 1; done
MY_IP=$(ip addr show $TUN|grep inet|cut -d' ' -f6|cut -d'/' -f1)
# The way you extract gateway ...