Puente de contenedores LXC para alojar eth0 para que puedan tener una IP pública

8

ACTUALIZAR:

Encontré la solución allí: http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#No_traffic_gets_trough_.28except_ARP_and_STP.29

 # cd /proc/sys/net/bridge
 # ls
 bridge-nf-call-arptables  bridge-nf-call-iptables
 bridge-nf-call-ip6tables  bridge-nf-filter-vlan-tagged
 # for f in bridge-nf-*; do echo 0 > $f; done

Pero me gustaría tener opiniones de expertos sobre esto: ¿es seguro deshabilitar todo bridge-nf- *? ¿Para qué están aquí?

FIN DE ACTUALIZACIÓN

Necesito conectar los contenedores LXC a la interfaz física (eth0) de mi host, leyendo numerosos tutoriales, documentos y publicaciones de blog sobre el tema.

Necesito que los contenedores tengan su propia IP pública (que anteriormente hice KVM / libvirt).

Después de dos días de buscar e intentar, todavía no puedo hacer que funcione con contenedores LXC.

El host ejecuta un Ubuntu Server Quantal recién instalado (12.10) con solo libvirt (que no estoy usando aquí) e lxc instalado.

Creé los contenedores con:

lxc-create -t ubuntu -n mycontainer

Entonces también corren Ubuntu 12.10.

El contenido de / var / lib / lxc / mycontainer / config es:


lxc.utsname = mycontainer
lxc.mount = /var/lib/lxc/test/fstab
lxc.rootfs = /var/lib/lxc/test/rootfs


lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.veth.pair = vethmycontainer
lxc.network.ipv4 = 179.43.46.233
lxc.network.hwaddr= 02:00:00:86:5b:11

lxc.devttydir = lxc
lxc.tty = 4
lxc.pts = 1024
lxc.arch = amd64
lxc.cap.drop = sys_module mac_admin mac_override
lxc.pivotdir = lxc_putold

# uncomment the next line to run the container unconfined:
#lxc.aa_profile = unconfined

lxc.cgroup.devices.deny = a
# Allow any mknod (but not using the node)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
#lxc.cgroup.devices.allow = c 4:0 rwm
#lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm
#fuse
lxc.cgroup.devices.allow = c 10:229 rwm
#tun
lxc.cgroup.devices.allow = c 10:200 rwm
#full
lxc.cgroup.devices.allow = c 1:7 rwm
#hpet
lxc.cgroup.devices.allow = c 10:228 rwm
#kvm
lxc.cgroup.devices.allow = c 10:232 rwm

Luego cambié mi host / etc / network / interfaces a:


auto lo
iface lo inet loopback

auto br0
iface br0 inet static
        bridge_ports eth0
        bridge_fd 0
        address 92.281.86.226
        netmask 255.255.255.0
        network 92.281.86.0
        broadcast 92.281.86.255
        gateway 92.281.86.254
        dns-nameservers 213.186.33.99
        dns-search ovh.net

Cuando intento la configuración de la línea de comandos ("brctl addif", "ifconfig eth0", etc.) mi host remoto se vuelve inaccesible y tengo que reiniciarlo.

Cambié el contenido de / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces a:


auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 179.43.46.233
        netmask 255.255.255.255
        broadcast 178.33.40.233
        gateway 92.281.86.254

Mycontainer tarda varios minutos en iniciarse (lxc-start -n mycontainer).

Traté de reemplazar 

        gateway 92.281.86.254
por:

        post-up route add 92.281.86.254 dev eth0
        post-up route add default gw 92.281.86.254
        post-down route del 92.281.86.254 dev eth0
        post-down route del default gw 92.281.86.254

Mi contenedor se inicia al instante.

Pero sea cual sea la configuración que configuré en / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces, no puedo hacer ping desde mycontainer a ninguna IP (incluida la del host):


ubuntu@mycontainer:~$ ping 92.281.86.226 
PING 92.281.86.226 (92.281.86.226) 56(84) bytes of data.
^C
--- 92.281.86.226 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5031ms

Y mi host no puede hacer ping al contenedor:


root@host:~# ping 179.43.46.233
PING 179.43.46.233 (179.43.46.233) 56(84) bytes of data.
^C
--- 179.43.46.233 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

El ifconfig de mi contenedor:


ubuntu@mycontainer:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 02:00:00:86:5b:11  
          inet addr:179.43.46.233  Bcast:255.255.255.255  Mask:0.0.0.0
          inet6 addr: fe80::ff:fe79:5a31/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:64 errors:0 dropped:6 overruns:0 frame:0
          TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4070 (4.0 KB)  TX bytes:4168 (4.1 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:32 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2496 (2.4 KB)  TX bytes:2496 (2.4 KB)

El ifconfig de mi host:


root@host:~# ifconfig
br0       Link encap:Ethernet  HWaddr 4c:72:b9:43:65:2b  
          inet addr:92.281.86.226  Bcast:91.121.67.255  Mask:255.255.255.0
          inet6 addr: fe80::4e72:b9ff:fe43:652b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1453 errors:0 dropped:18 overruns:0 frame:0
          TX packets:1630 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:145125 (145.1 KB)  TX bytes:299943 (299.9 KB)

eth0      Link encap:Ethernet  HWaddr 4c:72:b9:43:65:2b  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3178 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1637 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:298263 (298.2 KB)  TX bytes:309167 (309.1 KB)
          Interrupt:20 Memory:fe500000-fe520000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:300 (300.0 B)  TX bytes:300 (300.0 B)

vethtest  Link encap:Ethernet  HWaddr fe:0d:7f:3e:70:88  
          inet6 addr: fe80::fc0d:7fff:fe3e:7088/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:54 errors:0 dropped:0 overruns:0 frame:0
          TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4168 (4.1 KB)  TX bytes:4250 (4.2 KB)

virbr0    Link encap:Ethernet  HWaddr de:49:c5:66:cf:84  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

He deshabilitado lxcbr0 (USE_LXC_BRIDGE = "false" en / etc / default / lxc).


root@host:~# brctl show
bridge name     bridge id               STP enabled     interfaces                                                                                                 
br0             8000.4c72b943652b       no              eth0                                                                                                       
                                                        vethtest

He configurado la IP 179.43.46.233 para que apunte a 02: 00: 00: 86: 5b: 11 en el panel de configuración de mi proveedor de alojamiento (OVH).
(Las IP en esta publicación no son las reales).

¡Gracias por leer esta larga pregunta! :-)

