Mi intento se basa en eleste tutorial.
Puedo hacer ping desde el espacio de nombres a la red si la interfaz física no está asignada al puente.
# Create namespace
ip netns add namespace1
# Create veth pair.
ip link add veth1 type veth peer name br-veth1
# Associate the non `br-` side with the namespace.
ip link set veth1 netns namespace1
# Give namespace-side veth ip addresses.
ip netns exec namespace1 ip addr add 192.168.1.11/24 dev veth1
# Create a bridge device naming it `br1` and set it up.
ip link add name br1 type bridge
# Turn up the bridge.
ip link set br1 up
# Set the bridge veth from the default namespace up.
ip link set br-veth1 up
# Set the veth from the namespace up too.
ip netns exec namespace1 ip link set veth1 up
# Add the br-veth1 interface to the bridge by setting the bridge device as their master.
ip link set br-veth1 master br1
# Add the physical interface to the bridge
ip link set enp3s0 master br1
# Set the address of the `br1` interface (bridge device) to 192.168.1.10/24 and also set the broadcast address to 192.168.1.255 (the `+` symbol sets the host bits to 255).
ip addr add 192.168.1.10/24 brd + dev br1
# add the default gateway in all the network namespace.
ip netns exec namespace1 ip route add default via 192.168.1.10
# Set us up to have responses from the network.
# -t specifies the table to which the commands should be directed to. By default, it's `filter`.
# -A specifies that we're appending a rule to the chain that we tell the name after it.
# -s specifies a source address (with a mask in this case).
# -j specifies the target to jump to (what action to take).
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
sysctl -w net.ipv4.ip_forward=1
Respuesta1
¡No uses veth + bridge! ¡Usa macvlan!
Estuve luchando con veth + bridge recientemente como tú, afortunadamente encontréeste enlaceesta noche, que dice:
Antes de MACVLAN, si deseaba conectarse a una red física desde una máquina virtual o un espacio de nombres, habría necesitado crear dispositivos TAP/VETH y conectar un lado a un puente y conectar una interfaz física al puente en el host al mismo tiempo. Como se muestra abajo.
Ahora, con MACVLAN, puede vincular una interfaz física asociada con una MACVLAN directamente a espacios de nombres, sin necesidad de un puente.
Y esto es lo que hice:
$ sudo ip netns add ns0
$ sudo ip netns exec ns0 ip link set lo up
$ sudo ip link add macvlan0 link eth0 type macvlan mode bridge
$ sudo ip link set macvlan0 netns ns0
$ sudo ip netns exec ns0 ip link set macvlan0 up
$ sudo ip netns exec ns0 ip addr add 172.29.6.123/21 dev macvlan0
$ sudo ip netns exec ns0 ping 172.29.0.1
PING 172.29.0.1 (172.29.0.1) 56(84) bytes of data.
64 bytes from 172.29.0.1: icmp_seq=1 ttl=64 time=0.360 ms
64 bytes from 172.29.0.1: icmp_seq=2 ttl=64 time=0.412 ms
¡Está funcionando!
Respuesta2
Todo se ve bien hasta los dos últimos comandos (puerta de enlace predeterminada en el espacio de nombres de la red + enmascaramiento en el espacio de nombres principal).
Si omite esas dos, debería tener una configuración en la que la interfaz física esté conectada a dos interfaces internas, una interna 192.168.1.10del puente en el espacio de nombres principal y otra 192.168.1.11en namespace1.
Entonces, esto actúa de la misma manera que tener dos interfaces de red físicas conectadas a la misma subred, una del espacio de nombres principal y otra de namespace. (Puede lograr el mismo efecto con un macvlanpar en lugar de un par veth).
No es necesario reenviar ni enmascarar, y una ruta predeterminada 192.168.1.10desde el espacio de nombres principal es simplemente incorrecta.
Si las rutas son correctas para ambos espacios de nombres (verifique eso), debería poder hacer ping a la otra interfaz y también a cualquier cosa que esté conectada a la interfaz física.
Para realizar pruebas, recomiendo iniciar un xtermetc. en namespace1; luego puedes configurar todo directamente sin tener que escribir ip netns exec namespace1 ip ...todo el tiempo.