Bridges in Host für mehrere VMs einrichten

[max123kl]

Hallo,
ich komme gerade mit meinen "autodidaktischen" Netzwerk-Kenntnissen an meine Grenzen bzw. ich weiß nicht wo ich noch ansetzen soll um mein Problem zu lösen.
Aber von vorne:
Ziel ist einen kleinen Rechner im lokalen Netz aufzusetzen, der als Host für folgende VMs dienen soll: Firewall-Router (IpFire), NAS (OpenMediaVault), lokaler Web- und Email-Server.
Hardwaremäßig hat das verwendete Board (AsRock C226M WS) 2x GBit-LAN - Betriebssystem für den Host ist ein minimales Debian Jessie.

Direkt nach der Grundinstallation des Hosts funktionieren beide Netzwerkkarten (eth0 und eth1), wie zu erwarten war - der SSH-Zugriff klappt aus beiden Netzen.
Aber nach dem Einrichten der Bridges kann man nur über br0 auf das lokale Netz zugreifen und ins Internet verbinden (apt-get update und apt-get upgrade klappt) und auch der Zugriff über SSH ist nur über br0 möglich.
Hier meine angepasste /etc/network/interfaces:

Code: Alles auswählen

...
# The primary network interface
auto eth0
iface eth0 inet manual

# ------- extern WAN --------
auto br0
iface br0 inet static
	address 192.168.5.10
	netmask 255.255.255.0
	network 192.168.5.0
	broadcast 192.168.5.255
	gateway 192.168.5.100
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 192.168.5.100
#	dns-search local
		bridge_ports eth0
			bridge_fd 0
			bridge_maxwait 0
			bridge_stp on		

# zweite Netzwerkkarte getaggt
auto eth1.10
iface eth1.10 inet manual

# ------- LAN intern 1 --------
auto br1.10
iface br1.10 inet static
	address 192.168.1.10
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
        bridge_ports eth1.10
            bridge_fd 0
            bridge_maxwait 0
            bridge_stp on
	
# ------- LAN intern 2 --------
 auto br1.11
 iface br1.11 inet manual
		bridge_ports eth1.11
            bridge_fd 0
            bridge_maxwait 0
            bridge_stp on
 
# virtuelle Bridge
# ------- DMZ --------
auto br2
iface br2 inet manual
        bridge_fd 0
        bridge_maxwait 0
        bridge_stp on
	up brctl addbr br2 up

Bemerkung: Das Taggen der zweiten Netzwerkkarte soll später ein weiteren lokales Netz (br1.11) und die virtuelle Bridge (br2) eine DMZ ermöglichen. Sie sollen aber derzeit nicht verwendet werden.

Die Konfiguration wird offensichtlich übernommen
brctl show

Code: Alles auswählen

bridge name	bridge id		STP enabled	interfaces
br0			8000.d0509964d334	yes		eth0
br1.10		8000.d0509964d335	yes		eth1.10
br1.11		8000.000000000000	yes		
br2			8000.000000000000	no		

Nun zum eigentlichen Problem:
Ein Ping auf die lokale IP-Adresse klappt mit br0 und br1.10
Wenn ich jedoch einen Ping zum Router oder zu einem Nachbarrechner absetze, kann ich den nicht mehr erreichen.
ping -c 4 192.168.1.100

Code: Alles auswählen

PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable
From 192.168.1.10 icmp_seq=2 Destination Host Unreachable
From 192.168.1.10 icmp_seq=3 Destination Host Unreachable
From 192.168.1.10 icmp_seq=4 Destination Host Unreachable

--- 192.168.1.100 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3013ms
pipe 3

Der umgekehrte Weg, vom Nachbarrechner zum Hostrechner (br1.10), erzeugt die Fehlermeldung "Zeitüberschreitung der Anforderung"
br0 ist dagegen problemlos erreichbar.

Die Ausgabe von ifconfig

Code: Alles auswählen

