В сети / мосте alpine linux veth нет интернета

Question

Я пытался следовать нескольким руководствам, чтобы настроить veth-пару для 2 пространств имен, которые могут взаимодействовать друг с другом в alpine linux. Пока у меня работает связь между пространствами имен, но ни одно пространство имен не может подключаться / пинговать к любому внешнему ip / url.

Вот конфигурация руководств, которую я точно использую:

  ip netns add namespace1
  ip netns add namespace2
  ip netns exec namespace1 ip address show
  ip link add veth1 type veth peer name br-veth1
  ip link add veth2 type veth peer name br-veth2
  ip link set veth1 netns namespace1
  ip link set veth2 netns namespace2
  ip netns exec namespace1 ip address show
  ip netns exec namespace1 ip addr add 192.168.1.11/24 dev veth1
  ip netns exec namespace1 ip address show
  ip netns exec namespace2 ip addr add 192.168.1.12/24 dev veth2
  
  # Create the bridge device naming it `br1`
  # and set it up:
  ip link add name br1 type bridge
  ip link set br1 up
  ip link | grep br1
  
  # Set the bridge veths from the default
  # namespace up.
  ip link set br-veth1 up
  ip link set br-veth2 up
  ip netns exec namespace1 ip link set veth1 up
  ip netns exec namespace2 ip link set veth2 up
  
  # Add the br-veth* interfaces to the bridge
  # by setting the bridge device as their master.
  ip link set br-veth1 master br1
  ip link set br-veth2 master br1
  bridge link show br1
  ip addr add 192.168.1.10/24 brd + dev br1
  ip -all netns exec ip route add default via 192.168.1.10
  iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

Я также убедился, что /etc/sysctl.conf содержит

net.ipv4.ip_forward = 1

и я запустил эту команду также на всякий случай

sysctl -w net.ipv4.ip_forward=1

мой resolv.conf содержит:

nameserver 8.8.8.8

когда я бегу

ip netns exec namespace1 ip route

Получаю результаты:

192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11

Если я запускаю обычный список IP-маршрутов, я получаю:

192.168.56.0 eth0 proto kernel scope link src 192.168.56.217
192.168.1.0/24 dev br1 proto kernel scope link src 192.168.1.10

Я понятия не имею, почему описанная выше настройка не работает, поскольку большинство руководств, кажется, предполагают, что хост и пространства имен должны иметь возможность связываться после выполнения MASQUERADE и установки маршрута по умолчанию для пространств имен, однако работа в сети не является моей основной областью исследования, поэтому любые предложения будут быть чрезвычайно полезным. Если какой-либо информации не хватает, пожалуйста, оставьте комментарий, и я постараюсь предоставить его, если я что-то пропустил.

Answer 1

Я дословно применил вашу настройку, и она работает.

Вы, должно быть, где-то допустили опечатку или не совсем поняли то, что написали в своем вопросе.

Два замечания:

bridge link show br1

неверный синтаксис. man bridgeбыл изменен в последних версиях, вероятно, потому что это была распространенная ошибка:

bridge link show- перечислить конфигурацию портов для всех мостов . Эта команда отображает конфигурацию порта и флаги для всех мостов .

Чтобы отобразить конфигурацию порта и флаги для определенного моста, используйте команду " ip link show master <bridge_device>".

Поэтому вы должны использовать вместо этого:

ip link show master br1

или вы получите дополнительные интерфейсы на других мостах. Конечно, это неважно.

Важно то, что:

  ip -all netns exec ip route add default via 192.168.1.10

должен был установить маршруты по умолчанию в сетевых пространствах имен (и сделал для меня), но вы напишете позже:

когда я бегу

ip netns exec namespace1 ip route

Получаю результаты:

192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11

Здесь отсутствует маршрут по умолчанию. Проделав то же самое в моей системе, я получаю, как и следовало, но не получилось:

# ip netns exec namespace1 ip route
default via 192.168.1.10 dev veth1 
192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11 

Итак, выясните, чего не хватает. Повторно протестируйте свои команды точно так, как указано, вручную, без изменения порядка, и убедитесь, что вы получили маршрут по умолчанию. Например, этот маршрут будет потерян, если интерфейс будет отключен, а затем снова включен (но это не сделано в сценарии OP). При необходимости не используйте -allкоманду, а повторите ее дважды, один namespace1раз для namespace2.

---

ОБНОВЛЕНИЕ: из дальнейшего обсуждения в комментариях выясняется, что у OP были iptables с политикой FORWARD, установленной как DROP.

Если кто-то намеревается включить трафик между пространствами имен (должен быть активирован br_netfilter , см. В конце) и любой исходящий трафик из пространств имен, можно просто использовать, например:

iptables -I FORWARD -i br1 -j ACCEPT

Аналогичным образом, если необходимо, чтобы пространства имен достигли хоста:

iptables -I INPUT -i br1 -j ACCEPT

Об этом действительно стоит подумать, а правила интегрировать в существующее решение межсетевого экрана.

Все может стать более сложным, если работают другие инструменты, такие как Docker, потому что он может включать br_netfilter , как видно из моего ответа на этот вопрос / ответ .