Pontage des conteneurs LXC pour héberger eth0 afin qu'ils puissent avoir une adresse IP publique

8

MISE À JOUR:

J'ai trouvé la solution là-bas: 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

Mais j'aimerais avoir des avis d'experts à ce sujet: est-il sûr de désactiver tous les ponts-nf- *? Pourquoi sont-ils là?

FIN DE MISE À JOUR

Je dois relier les conteneurs LXC à l'interface physique (eth0) de mon hôte, en lisant de nombreux tutoriels, documents et articles de blog sur le sujet.

J'ai besoin que les conteneurs aient leur propre IP publique (ce que j'ai déjà fait KVM / libvirt).

Après deux jours de recherche et d'essais, je n'arrive toujours pas à le faire fonctionner avec les conteneurs LXC.

L'hôte exécute un serveur Ubuntu Quantal (12.10) fraîchement installé avec uniquement libvirt (que je n'utilise pas ici) et lxc installé.

J'ai créé les conteneurs avec:

lxc-create -t ubuntu -n mycontainer

Ils exécutent donc également Ubuntu 12.10.

Le contenu de / var / lib / lxc / mycontainer / config est:


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

Ensuite, j'ai changé mon hôte / etc / network / interfaces en:


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

Lorsque j'essaie de configurer la ligne de commande ("brctl addif", "ifconfig eth0", etc.), mon hôte distant devient inaccessible et je dois le redémarrer.

J'ai changé le contenu de / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces en:


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

Le démarrage de mycontainer prend plusieurs minutes (lxc-start -n mycontainer).

J'ai essayé de remplacer 

        gateway 92.281.86.254
par :

        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

Mon conteneur démarre alors instantanément.

Mais quelle que soit la configuration que j'ai définie dans / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces, je ne peux pas envoyer de ping depuis mycontainer vers n'importe quelle IP (y compris celle de l'hôte):


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

Et mon hôte ne peut pas cingler le conteneur:


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 de mon conteneur:


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 de mon hôte:


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)

J'ai désactivé lxcbr0 (USE_LXC_BRIDGE = "false" dans / etc / default / lxc).


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

J'ai configuré l'IP 179.43.46.233 pour pointer vers 02: 00: 00: 86: 5b: 11 dans le panneau de configuration de mon fournisseur d'hébergement (OVH).
(Les adresses IP dans ce post ne sont pas les vraies.)

Merci d'avoir lu cette longue question! :-)

Vianney

networking  iptables  bridge  lxc 
— Vianney Stroebel
source

Réponses:

6

Une meilleure façon de rendre votre modification permanente est d'utiliser sysctl au lieu d'écrire directement dans / proc car c'est la façon standard de configurer les paramètres du noyau au moment de l'exécution afin qu'ils soient correctement définis au prochain démarrage:

# 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

Quant à la réponse à la question dans votre mise à jour ...

bridge-netfilter (ou bridge-nf) est un pont très simple pour les paquets IPv4 / IPv6 / ARP (même dans les en-têtes 802.1Q VLAN ou PPPoE) qui fournit la fonctionnalité d'un pare-feu transparent avec état, mais des fonctionnalités plus avancées comme IP NAT transparent sont fourni en passant ces paquets à arptables / iptables pour un traitement ultérieur - cependant, même si les fonctionnalités plus avancées d'arptables / iptables ne sont pas nécessaires, la transmission de paquets à ces programmes est toujours activée par défaut dans le module du noyau et doit être désactivée explicitement en utilisant sysctl.

Pourquoi sont-ils là? Ces options de configuration du noyau sont là pour passer (1) ou ne pas passer (0) des paquets à arptables / iptables comme décrit dans la FAQ 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.

Est-il sûr de désactiver tous les bridge-nf- *? Oui, il est non seulement sûr de le faire, mais il est recommandé aux distributions de le désactiver par défaut pour aider les gens à éviter toute confusion pour le type de problème que vous avez rencontré:

En pratique, cela peut conduire à une grave confusion lorsque quelqu'un crée un pont et constate que du trafic n'est pas acheminé à travers le pont. Parce que c'est tellement inattendu que les règles de pare-feu IP s'appliquent aux trames sur un pont, cela peut prendre un certain temps pour comprendre ce qui se passe.

et pour augmenter la sécurité :

Je pense toujours que le risque de pontage est plus élevé, surtout en présence de virtualisation. Considérez le scénario où vous avez deux machines virtuelles sur le même hôte, chacune avec un pont dédié avec l'intention qu'aucun des deux ne devrait rien savoir du trafic de l'autre.

Le conntrack fonctionnant dans le cadre du pontage, le trafic peut désormais traverser, ce qui constitue un grave trou de sécurité.

MISE À JOUR: mai 2015

Si vous exécutez un noyau antérieur à 3.18, vous pouvez être soumis à l'ancien comportement de filtrage de pont activé par défaut; si vous êtes plus récent que 3.18, vous pouvez toujours être mordu par ceci si vous avez chargé le module de bridge et n'avez pas désactivé le filtrage de bridge. Voir:

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

Après toutes ces années à demander que la valeur par défaut du filtrage de pont soit "désactivée" et que la modification ait été refusée par les responsables du noyau, le filtrage a maintenant été déplacé dans un module distinct qui n'est pas chargé (par défaut) lorsque le module de pont est chargé, ce qui rend la valeur par défaut "désactivée". Yay!

Je pense que c'est dans le noyau à partir de la 3.17 (c'est certainement dans le noyau 3.18.7-200.fc21, et semble être dans git avant la balise "v3.17-rc4")

— aculich
source
0

J'ai une configuration similaire en cours d'exécution sur un hyperviseur Debian Wheezy. Je n'ai pas eu à modifier / etc / network / interfaces dans les rootfs du conteneur; avoir lxc.network. * configuré dans la configuration de LXC est suffisant.

Vous devriez pouvoir faire fonctionner le pontage, que vous exécutiez un conteneur ou non. J'ai les paramètres suivants configurés sous br0 dans / etc / network / interfaces sur l'hôte:

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

Après avoir configuré cela et déplacé ma configuration d'adresse IP de eth0 à br0, sudo service networking restartreconfiguré de manière transparente les interfaces sur ma machine hôte sans abandonner ma session SSH.

Une fois cela fait, essayez de supprimer la configuration «eth0» dans / etc / network / interfaces et de redémarrer votre conteneur.

— Murali Suriar
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.