Vianney

networking iptables bridge lxc Vianney Stroebel
fuente

Respuestas:

6

Una mejor manera de hacer que su cambio sea permanente es usar sysctl en lugar de escribir directamente en / proc, ya que esa es la forma estándar de configurar los parámetros del kernel en tiempo de ejecución para que se configuren correctamente en el próximo arranque:

# cat >> /etc/sysctl.d/99-bridge-nf-dont-pass.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
EOF
# service procps start

En cuanto a la respuesta a la pregunta en su actualización ...

bridge-netfilter (o bridge-nf) es un puente muy simple para paquetes IPv4 / IPv6 / ARP (incluso en encabezados 802.1Q VLAN o PPPoE) que proporciona la funcionalidad para un firewall transparente con estado, pero una funcionalidad más avanzada como IP NAT transparente es se proporciona al pasar esos paquetes a arptables / iptables para su posterior procesamiento; sin embargo, incluso si las características más avanzadas de arptables / iptables no son necesarias, pasar paquetes a esos programas todavía está activado de forma predeterminada en el módulo del núcleo y debe desactivarse explícitamente usando sysctl.

¿Para qué están aquí? Estas opciones de configuración del núcleo están aquí para pasar (1) o no pasar (0) paquetes a arptables / iptables como se describe en las preguntas frecuentes de bridge-nf :

As of kernel version 2.6.1, there are three sysctl entries for bridge-nf behavioral control (they can be found under /proc/sys/net/bridge/):
bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables.

¿Es seguro deshabilitar todo bridge-nf- *? Sí, no solo es seguro hacerlo, sino que también se recomienda que las distribuciones lo desactiven de manera predeterminada para ayudar a las personas a evitar la confusión por el tipo de problema que encontraron:

En la práctica, esto puede conducir a una seria confusión cuando alguien crea un puente y descubre que parte del tráfico no se reenvía a través del puente. Debido a que es tan inesperado que las reglas de firewall IP se aplican a los marcos en un puente, puede llevar bastante tiempo descubrir qué está sucediendo.

y para aumentar la seguridad :

Todavía creo que el riesgo con el puente es mayor, especialmente en presencia de virtualización. Considere el escenario en el que tiene dos máquinas virtuales en un host, cada una con un puente dedicado con la intención de que ninguno de ellos sepa nada sobre el tráfico del otro.

Con conntrack ejecutándose como parte del puente, el tráfico ahora puede cruzar, lo que es un grave agujero de seguridad.

ACTUALIZACIÓN: mayo de 2015

Si está ejecutando un kernel anterior a 3.18, entonces puede estar sujeto al comportamiento anterior de filtrado de puentes habilitado por defecto; si es más reciente que 3.18, aún puede ser mordido por esto si ha cargado el módulo de puente y no ha deshabilitado el filtro de puente. Ver:

https://bugzilla.redhat.com/show_bug.cgi?id=634736#c44

Después de todos estos años de pedir que el filtro predeterminado del puente se "deshabilite" y el cambio sea rechazado por los encargados del mantenimiento del núcleo, ahora el filtro se ha movido a un módulo separado que no está cargado (por defecto) cuando el módulo puente se carga, haciendo que el valor predeterminado sea "deshabilitado" ¡Hurra!

Creo que esto está en el núcleo a partir de 3.17 (definitivamente está en el núcleo 3.18.7-200.fc21, y parece estar en git antes de la etiqueta "v3.17-rc4")

aculich
fuente
0

Tengo una configuración similar ejecutándose en un hipervisor Debian Wheezy. No tuve que modificar / etc / network / interfaces dentro de rootfs del contenedor; tener lxc.network. * configurado en la configuración de LXC es suficiente.

Debería poder hacer que el puente funcione independientemente de si está ejecutando un contenedor o no. Tengo las siguientes configuraciones configuradas en br0 en / etc / network / interfaces en el host:

% grep bridge /etc/network/interfaces
  bridge_ports eth0
  bridge_fd 0
  bridge_stp off
  bridge_waitport 0
  bridge_maxwait 0

Después de configurar esto y mover la configuración de mi dirección IP de eth0 a br0, sudo service networking restartreconfiguré de forma transparente las interfaces en mi máquina host sin perder mi sesión SSH.

Una vez hecho esto, intente eliminar la configuración 'eth0' en / etc / network / interfaces y reinicie su contenedor.

Murali Suriar
fuente