Gettare un ponte sui contenitori LXC per ospitare eth0 in modo che possano avere un IP pubblico

8

AGGIORNARE:

Ho trovato la soluzione lì: 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

Ma vorrei avere opinioni di esperti su questo: è sicuro disabilitare tutti i bridge-nf- *? Per cosa sono qui?

FINE AGGIORNAMENTO

Devo collegare i container LXC all'interfaccia fisica (eth0) del mio host, leggendo numerosi tutorial, documenti e post di blog sull'argomento.

Ho bisogno che i container abbiano il loro IP pubblico (che ho già fatto in precedenza KVM / libvirt).

Dopo due giorni di ricerche e tentativi, non riesco ancora a farlo funzionare con i contenitori LXC.

L'host esegue un Ubuntu Server Quantal appena installato (12.10) con solo libvirt (che non sto usando qui) e lxc installato.

Ho creato i contenitori con:

lxc-create -t ubuntu -n mycontainer

Quindi eseguono anche Ubuntu 12.10.

Il contenuto di / 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

Quindi ho cambiato il mio host / etc / network / interfaces in:


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 provo la configurazione della riga di comando ("brctl addif", "ifconfig eth0", ecc.) Il mio host remoto diventa inaccessibile e devo riavviarlo a fatica.

Ho modificato il contenuto di / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces in:


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

L'avvio di mycontainer richiede alcuni minuti (lxc-start -n mycontainer).

Ho provato a sostituire 

        gateway 92.281.86.254
di:

        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

Il mio contenitore si avvia quindi all'istante.

Ma qualunque sia la configurazione che ho impostato in / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces, non posso eseguire il ping da mycontainer a nessun IP (incluso l'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 il mio host non può eseguire il ping del contenitore:


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 del mio container:


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 del mio 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)

Ho disabilitato lxcbr0 (USE_LXC_BRIDGE = "false" in / etc / default / lxc).


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

Ho configurato l'IP 179.43.46.233 in modo che punti a 02: 00: 00: 86: 5b: 11 nel pannello di configurazione del mio provider di hosting (OVH).
(Gli IP in questo post non sono quelli reali.)

Grazie per aver letto questa lunga domanda! :-)

Vianney

networking  iptables  bridge  lxc 
— Vianney Stroebel
fonte

Risposte:

6

Un modo migliore per rendere permanente la modifica è usare sysctl invece di scrivere direttamente in / proc poiché questo è il modo standard per configurare i parametri del kernel in fase di esecuzione in modo che siano impostati correttamente al prossimo avvio:

# 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

Per quanto riguarda la risposta alla domanda nel tuo aggiornamento ...

bridge-netfilter (o bridge-nf) è un bridge molto semplice per i pacchetti IPv4 / IPv6 / ARP (anche nelle intestazioni VLAN o PPPoE 802.1Q) che fornisce la funzionalità per un firewall con stato trasparente, ma funzionalità più avanzate come NAT IP trasparente è fornito passando tali pacchetti su arptables / iptables per ulteriori elaborazioni, tuttavia anche se non sono necessarie le funzionalità più avanzate di arptables / iptables, il passaggio dei pacchetti a tali programmi è ancora attivato di default nel modulo del kernel e deve essere disattivato esplicitamente usando sysctl.

Per cosa sono qui? Queste opzioni di configurazione del kernel sono qui per passare (1) o non passare (0) pacchetti a arptables / iptables come descritto nelle FAQ di 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.

È sicuro disabilitare tutti i bridge-nf- *? Sì, non è solo sicuro farlo, ma esiste una raccomandazione per le distribuzioni di disattivarlo per impostazione predefinita per aiutare le persone a evitare confusione per il tipo di problema riscontrato:

In pratica, ciò può creare seria confusione quando qualcuno crea un ponte e scopre che parte del traffico non viene inoltrato attraverso il ponte. Poiché è così inaspettato che le regole del firewall IP si applichino ai frame su un bridge, può richiedere parecchio tempo per capire cosa sta succedendo.

e per aumentare la sicurezza :

Penso ancora che il rischio con i ponti sia maggiore, soprattutto in presenza di virtualizzazione. Considera lo scenario in cui hai due VM su un host, ognuna con un bridge dedicato con l'intenzione che nessuno dei due dovrebbe sapere nulla sul traffico dell'altro.

Con conntrack in esecuzione come parte del bridge, il traffico può ora attraversare il che rappresenta un grave buco di sicurezza.

AGGIORNAMENTO: maggio 2015

Se stai eseguendo un kernel più vecchio di 3.18, potresti essere soggetto al vecchio comportamento del bridge bridge abilitato di default; se sei più recente di 3.18, puoi ancora essere morso da questo se hai caricato il modulo bridge e non hai disabilitato il filtro bridge. Vedere:

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

Dopo tutti questi anni in cui è stata richiesta la disattivazione del default del filtro bridge e il rifiuto della modifica da parte dei manutentori del kernel, ora il filtro è stato spostato in un modulo separato che non viene caricato (per impostazione predefinita) quando il modulo bridge viene caricato, rendendo effettivamente l'impostazione predefinita "disabilitata". Sìì!

Penso che questo sia nel kernel a partire dalla 3.17 (È sicuramente nel kernel 3.18.7-200.fc21, e sembra essere in git prima del tag "v3.17-rc4")

— aculich
fonte
0

Ho un setup simile in esecuzione su un hypervisor Debian Wheezy. Non ho dovuto modificare / etc / network / interfaces nei rootfs del contenitore; avere lxc.network. * configurato nella configurazione di LXC è sufficiente.

Dovresti essere in grado di far funzionare il bridge indipendentemente dal fatto che tu stia eseguendo o meno un container. Ho le seguenti impostazioni configurate sotto br0 in / etc / network / interfaces sull'host:

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

Dopo aver configurato questo e spostato la mia configurazione dell'indirizzo IP da eth0 a br0, sudo service networking restartho riconfigurato in modo trasparente le interfacce sul mio computer host senza abbandonare la mia sessione SSH.

Una volta fatto, prova a rimuovere la configurazione 'eth0' in / etc / network / interfaces e a riavviare il tuo contenitore.

— Murali Suriar
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.