Ligando contêineres LXC para hospedar o eth0 para que eles possam ter um IP público

8

ATUALIZAÇÃO:

Eu encontrei a solução lá: link

 # 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

Mas eu gostaria de ter opiniões de especialistas sobre isso: é seguro desativar todos os bridge-nf- *? Para que eles estão aqui?

END OF UPDATE

Eu preciso colmatar os contêineres do LXC para a interface física (eth0) do meu host, lendo inúmeros tutoriais, documentos e postagens de blogs sobre o assunto.

Eu preciso que os containers tenham seu próprio IP público (que eu já fiz KVM / libvirt).

Após dois dias pesquisando e tentando, ainda não consigo fazê-lo funcionar com contêineres LXC.

O host executa um Ubuntu Server Quantal recém-instalado (12.10) com apenas libvirt (que não estou usando aqui) e lxc instalado.

Eu criei os contêineres com:

lxc-create -t ubuntu -n mycontainer

Então eles também rodam o Ubuntu 12.10.

O conteúdo de / var / lib / lxc / mycontainer / config é:


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

Então mudei meu host / etc / network / interfaces para:


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

Quando eu tento a configuração da linha de comando ("brctl addif", "ifconfig eth0", etc.), meu host remoto fica inacessível e eu tenho que reiniciá-lo com força.

Alterei o conteúdo de / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces para:


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

Demora vários minutos para o mycontainer iniciar (lxc-start -n mycontainer).

Eu tentei substituir

        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

Meu contêiner começa instantaneamente.

Mas seja qual for a configuração que eu configurei em / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces, não consigo pingar de mycontainer para qualquer IP (incluindo o 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

E meu host não pode fazer ping no contêiner:


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

ifconfig do meu contêiner:


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)

ifconfig do meu 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)

Eu desativei o lxcbr0 (USE_LXC_BRIDGE="false" em / etc / default / lxc).


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

Eu configurei o IP 179.43.46.233 para apontar para 02: 00: 00: 86: 5b: 11 no painel de configuração do meu provedor de hospedagem (OVH).
(Os IPs neste post não são os reais.)

Obrigado por ler esta longa pergunta! : -)

Vianney

    
por Vianney Stroebel 06.11.2012 / 17:10

2 respostas

6

A melhor maneira de tornar sua mudança permanente é usar sysctl em vez de escrever para / proc diretamente, já que esta é a maneira padrão de configurar os parâmetros do kernel em tempo de execução, para que eles sejam configurados corretamente na próxima inicialização:

# 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

Quanto à resposta à pergunta na sua atualização ...

bridge-netfilter (ou bridge-nf) é uma ponte muito simples para IPv4 / IPv6 / Pacotes ARP (mesmo em 802.1Q VLAN ou PPPoE headers) que fornecem a funcionalidade para um firewall transparente com estado, mas funcionalidades mais avançadas como IP NAT transparente são fornecidas ao passar esses pacotes para arptables / iptables para processamento adicional - no entanto se os recursos mais avançados de arptables / iptables não forem necessários, a passagem de pacotes para esses programas ainda é ativada por padrão no módulo do kernel e deve ser desativada explicitamente usando sysctl.

Para que eles estão aqui? Estas opções de configuração do kernel estão aqui para passar (1) ou não passar (0) pacotes para arptables / iptables como descrito no bridge-nf FAQ :

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.

É seguro desativar todos os bridge-nf - *? Sim, não é apenas seguro fazê-lo, mas há um recomendação para que as distribuições o desliguem por padrão para ajudar as pessoas a evitar confusão para o tipo de problema que encontrou:

In practice, this can lead to serious confusion where someone creates a bridge and finds that some traffic isn't being forwarded across the bridge. Because it's so unexpected that IP firewall rules apply to frames on a bridge, it can take quite some time to figure out what's going on.

e para aumentar a segurança :

I still think the risk with bridging is higher, especially in the presence of virtualisation. Consider the scenario where you have two VMs on the one host, each with a dedicated bridge with the intention that neither should know anything about the other's traffic.

With conntrack running as part of bridging, the traffic can now cross over which is a serious security hole.

ATUALIZAÇÃO: maio de 2015

Se você estiver executando um kernel mais antigo que 3.18, então você pode estar sujeito ao antigo comportamento de filtragem de ponte ativado por padrão; se você for mais novo que 3.18, então você ainda pode ser mordido por isso se tiver carregado o módulo de ponte e não tiver desativado a filtragem de ponte. Veja:

link

After all these years of asking for the default of bridge filtering to be "disabled" and the change being refused by the kernel maintainers, now the filtering has been moved into a separate module that isn't loaded (by default) when the bridge module is loaded, effectively making the default "disabled". Yay!

I think this is in the kernel as of 3.17 (It definitely is in kernel 3.18.7-200.fc21, and appears to be in git prior to the tag "v3.17-rc4")

    
por 22.11.2012 / 23:29
0

Eu tenho uma configuração semelhante rodando em um hipervisor Debian Wheezy. Eu não precisei modificar o / etc / network / interfaces dentro do rootfs do container; ter lxc.network. * configurado na configuração do LXC é suficiente.

Você deve conseguir fazer a ponte de trabalho, independentemente de estar executando um contêiner ou não. Eu tenho as seguintes configurações configuradas em br0 em / etc / network / interfaces no host:

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

Depois de configurar isso e mover minha configuração de endereço IP de eth0 para br0, sudo service networking restart reconfigurou de forma transparente as interfaces em minha máquina host sem perder minha sessão SSH.

Uma vez feito isso, tente remover a configuração 'eth0' em / etc / network / interfaces e reiniciar o seu contêiner.

    
por 24.02.2013 / 20:35