Bridging les conteneurs LXC pour accueillir Eth0 afin qu'ils puissent avoir une adresse IP publique
METTRE À 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 pont-nf- *? Comment sont-ils ici?
Fin de mise à jour
J'ai besoin de combler les conteneurs LXC à l'interface physique (ETH0) de mon hôte, de lire de nombreux didacticiels, documents et articles de blog sur le sujet.
J'ai besoin que les conteneurs puissent avoir leur propre adresse publique publique (ce que j'ai déjà fait KVM/Libvirt).
Après deux jours de recherche et d'essai, je ne peux toujours pas le faire fonctionner avec des conteneurs LXC.
L'hôte exécute un serveur d'Ubuntu fraîchement installé (12.10) avec uniquement Libvirt (que je n'utilise pas ici) et LXC installé.
J'ai créé les conteneurs avec:
lxc-create -t ubuntu -n mycontainerDonc, ils fonctionnent également Ubuntu 12.10.
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/réseau/interfaces/interfaces sur:
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'essaye la configuration de la ligne de commande ("BRCTL Adtiv", "ifconfigth.0", etc.) Mon hôte distant devient inaccessible et je dois le redémarrer dur.
J'ai changé le contenu de/var/lib/lxc/mycontainer/rootfs/etc/réseau/interfaces vers:
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
Il faut plusieurs minutes pour que Mycontainer commence (LXC-Start -n Mycontainer).
J'ai essayé de remplacer
gateway 92.281.86.254 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 commence alors instantanément.
Mais quelle que soit la configuration que j'ai définie dans/var/lib/lxc/myContainer/rootfs/etc/réseau/interfaces, je ne peux pas ping de myContainer à aucune adresse IP (y compris 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 ping 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
Mon conteneur est ifconfig:
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/par défaut/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 à pointer sur 02: 00: 00: 86: 5B: 11 dans mon panneau de configuration de mon fournisseur d'hébergement (OVH).
[.____] (Les IP dans ce post ne sont pas les vrais.)
Merci de lire cette longue question! :-)
Vianney
Un meilleur moyen de rendre votre changement permanent consiste à utiliser SYSCTL au lieu d'écrire directement sur/PROC, car c'est le moyen standard de configurer les paramètres de 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 de votre mise à jour ...
Bridge-NetFilter (ou Bridge-NF) est un pont très simple pour les paquets IPv4/IPv6/ARP (même en 802.1Q VLAN ou PPPoE Les en-têtes) qui fournissent la fonctionnalité d'un pare-feu transparent d'état, mais plus de fonctionnalités avancées telles que Transparent IP NAT est fournie en passant à ces paquets à ARPTables/Iptables pour un traitement ultérieur - Cependant, même si les fonctionnalités les plus avancées d'ARPTables/IPTABLES n'ont pas besoin de passer des paquets à ces programmes sont toujours activés par défaut dans le module du noyau et doivent être désactivés explicitement à l'aide de SYSCTL.
Quels sont-ils ici pour? Ces options de configuration du noyau sont ici pour passer (1) ou ne pas passer (0) paquets à des arptables/iptables comme décrit dans la FAQ sur le pont-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 tout pont-nf - *? Oui, il est non seulement sûr de le faire, mais il existe une recommandation pour les distributions pour l'éteindre par défaut Pour aider les gens Éviter la confusion pour le genre de problème que vous avez rencontré:
En pratique, cela peut conduire à une confusion sérieuse dans laquelle quelqu'un crée un pont et trouve que le trafic n'est pas transmis à travers le pont. Parce qu'il est tellement inattendu que les règles de pare-feu IP s'appliquent aux cadres sur un pont, il peut prendre assez de temps pour comprendre ce qui se passe.
et augmenter la sécurité:
Je pense toujours que le risque avec le pontage est plus élevé, en particulier en présence de la virtualisation. Considérez le scénario où vous avez deux VMS sur un hôte, chacun avec un pont dédié avec l'intention de ne rien savoir sur le trafic de l'autre.
Avec Conntrack en cours d'exécution dans le pontage, le trafic peut maintenant traverser lequel est un trou de sécurité sérieux.
Mise à jour: mai 2015
Si vous exécutez un noyau de plus de 3,18, vous pouvez être soumis à l'ancien comportement du filtrage du pont activé par défaut; Si vous récemment 3.18, vous pouvez toujours être mordu par cela si vous avez chargé le module de pont et que vous n'avez pas désactivé le filtrage du pont. Voir:
https://bugzilla.redhat.com/show_bug.cgi?id=634736#c44
Après toutes ces années de demander la valeur par défaut du filtrage du pont "désactivé" et que le changement étant refusé par les mainteneurs du noyau, le filtrage a maintenant été déplacé dans un module séparé qui n'est pas chargé (par défaut) lorsque le module de pont est chargé, en faisant efficacement la valeur par défaut "désactivée". Yay!
I Pensez Ceci est dans le noyau à partir de 3.17 (c'est certainement dans le noyau 3.18.7-200.fc21, et semble être dans GIT avant la balise "V3.17-RC4" )
J'ai une mise en place similaire à exécuter sur un hyperviseur debian Wheezy. Je n'avais pas besoin de modifier/etc/réseau/interfaces dans la rothiste du conteneur; avoir lxc.network. * Configuré dans la configuration de LXC est suffisant.
Vous devriez être capable de faire fonctionner le travail, que vous soyez 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éplacer ma configuration d'adresse IP d'ETH0 à BR0, Sudo service networking restart Reconfiguré de manière transparente les interfaces sur ma machine hôte sans laisser tomber ma session SSH.
Une fois que cela est fait, essayez de supprimer la configuration 'Eth0' dans/etc/réseau/interfaces et redémarrer votre conteneur.