Não há tempo para testá-lo agora com uma imagem de caixa virtual, mas suponho que o seguinte funcione:
Minha suspeita é que o ipvlan
não funciona bem no adaptador de rede da caixa virtual, porque é, bem, virtual.
Então faça do jeito antigo, e use uma ponte real, e veth-pares dos namespaces. Então, algo nas seguintes linhas (não testado):
addr=192.168.56
ip link add br0 type bridge
ip addr add $addr.250/24 dev br0
Em seguida, para cada namespace $1
começando por, digamos, 1:
ip netns add "ns$1"
ip link add "vetha$1" type veth peer name "vethb$1" netns "ns$1"
ip -n "ns$1" link set lo up
ip -n "ns$1" link set "vethb$1" up
ip -n "ns$1" addr add 127.0.0.1 dev lo
ip -n "ns$1" addr add "$addr.$1/24" dev "vethb$1"
ip -n "ns$1" route add default via "$addr.250" dev "vethb$1"
ip link set "vetha$1" master br0
ip link set "vetha$1" up
e finalmente
ip link set vboxnet0 master br0
ip link set br0 up
Agora, a ponte com o endereço 192.168.56.250
está voltada para o host, os endereços 192.168.56.1
, 192.168.56.2
etc. são atribuídos ao namespace e você deve garantir que os clientes do virtualbox obtenham IPs diferentes (ou altere o endereçamento esquema). Os namespaces têm o host como gateway.
Se algo não funcionar, você pode usar ip -n ns0 addr show
etc. para verificar as atribuições de endereço, tcpdump -ni vetha0
etc em uma janela diferente, enquanto ping
ing para ver o que funciona e o que não funciona etc. também pode iniciar um xterm
no namespace para depurar coisas mais diretamente.
Se o acima funcionar, você também pode tentar um macvlan
(muito semelhante ao ipvlan
) ou ipvlan
no modo l3
- estes são um pouco mais eficientes, se a eficiência for necessária, se pode ser feito para trabalhar com o adaptador de rede da caixa virtual. A instalação para ambos está muito próxima do seu script original.