Моя попытка смоделирована по образцуэтот урок.
Я могу выполнить ping из пространства имен в сеть, если физический интерфейс не назначен мосту.
# 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
решение1
Не используйте veth + bridge! Используйте macvlan!
Недавно я боролся с вет + мост, как и вы, к счастью, я нашелэта ссылкасегодня вечером, в котором говорится:
До появления MACVLAN, если бы вы хотели подключиться к физической сети из виртуальной машины или пространства имен, вам пришлось бы создать устройства TAP/VETH и подключить одну сторону к мосту, а также одновременно подключить физический интерфейс к мосту на хосте, как показано ниже.
Теперь с помощью MACVLAN вы можете напрямую привязать физический интерфейс, связанный с MACVLAN, к пространствам имен, без необходимости использования моста.
И вот что я сделал:
$ 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
Это работает!
решение2
Все выглядит хорошо до последних двух команд (шлюз по умолчанию в сетевом пространстве имен + маскировка в основном пространстве имен).
Если вы пропустите эти два, у вас должна быть конфигурация, в которой физический интерфейс соединен мостом с двумя внутренними интерфейсами, один из которых является внутренним интерфейсом 192.168.1.10моста в основном пространстве имен, а другой — 192.168.1.11внутренним namespace1.
Таким образом, это действует так же, как если бы к одной и той же подсети были подключены два физических сетевых интерфейса: один из основного пространства имен, а другой из namespace. (Вы можете добиться того же эффекта, используя macvlanвместо veth-pair).
Ни переадресация, ни маскировка не нужны, а маршрут по умолчанию 192.168.1.10из основного пространства имен просто неверен.
Если маршруты верны для обоих пространств имен (проверьте это), вы сможете выполнить ping на другой интерфейс, а также на все, что подключено к физическому интерфейсу.
Для тестирования я рекомендую запустить xtermetc. в namespace1; тогда вы сможете напрямую все настроить, не печатая ip netns exec namespace1 ip ...все время.