Überbrückung von LXC-Containern mit dem Host eth0, damit diese eine öffentliche IP-Adresse haben können

8

AKTUALISIEREN:

Ich habe dort die Lösung gefunden: 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

Aber ich hätte gerne Expertenmeinungen dazu: Ist es sicher, alle Bridge-nf- * zu deaktivieren? Wofür sind sie hier?

ENDE DES UPDATE

Ich muss LXC-Container mit der physischen Schnittstelle (eth0) meines Hosts verbinden und zahlreiche Tutorials, Dokumente und Blog-Beiträge zu diesem Thema lesen.

Ich brauche die Container, um ihre eigene öffentliche IP zu haben (was ich zuvor mit KVM / libvirt gemacht habe).

Nach zwei Tagen des Suchens und Versuchens kann ich es immer noch nicht mit LXC-Containern zum Laufen bringen.

Auf dem Host wird ein frisch installierter Ubuntu Server Quantal (12.10) ausgeführt, auf dem nur libvirt (das ich hier nicht verwende) und lxc installiert sind.

Ich habe die Container erstellt mit:

lxc-create -t ubuntu -n mycontainer

Sie führen also auch Ubuntu 12.10 aus.

Der Inhalt von / var / lib / lxc / mycontainer / config lautet:


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

Dann habe ich meinen Host / etc / network / interfaces geändert 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

Wenn ich die Befehlszeilenkonfiguration ("brctl addif", "ifconfig eth0" usw.) versuche, kann auf meinen Remote-Host nicht mehr zugegriffen werden, und ich muss ihn hart neu starten.

Ich habe den Inhalt von / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces geändert 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

Es dauert einige Minuten, bis mycontainer gestartet ist (lxc-start -n mycontainer).

Ich habe versucht zu ersetzen 

        gateway 92.281.86.254
durch :

        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

Mein Container startet dann sofort.

Unabhängig von der Konfiguration, die ich in / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces festgelegt habe, kann ich keinen Ping von mycontainer an eine IP-Adresse (einschließlich der des Hosts) senden:


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

Und mein Gastgeber kann den Container nicht anpingen:


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

Die ifconfig meines Containers:


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)

Die ifconfig meines Hosts:


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)

Ich habe lxcbr0 deaktiviert (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

Ich habe die IP 179.43.46.233 so konfiguriert, dass sie in meinem OVH-Konfigurationsfenster (Hosting Provider) auf 02: 00: 00: 86: 5b: 11 zeigt.
(Die IPs in diesem Beitrag sind nicht die echten.)

Vielen Dank für das Lesen dieser langen Frage! :-)

Vianney

networking  iptables  bridge  lxc 
— Vianney Stroebel
quelle

Antworten:

6

Eine bessere Möglichkeit, Ihre Änderung dauerhaft zu machen, besteht darin, sysctl zu verwenden, anstatt direkt in / proc zu schreiben, da dies die Standardmethode ist, um Kernel-Parameter zur Laufzeit so zu konfigurieren, dass sie beim nächsten Start korrekt eingestellt werden:

# 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

Wie für die Antwort auf die Frage in Ihrem Update ...

Bridge-Netfilter (oder Bridge-NF) ist eine sehr einfache Bridge für IPv4 / IPv6 / ARP-Pakete (auch in 802.1Q-VLAN- oder PPPoE-Headern), die die Funktionalität für eine zustandsbehaftete transparente Firewall bietet, jedoch erweiterte Funktionen wie transparentes IP-NAT bietet Wird bereitgestellt, indem diese Pakete zur weiteren Verarbeitung an arptables / iptables übergeben werden. Auch wenn die erweiterten Funktionen von arptables / iptables nicht erforderlich sind, ist die Weitergabe von Paketen an diese Programme im Kernelmodul standardmäßig aktiviert und muss explizit deaktiviert werden mit sysctl.

Wofür sind sie hier? Diese Kernel-Konfigurationsoptionen dienen dazu, Pakete entweder an (1) oder nicht (0) an arptables / iptables zu übergeben, wie in den häufig gestellten Fragen zu bridge-nf beschrieben :

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.

Ist es sicher, alle Bridge-nf- * zu deaktivieren? Ja, dies ist nicht nur sicher, es gibt auch eine Empfehlung für Distributionen, diese standardmäßig zu deaktivieren, um Verwirrung über die Art des Problems zu vermeiden, auf das Sie gestoßen sind:

In der Praxis kann dies zu ernsthafter Verwirrung führen, wenn jemand eine Brücke erstellt und feststellt, dass kein Verkehr über die Brücke weitergeleitet wird. Da es so unerwartet ist, dass IP-Firewall-Regeln für Frames auf einer Bridge gelten, kann es einige Zeit dauern, um herauszufinden, was los ist.

und um die Sicherheit zu erhöhen :

Ich denke immer noch, dass das Risiko beim Überbrücken höher ist, insbesondere bei vorhandener Virtualisierung. Stellen Sie sich das Szenario vor, in dem sich auf einem Host zwei VMs mit jeweils einer dedizierten Bridge befinden, mit der Absicht, dass keiner etwas über den Datenverkehr des anderen wissen sollte.

Wenn conntrack als Teil der Überbrückung ausgeführt wird, kann der Verkehr jetzt überqueren, was eine ernsthafte Sicherheitslücke darstellt.

UPDATE: Mai 2015

Wenn Sie einen Kernel ausführen, der älter als 3.18 ist, kann es sein, dass Sie dem alten Verhalten der standardmäßig aktivierten Bridge-Filterung unterliegen. Wenn Sie neuer als 3.18 sind, können Sie trotzdem davon gebissen werden, wenn Sie das Bridge-Modul geladen und die Bridge-Filterung nicht deaktiviert haben. Sehen:

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

Nach all den Jahren, in denen gefordert wurde, dass die Standardeinstellung für die Bridge-Filterung "deaktiviert" wird und die Änderung von den Kernel-Betreuern abgelehnt wird, wurde die Filterung jetzt in ein separates Modul verschoben, das (standardmäßig) beim Bridge-Modul nicht geladen wird wird geladen, wodurch die Standardeinstellung "deaktiviert" wird. Yay!

Ich denke, dies ist im Kernel ab 3.17 (Es ist definitiv im Kernel 3.18.7-200.fc21 und scheint vor dem Tag "v3.17-rc4" in Git zu sein).

— aculich
quelle
0

Ich habe ein ähnliches Setup auf einem Debian Wheezy-Hypervisor. Ich musste / etc / network / interfaces in den rootfs des Containers nicht ändern. Es reicht aus, wenn lxc.network. * in der LXC-Konfiguration konfiguriert ist.

Sie sollten in der Lage sein, Bridging zum Laufen zu bringen, unabhängig davon, ob Sie einen Container ausführen oder nicht. Ich habe die folgenden Einstellungen unter br0 in / etc / network / interfaces auf dem Host konfiguriert:

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

Nachdem Sie dies konfiguriert und meine IP-Adresskonfiguration von eth0 auf br0 verschoben haben, haben Sie sudo service networking restartdie Schnittstellen auf meinem Host-Computer transparent neu konfiguriert, ohne meine SSH-Sitzung zu beenden .

Versuchen Sie anschließend, die Konfiguration 'eth0' in / etc / network / interfaces zu entfernen und den Container neu zu starten.

— Murali Suriar
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.