br0       Link encap:Ethernet  Hardware Adresse d0:50:99:64:d3:34  
          inet Adresse:192.168.5.10  Bcast:192.168.5.255  Maske:255.255.255.0
          inet6-Adresse: fe80::d250:99ff:fe64:d334/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:477 errors:0 dropped:0 overruns:0 frame:0
          TX packets:229 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:33438 (32.6 KiB)  TX bytes:31155 (30.4 KiB)

br1.10    Link encap:Ethernet  Hardware Adresse d0:50:99:64:d3:35  
          inet Adresse:192.168.1.10  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fe80::d250:99ff:fe64:d335/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:0 (0.0 B)  TX bytes:1404 (1.3 KiB)

br1.11    Link encap:Ethernet  Hardware Adresse d2:23:1d:cd:b3:7f  
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  Hardware Adresse d0:50:99:64:d3:34  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:480 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1515 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:43474 (42.4 KiB)  TX bytes:114687 (111.9 KiB)
          Interrupt:20 Speicher:ef200000-ef220000 

eth1      Link encap:Ethernet  Hardware Adresse d0:50:99:64:d3:35  
          inet6-Adresse: fe80::d250:99ff:fe64:d335/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:103 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1322 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:9767 (9.5 KiB)  TX bytes:69018 (67.4 KiB)
          Speicher:ef100000-ef17ffff 

