Mein Versuch orientiert sich an derdieses Tutorial.
Ich kann vom Namespace aus einen Ping an das Netzwerk senden, wenn die physische Schnittstelle nicht der Bridge zugewiesen ist.
# 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
Antwort1
Verwenden Sie nicht veth + bridge! Verwenden Sie macvlan!
Ich hatte vor kurzem Probleme mit veth + bridge wie Sie, zum Glück fand ichdieser Linkheute Abend, in dem steht:
Wenn Sie vor MACVLAN von einer VM oder einem Namespace aus eine Verbindung zum physischen Netzwerk herstellen wollten, mussten Sie TAP/VETH-Geräte erstellen, eine Seite an eine Brücke anschließen und gleichzeitig eine physische Schnittstelle an die Brücke auf dem Host anschließen, wie unten gezeigt.
Jetzt können Sie mit MACVLAN eine physische Schnittstelle, die mit einem MACVLAN verknüpft ist, direkt an Namespaces binden, ohne dass eine Brücke erforderlich ist.
Und das habe ich getan:
$ 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
Es funktioniert!
Antwort2
Bis auf die letzten beiden Befehle (Standard-Gateway im Netzwerk-Namespace + Masquerading im Haupt-Namespace) sieht alles gut aus.
Wenn Sie diese beiden überspringen, sollten Sie eine Konfiguration haben, bei der die physische Schnittstelle mit zwei internen Schnittstellen verbunden ist, eine mit der internen 192.168.1.10der Brücke im Hauptnamespace und eine mit der 192.168.1.11in namespace1.
Dies wirkt sich also so aus, als ob zwei physische Netzwerkschnittstellen mit demselben Subnetz verbunden wären, eine aus dem Hauptnamespace und eine aus namespace. (Sie können denselben Effekt mit einem macvlananstelle eines veth-Paares erzielen.)
Weder Weiterleitung noch Maskierung sind erforderlich und eine Standardroute 192.168.1.10aus dem Hauptnamespace ist einfach falsch.
Wenn die Routen für beide Namespaces korrekt sind (überprüfen Sie das), sollten Sie in der Lage sein, die andere Schnittstelle sowie alles, was mit der physischen Schnittstelle verbunden ist, anzupingen.
Zum Testen empfehle ich, ein xtermetc. in zu starten, dann kann man alles direkt konfigurieren, ohne ständig namespace1etwas eintippen zu müssen .ip netns exec namespace1 ip ...