La red / puente alpine linux veth no tiene internet

Question

He estado tratando de seguir varias guías para configurar un par veth para 2 espacios de nombres que pueden comunicarse entre sí en alpine linux. Hasta ahora tengo comunicación entre espacios de nombres funcionando, pero ninguno de los espacios de nombres puede conectarse / hacer ping a ninguna ip / url externa.

Aquí está la configuración de guías que utilizo exactamente:

  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

También he verificado que /etc/sysctl.conf contiene

net.ipv4.ip_forward = 1

y he ejecutado este comando también por si acaso

sysctl -w net.ipv4.ip_forward=1

mi resolv.conf contiene:

nameserver 8.8.8.8

cuando corro

ip netns exec namespace1 ip route

Obtengo los resultados:

192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11

Si ejecuto una lista de rutas IP regular, obtengo:

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

No tengo idea de por qué la configuración anterior no funcionará, ya que la mayoría de las guías parecen sugerir que el host y los espacios de nombres deberían ser capaces de comunicarse después de realizar MASQUERADE y establecer la ruta predeterminada de los espacios de nombres; sin embargo, las redes no son mi campo principal de estudio, por lo que cualquier sugerencia sería ser extremadamente útil. Si falta alguna información, no dude en dejar un comentario e intentaré proporcionarla en caso de que me haya perdido algo.

Answer 1

Apliqué su configuración literalmente y está funcionando.

Debe haber cometido un error tipográfico en alguna parte o no siguió exactamente lo que escribió en su pregunta.

Dos observaciones:

bridge link show br1

es una sintaxis no válida. man bridgefue enmendado en versiones recientes probablemente porque fue un error común:

bridge link show- Lista de configuración de puertos para todos los puentes . Este comando muestra la configuración del puerto y los indicadores de todos los puentes .

Para mostrar la configuración del puerto y los indicadores de un puente específico, use el ip link show master <bridge_device>comando " ".

Entonces deberías usar en su lugar:

ip link show master br1

o obtendría interfaces adicionales en otros puentes. Por supuesto que no importa.

Lo que importa es que:

  ip -all netns exec ip route add default via 192.168.1.10

debería haber establecido rutas predeterminadas en los espacios de nombres de la red (y lo hizo por mí), pero escribe más tarde:

cuando corro

ip netns exec namespace1 ip route

Obtengo los resultados:

192.168.1.0/24 dev veth1 proto kernel scope link src 192.168.1.11

Aquí falta la ruta predeterminada. Al hacer lo mismo en mi sistema, obtengo, como debería haberlo hecho, pero no lo hizo:

# 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 

Así que averigua qué falta. Vuelva a probar sus comandos exactamente como se le dieron, manualmente, sin cambiar ningún orden, y verifique que obtenga la ruta predeterminada. Por ejemplo, esta ruta se perdería si la interfaz se baja y luego se vuelve a activar (pero no se hace en el script de OP). Si es necesario, no lo use, -allpero repita dos veces el comando una vez por namespace1una namespace2.

---

ACTUALIZACIÓN: a partir de una discusión adicional en los comentarios, también parece que OP tenía iptables 'con una política FORWARD establecida como DROP.

Si uno tiene la intención de habilitar el tráfico entre espacios de nombres (si se activa br_netfilter , consulte al final) y cualquier tráfico saliente de los espacios de nombres, simplemente podría usar, por ejemplo:

iptables -I FORWARD -i br1 -j ACCEPT

Del mismo modo, para que los espacios de nombres lleguen al host si es necesario:

iptables -I INPUT -i br1 -j ACCEPT

Realmente se debe considerar la seguridad sobre esto, y las reglas integradas en la solución de firewall existente.

Las cosas pueden llegar a ser más compleja si otras herramientas como estibador se están ejecutando ya que podría permitir a br_netfilter , como se puede ver en mi respuesta a esta Q / A .