eth1.10   Link encap:Ethernet  Hardware Adresse d0:50:99:64:d3:35  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1313 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:0 (0.0 B)  TX bytes:68328 (66.7 KiB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:43 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:3729 (3.6 KiB)  TX bytes:3729 (3.6 KiB)

und ip addr

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d0:50:99:64:d3:35 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d250:99ff:fe64:d335/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether d0:50:99:64:d3:34 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether d0:50:99:64:d3:34 brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.10/24 brd 192.168.5.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::d250:99ff:fe64:d334/64 scope link 
       valid_lft forever preferred_lft forever
5: eth1.10@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br1.10 state UP group default 
    link/ether d0:50:99:64:d3:35 brd ff:ff:ff:ff:ff:ff
6: br1.10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether d0:50:99:64:d3:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global br1.10
       valid_lft forever preferred_lft forever
    inet6 fe80::d250:99ff:fe64:d335/64 scope link 
       valid_lft forever preferred_lft forever
7: br1.11: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether fe:29:5b:08:06:ad brd ff:ff:ff:ff:ff:ff
8: br2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 9e:1e:35:17:b7:74 brd ff:ff:ff:ff:ff:ff

sind für mich nicht auffällig.

IPTABLES habe ich noch nicht konfiguriert und deshalb dürfte es von dieser Seite auch keine Blockade geben.
iptables -L

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Aus meiner Sicht bleibt jetzt nur noch das Routing.
Aber da kann ich auch nichts erkennen.
ip route

Code: Alles auswählen

default via 192.168.5.100 dev br0 
192.168.1.0/24 dev br1.10  proto kernel  scope link  src 192.168.1.10 
192.168.5.0/24 dev br0  proto kernel  scope link  src 192.168.5.10 

route -nee

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Gateway         Maske           Flags Metric Ref    Benutzer Iface    MSS   Fenster irtt
0.0.0.0         192.168.5.100   0.0.0.0         UG    0      0        0 br0      0     0      0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br1.10   0     0      0
192.168.5.0     0.0.0.0         255.255.255.0   U     0      0        0 br0      0     0      0

Kann mir jemand einen Tipp geben wo ich weiter suchen könnte - welche Log-Datei mir ev. weitere Infos geben könnte?

Grüße max

[dufty2]

Ok, ich weiss es auch nicht

Es könnte mit dem sog. BROUTING zusammen hängen,
da bei Dir ungetagged funzt, getaggt jedoch nicht.

Schau Dir doch mal
http://www.rackspace.com/blog/vms-vlans ... my-part-2/
an, vielleicht hilft es.

[max123kl]

Zwischenbericht:

Es könnte mit dem sog. BROUTING zusammen hängen,
da bei Dir ungetagged funzt, getaggt jedoch nicht.

Danke, dein Tipp war goldrichtig!
Ich habe bisher gedacht, dass der Fehler mit dem Aufbau der Bridgen zusammenhängt und gar nicht erst versucht eine ungetaggte Bridge anzulegen.
Brouting hatte ich nicht auf dem Plan.
Ich habe mal testweise die interfaces angepasst.

Code: Alles auswählen

...
# zweite Netzwerkkarte
auto eth1
iface eth1 inet manual

# ------- LAN intern 1 --------
auto br1
iface br1 inet static
	address 192.168.1.10
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
        bridge_ports eth1
            bridge_fd 0
            bridge_maxwait 0
            bridge_stp on
...

Diese Variante klappt auf Anhieb.
Leider muss ich dann aber auf das zweite interne LAN verzichten.
Falls es mit deinem nachfolgenden Linktipp nicht funktionieren sollte, bliebe immerhin noch die Hardwarelösung (zusätzliche NIC einbauen), ein für meine Zwecke unnötiger Technik-Overkill.

Schau Dir doch mal
http://www.rackspace.com/blog/vms-vlans ... my-part-2/
an, vielleicht hilft es.

Mein Englisch ist ziemlich eingerostet. Den Text muss ich erst gründlich durcharbeiten. Ich melde mich dann zurück.
Gruß max

PS: Hast du ev. noch einen Link zu mehr Hintergrundwissen zum Brouting, am Besten natürlich auf deutsch?

[dufty2]

Mmh, auf Deutsch wird schwierig, da doch etwas "advanced"

Ich kann Dir mal die Kurzfassung in meinen Worten geben:
Glotzt Du auf Bildchen:
https://c3414940.ssl.cf0.rackcdn.com/bl ... t-Flow.png
Hattu interface in Bridge gesteckt => Pakete hoppeln durch den blauen Streifen (Layer-2).
"Dummerweise" wird VLAN tagging (eigentlich Layer-2) im Grünen Bereich (Layer-3) "abgefackelt".
Durch "-j Drop" wird Paket aus Kästchen "BRoute|BRouting" über weißen Pfeil rückwärts nach Kreis "Routing Process" und danach ins "Grün" geschubst.
Alles Grün, alles Gut

[max123kl]

Mmh, auf Deutsch wird schwierig, da doch etwas "advanced"

Ich habe mal deinen verlinkten Atikel und den zugehörigen ersten Teil für mich übersetzt.
Ich denke, dass ich die Systematik verstanden habe, ob alles technisch richtig formuliert ist weiß ich dagegen nicht.
Falls Interesse besteht könnte ich dir oder anderen per Mail oder PM den Text zum Korrekturlesen schicken.
Man könnte danach im Wiki oder sonst wo den Text für alle zugänglich machen, die Zustimmung des Original-Autors vorrausgesetzt.

Ich kann Dir mal die Kurzfassung in meinen Worten geben:
Glotzt Du auf Bildchen:
https://c3414940.ssl.cf0.rackcdn.com/bl ... t-Flow.png
Hattu interface in Bridge gesteckt => Pakete hoppeln durch den blauen Streifen (Layer-2).
"Dummerweise" wird VLAN tagging (eigentlich Layer-2) im Grünen Bereich (Layer-3) "abgefackelt".
Durch "-j Drop" wird Paket aus Kästchen "BRoute|BRouting" über weißen Pfeil rückwärts nach Kreis "Routing Process" und danach ins "Grün" geschubst.
Alles Grün, alles Gut

Soweit die Theorie
In meinem Fall habe ich bisher keinen Erfolg gehabt. Ich denke, dass mir noch etwas Hintergrundwissen fehlt.
Meine Versuche in zeitlicher Reihenfolge:
Nachinstallation von "ebtables" und "vlan"
Neustart des Rechners - die interfaces-Datei ohne getaggte Schnittstellen aber mit definition von br0 und br1 => die Pings antworten wie erwartet!
Die interfaces-Datei wurde dann wie hier umgebaut

Code: Alles auswählen

...
# The primary network interface
auto eth0
iface eth0 inet manual

# ------- extern WAN --------
auto br0
iface br0 inet static
	address 192.168.5.10
	netmask 255.255.255.0
	network 192.168.5.0
	broadcast 192.168.5.255
	gateway 192.168.5.100
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 192.168.5.100
#	dns-search local
		bridge_ports eth0
			bridge_fd 0
			bridge_stp yes
			bridge_maxwait 0

# zweite Netzwerkkarte getaggt ******
# ------- LAN intern 1 getaggt --------
auto eth1.10
iface eth1.10 inet manual

auto br1.10
iface br1.10 inet static
	address 192.168.1.10
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
        bridge_ports eth1.10
            bridge_fd 0
            bridge_stp yes
            bridge_maxwait 0
	
# ------- LAN intern 2 getaggt --------
auto eth1.11
iface eth1.11 inet manual

auto br1.11
iface br1.11 inet manual
	bridge_ports eth1.11
            bridge_fd 0
            bridge_stp yes
            bridge_maxwait 0
 
# virtuelle Bridge
# ------- DMZ --------
auto br2
iface br2 inet manual
        bridge_fd 0
        bridge_stp yes
        bridge_maxwait 0
	up brctl addbr br2 up

Danach

Code: Alles auswählen

service networking restart

zusätzlich

Code: Alles auswählen

ebtables -t broute -F
ebtables -t broute -A BROUTING -i eth1 -p 802_1Q -d d0:50:99:64:d3:35 -j DROP

eingegeben
Wider Erwarten bleibt br1 gestartet, zusätzlich werden br1.10 und br1.11 erzeugt. Der Ping wird wie gewünscht beantwortet - aber nach einem Reboot ist alles wieder negativ, auch nachdem die ebtables-Regel wieder eingegeben wurde kommt kein Ping mehr an (host unreachable). Die br1 ist jetzt nicht mehr aktiv.
brctl show

Code: Alles auswählen

bridge name	bridge id		STP enabled	interfaces
br0       8000.d0509964d334	yes		eth0
br1.10		8000.d0509964d335	yes		eth1.10
br1.11		8000.d0509964d335	yes		eth1.11
br2	     8000.000000000000	no		

ebtables -t broute -L

Code: Alles auswählen

Bridge table: broute

Bridge chain: BROUTING, entries: 1, policy: ACCEPT
-p 802_1Q -d d0:50:99:64:d3:35 -i eth1 -j DROP 

Muss in der ebtables-Regel ev. statt eth1 -> eth1.10 eingegeben werden?
In Moment bin ich ziemlich ratlos wie ich weiter verfahren soll
Gruß max

[dufty2]

Yo, irgendwie ist das alles ein ziemlicher hack

Hab' jetzt dazu gelernt, dass die Linux Bridge in neuester Zeit doch "VLAN-aware" ist:
http://events.linuxfoundation.org/sites ... kita_0.pdf
Seite 34ff.

Dann bräuchte man auch nur noch eine Bridge/Switch, vgl. Seite 39.
Und somit - vermutlich - auch kein BROUTING mehr
Hab's aber selbst noch nicht ausprobiert.

[max123kl]

Yo, irgendwie ist das alles ein ziemlicher hack

Hab' jetzt dazu gelernt, dass die Linux Bridge in neuester Zeit doch "VLAN-aware" ist:
http://events.linuxfoundation.org/sites ... kita_0.pdf
Seite 34ff.
Dann bräuchte man auch nur noch eine Bridge/Switch, vgl. Seite 39.
Und somit - vermutlich - auch kein BROUTING mehr
Hab's aber selbst noch nicht ausprobiert.

In der Kompaktheit ziemlich schwerer Stoff für mich - ohne zusätzliche Infos kann ich das kaum verstehen.
Ich muss mir dazu noch etwas "Literatur" besorgen.
Vorläufig werde ich mich auf das ungetaggte Netz beschränken und später einen neuen Versuch wagen.
Gruß max

[EDIT] Ich habe jetzt die gewünschte Konfiguration über einen Remote-Connect mit Hilfe des "virt-manager" hinbekommen.
Keine Ahnung warum das mit der interfaces-Datei nicht geklappt hat.