Alpine linux veth network / bridge não tem internet

Question

Tenho tentado seguir vários guias para configurar um par veth para 2 namespaces que podem se comunicar uns com os outros no linux alpino. Até agora, tenho comunicação entre os namespaces funcionando, mas nenhum dos namespaces pode se conectar / fazer ping para qualquer ip / url externo.

Aqui está a configuração dos guias que eu uso exatamente:

  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

Eu também verifiquei que /etc/sysctl.conf contém

net.ipv4.ip_forward = 1

e eu executei este comando também para o caso

sysctl -w net.ipv4.ip_forward=1

meu resolv.conf contém:

nameserver 8.8.8.8

quando eu corro

ip netns exec namespace1 ip route

Eu obtenho os resultados:

192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11

Se eu executar uma lista de rota de IP normal, recebo:

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

Não tenho ideia de por que a configuração acima não funcionará, já que a maioria dos guias parece sugerir que o host e os namespaces devem ser capazes de se comunicar depois de executar o MASQUERADE e definir a rota padrão dos namespaces, no entanto, a rede não é meu campo principal de estudo, então qualquer sugestão seria ser extremamente útil. Se houver alguma informação faltando, por favor sinta-se à vontade para deixar um comentário e tentarei fornecê-lo caso eu tenha perdido algo.

Answer 1

Apliquei sua configuração literalmente e está funcionando.

Você deve ter cometido um erro de digitação em algum lugar ou não seguiu exatamente o que escreveu em sua pergunta.

Duas observações:

bridge link show br1

é uma sintaxe inválida. man bridgefoi alterado em versões recentes provavelmente porque foi um erro comum:

bridge link show- lista a configuração das portas para todas as pontes . Este comando exibe a configuração da porta e sinalizadores para todas as pontes .

Para exibir a configuração da porta e sinalizadores para uma ponte específica, use o ip link show master <bridge_device>comando " ".

Portanto, você deve usar em vez disso:

ip link show master br1

ou você obteria interfaces extras em outras pontes. Claro que não importa.

O que importa é que:

  ip -all netns exec ip route add default via 192.168.1.10

deveria ter definido as rotas padrão nos namespaces da rede (e fez para mim), mas você escreverá mais tarde:

quando eu corro

ip netns exec namespace1 ip route

Eu obtenho os resultados:

192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11

Aqui, a rota padrão está faltando. Fazendo o mesmo no meu sistema, eu recebo, como você deveria, mas não fez:

# 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 

Portanto, descubra o que está faltando. Teste novamente seus comandos exatamente como fornecidos, manualmente, sem alterar nenhuma ordem, e verifique se você obteve a rota padrão. Por exemplo, esta rota seria perdida se a interface fosse desativada e ativada novamente (mas isso não é feito no script do OP). Se necessário, não use, -allmas repita duas vezes o comando, uma vez por namespace1vez para namespace2.

---

ATUALIZAÇÃO: a partir de uma discussão posterior nos comentários, parece também que OP tinha iptables 'com uma política FORWARD definida como DROP.

Se alguém pretende habilitar o tráfego entre namespaces (caso br_netfilter esteja ativado, veja no final) e qualquer tráfego de saída dos namespaces, pode-se simplesmente usar, por exemplo:

iptables -I FORWARD -i br1 -j ACCEPT

Da mesma forma, para que os namespaces alcancem o host, se necessário:

iptables -I INPUT -i br1 -j ACCEPT

A segurança sobre isso realmente deve ser considerada, e as regras integradas na solução de firewall existente.

As coisas podem ficar mais complexas se outras ferramentas como o Docker estiverem em execução, porque ele pode habilitar o br_netfilter , como pode ser visto em minha resposta a esta pergunta / resposta .