Esta é uma questão muito complexa, muito antiga, envolvendo várias áreas diferentes, especificamente VETH, Namespaces de Rede, ARP, tabelas de rotas e NAT ...
Estou adicionando a resposta a este problema não apenas para o OP, mas para outras pessoas, esperançosamente salvar alguém dos cabelos grisalhos que isso me deu ...
Basta dizer que, depois de muita pesquisa e teste, os pares de veth podem ser exatamente usados desta forma , já que são literalmente dois virtual > interfaces. No entanto, porque eles são virtuais - você encontrará alguns problemas realmente estranhos em relação a tabelas / entradas ARP. Depois de várias semanas lidando com esse cenário exato (necessário para o trabalho), descobri exatamente como fazer isso e, no processo, aprendi muito mais sobre ARP, NAT e roteamento do que eu queria. Para realizar exatamente o que você deseja, digite o seguinte (no meu caso, Ubuntu 16.04). Por favor note que uma vez que você esteja no namespace test , você terá que sair do bash para sair, já que tudo (tabelas de rotas, iptables, etc) é diferente daquele da máquina host. Eu normalmente abro dois terminais, um que fica no host - o outro que fica no namespace do convidado.
Prefácio
# Tell the system we want to support IPv4 forwarding
add/verify that the following is in '/etc/sysctl.conf'
'net.ipv4.ip_forward = 1'
# if it wasn't there, reparse syscrtl + restart networking
sysctl -p;
/etc/init.d/networking restart;
CONFIGURAÇÃO DO HOST
# create a veth pair
ip link add name vHOST type veth peer name vGUEST
# choose a private MAC address and private IP address
ifconfig vHOST hw ether 02:1d:8d:dd:0c:61
ifconfig vHOST 10.11.0.1/24 up
# have to setup routes FROM HOST -> GUEST
ip route add 10.111.0.0/24 via 10.11.0.1 dev vHOST # gateway
# have to explicitly assign what the MAC is for the vGUEST in the vHOST interface ARP table
arp -i vHOST -s 10.111.0.1 02:1d:8d:dd:0c:60 # vGUEST ip + mac address
# We must tell vHOST-vGUEST "tunnel", vHOST side that it's not a REAL bridge, so any ARP requests must be answered by vHOST
echo 1 > /proc/sys/net/ipv4/conf/vHOST/proxy_arp
# setup forwarding + NAT (so packets can come back)
iptables -A FORWARD -s 10.111.0.0/24 -o vHOST -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.111.0.1 -j SNAT --to 192.168.42.124
CONFIGURAÇÃO DE CONVIDADOS
# create the "test" namespace, so we can verfiy settings
ip netns add test
# add vGUEST "interface" to the "test" namespace
ip link set vGUEST netns test
# enter the "test" namespace with a bash shell
ip netns exec test bash
# choose a private MAC address and private IP address
ifconfig vGUEST hw ether 02:1d:8d:dd:0c:60
ifconfig vGUEST 10.111.0.1/24 up
# have to setup routes FROM GUEST -> HOST
ip route add default via 10.111.0.1 dev vGUEST # gateway
# have to explicitly assign what the MAC is for the vHOST in the vGUEST interface ARP table
arp -i vGUEST -s 10.11.0.1 02:1d:8d:dd:0c:61 # vHOST ip + mac address
agora, o GUEST / HOST pode fazer ping entre si e o vGUEST pode fazer ping fora da máquina
De nota especial, multimac também pode fazer exatamente a mesma coisa que veth, de uma maneira um pouco diferente, como o multimac suporta um relacionamento de muitos para um, onde veth é um relacionamento de um para um.
Para suportar isso em sem namespaces , você tem que usar o policy routing (que é um pouco mais complexo que namespaces de rede)