Hi wir haben einen Server mit 6 Nic am Start, wobei Nic 2 + 3 als Bridge Br0 laufen sollen. Wenn ich mir mit tcpdump eth2 und eth3 ansehe, sehe ich jedoch nicht den selben Traffic. Ich bin davon ausgegangen, das der Traffic 1zu1 weitergleitet wird. Wir wollen später über IPtables den Trafic zwischen eth2 und eth3 Filtern (FW/iptables). Anbei meine Config, für den goldenen Tipp wäre ich dankbar. [root@fil-fra network-scripts]# more ifcfg-* :::::::::::::: ifcfg-br0 :::::::::::::: DEVICE=br0 TYPE=Bridge IPADDR=192.168.10.2 NETMASK=255.255.255.0 BROADCAST=192.168.10.255 NETWORK=192.168.10.0 STP=no IPV6INIT=no ONBOOT=yes BOOTPROTO=none :::::::::::::: ifcfg-eth0 :::::::::::::: # Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) DEVICE=eth0 BOOTPROTO=none BROADCAST=xx.xx.18.63 HWADDR=00:0E:0C:68:06:F0 IPADDR=xx.xx.18.50 IPV6INIT=no IPV6_AUTOCONF=no NETMASK=255.255.255.192 NETWORK=xx.xx.18.0 ONBOOT=yes GATEWAY=xx.xx.18.1 TYPE=Ethernet :::::::::::::: ifcfg-eth1 :::::::::::::: # Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) DEVICE=eth1 HWADDR=00:0E:0C:68:06:F1 ONBOOT=no BOOTPROTO=dhcp TYPE=Ethernet :::::::::::::: ifcfg-eth2 :::::::::::::: # Intel Corporation 82546GB Gigabit Ethernet Controller (Copper) DEVICE=eth2 HWADDR=00:1B:21:52:0F:78 ONBOOT=yes BRIDGE=br0 :::::::::::::: ifcfg-eth3 :::::::::::::: # Intel Corporation 82546GB Gigabit Ethernet Controller (Copper) DEVICE=eth3 HWADDR=00:1B:21:52:0F:79 ONBOOT=yes BRIDGE=br0 :::::::::::::: ifcfg-eth4 :::::::::::::: # Intel Corporation 82546GB Gigabit Ethernet Controller (Copper) DEVICE=eth4 HWADDR=00:1B:21:52:0F:7A TYPE=ETHER #BRIDGE=br1 ONBOOT=yes BOOTPROTO=dhcp :::::::::::::: ifcfg-eth5 :::::::::::::: # Intel Corporation 82546GB Gigabit Ethernet Controller (Copper) DEVICE=eth5 HWADDR=00:1B:21:52:0F:7B TYPE=ETHER #BRIDGE=br1 ONBOOT=yes BOOTPROTO=dhcp :::::::::::::: ifcfg-lo :::::::::::::: DEVICE=lo IPADDR=127.0.0.1 NETMASK=255.0.0.0 NETWORK=127.0.0.0 # If you're having problems with gated making 127.0.0.0/8 a martian, # you can change this to something else (255.255.255.255, for example) BROADCAST=127.255.255.255 ONBOOT=yes NAME=loopback [root@fil-fra network-scripts]#uname -a Linux fil-fra 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux[root@fil-fra network-scripts]#brctl show bridge name bridge id STP enabled interfaces br0 8000.001b21520f78 no eth3 eth2 [root@fil-fra network-scripts]#[root@rtp-filter-frankfurt network-scripts]# ifconfig -a br0 Link encap:Ethernet HWaddr 00:1B:21:52:0F:78 inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::21b:21ff:fe52:f78/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8454 errors:0 dropped:0 overruns:0 frame:0 TX packets:34 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:413866 (404.1 KiB) TX bytes:8500 (8.3 KiB) eth0 Link encap:Ethernet HWaddr 00:0E:0C:68:06:F0 inet addr:xx.xx.18.50 Bcast:xx.xx.18.63 Mask:255.255.255.192 inet6 addr: fe80::20e:cff:fe68:6f0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:42052 errors:0 dropped:0 overruns:0 frame:0 TX packets:47260 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:5850469 (5.5 MiB) TX bytes:28105052 (26.8 MiB) Base address:0x3040 Memory:fe8c0000-fe8e0000 ... eth2 Link encap:Ethernet HWaddr 00:1B:21:52:0F:78 inet6 addr: fe80::21b:21ff:fe52:f78/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:361408 errors:0 dropped:0 overruns:0 frame:0 TX packets:204 errors:0 dropped:0 overruns:0 carrier:0 collisions:1 txqueuelen:100 RX bytes:41240902 (39.3 MiB) TX bytes:54453 (53.1 KiB) Memory:fe780000-fe7a0000 eth3 Link encap:Ethernet HWaddr 00:1B:21:52:0F:79 inet6 addr: fe80::21b:21ff:fe52:f79/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:196596 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:12424750 (11.8 MiB) Memory:fe7a0000-fe7c0000 ...
lg Jan
__________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
Am Mittwoch, den 03.02.2010, 10:28 +0100 schrieb jan vollme:
Hi
wir haben einen Server mit 6 Nic am Start, wobei Nic 2 + 3 als Bridge Br0 laufen sollen. Wenn ich mir mit tcpdump eth2 und eth3 ansehe, sehe ich jedoch nicht den selben Traffic. Ich bin davon ausgegangen, das der Traffic 1zu1 weitergleitet wird. Wir wollen später über IPtables den Trafic zwischen eth2 und eth3 Filtern (FW/iptables). Anbei meine Config, für den goldenen Tipp wäre ich dankbar.
Hall Jan
hast du denn die firewall an? Wenn ja dann schalte sie doch einmal aus und teste dann mal. Wenn die Firewall läuft und _alles_ ungefiltert über die Bridge gehen soll dann brauchst Du dafür eine Regel in der Art: Chain FORWARD: ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
thus Christoph Maser spake:
Am Mittwoch, den 03.02.2010, 10:28 +0100 schrieb jan vollme:
Hi
wir haben einen Server mit 6 Nic am Start, wobei Nic 2 + 3 als Bridge Br0 laufen sollen. Wenn ich mir mit tcpdump eth2 und eth3 ansehe, sehe ich jedoch nicht den selben Traffic. Ich bin davon ausgegangen, das der Traffic 1zu1 weitergleitet wird. Wir wollen später über IPtables den Trafic zwischen eth2 und eth3 Filtern (FW/iptables). Anbei meine Config, für den goldenen Tipp wäre ich dankbar.
Hall Jan
hast du denn die firewall an? Wenn ja dann schalte sie doch einmal aus und teste dann mal. Wenn die Firewall läuft und _alles_ ungefiltert über die Bridge gehen soll dann brauchst Du dafür eine Regel in der Art: Chain FORWARD: ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged
Chris
Unicasts sollten nicht über die Bridge gehen, wenn die entsprechenden zwei Maschinen im gleichen Segment hängen -- Broadcasts schon.
Timo
Am Mittwoch, den 03.02.2010, 10:48 +0100 schrieb Timo Schoeler:
Unicasts sollten nicht über die Bridge gehen, wenn die entsprechenden zwei Maschinen im gleichen Segment hängen -- Broadcasts schon.
Timo
Wieso denn das bitte? Eine Bridge sollte layer2 transparent sein, und darum unterstützt sie normalerweise ARP und STP.
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
On Wed, Feb 03, 2010 at 11:11:53AM +0100, Christoph Maser wrote:
Am Mittwoch, den 03.02.2010, 10:48 +0100 schrieb Timo Schoeler:
Unicasts sollten nicht über die Bridge gehen, wenn die entsprechenden zwei Maschinen im gleichen Segment hängen -- Broadcasts schon.
Timo
Wieso denn das bitte? Eine Bridge sollte layer2 transparent sein, und darum unterstützt sie normalerweise ARP und STP.
Wenn sie transparent für Schicht 2 sein soll, braucht sie doch kein ARP oder STP unterstützen, sondern würde nur auf Schicht 1 operieren.
Aber auf für das eigentliche Szenario ist es auch irrelevant, da mit auf der Bridge eh nicht per iptables die Kommunikation zwischen den Maschinen im gleichen Segment unterbinden kann. Dafür müßte halt jede Maschine an einem eigenen Port hängen.
Grüße Till
Am Mittwoch, den 03.02.2010, 11:42 +0100 schrieb Till Maas:
On Wed, Feb 03, 2010 at 11:11:53AM +0100, Christoph Maser wrote:
Am Mittwoch, den 03.02.2010, 10:48 +0100 schrieb Timo Schoeler:
Unicasts sollten nicht über die Bridge gehen, wenn die entsprechenden zwei Maschinen im gleichen Segment hängen -- Broadcasts schon.
Timo
Wieso denn das bitte? Eine Bridge sollte layer2 transparent sein, und darum unterstützt sie normalerweise ARP und STP.
Wenn sie transparent für Schicht 2 sein soll, braucht sie doch kein ARP oder STP unterstützen, sondern würde nur auf Schicht 1 operieren.
Aber auf für das eigentliche Szenario ist es auch irrelevant, da mit auf der Bridge eh nicht per iptables die Kommunikation zwischen den Maschinen im gleichen Segment unterbinden kann. Dafür müßte halt jede Maschine an einem eigenen Port hängen.
Grüße Till
Eigentlich ist das Standard-Layout für eine Bridging-Firewall.
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Am Wed, 3 Feb 2010 11:11:53 +0100 schrieb Christoph Maser cmr@financial.com:
Wieso denn das bitte? Eine Bridge sollte layer2 transparent sein, und darum unterstützt sie normalerweise ARP und STP.
Was ist "layer2 transparent"?
Timo hat recht. Eine Bridge ist ein 2-Port-Switch und der lässt auch nur die Unicasts durch, die auf eine andere collision domain wollen. ARP beinhaltet ja auch broadcasting.
Gruß, Tobias.
Am Mittwoch, den 03.02.2010, 11:46 +0100 schrieb Tobias Crefeld:
Am Wed, 3 Feb 2010 11:11:53 +0100 schrieb Christoph Maser cmr@financial.com:
Wieso denn das bitte? Eine Bridge sollte layer2 transparent sein, und darum unterstützt sie normalerweise ARP und STP.
Was ist "layer2 transparent"?
Timo hat recht. Eine Bridge ist ein 2-Port-Switch und der lässt auch nur die Unicasts durch, die auf eine andere collision domain wollen. ARP beinhaltet ja auch broadcasting.
Gruß, Tobias.
Man vergebe mir die flapsige Ausdrucksweise. Aber grundsätzlich ist das was Jan vor hat die 08/15 bridging Firewall:
+----------+ +----------+ | Desktop | | Server | +-----+----+ +-----+----+ | | eth1 eth0 | | +----------+ +----------+ +-------------+---------| Firewall |-----| Router |-- Internet +----------+ +----------+
Natürlich sieht man hier an der Firewall nicht auf eth1 den gleichen Traffic wie auf eth0. Allerdings sollte (im Sinne des Diagramms) jeglicher Traffic der an den Router oder das "Internet" gerichtet ist hier auf beiden Interfaces zu sehen sein.
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
thus Christoph Maser spake:
Am Mittwoch, den 03.02.2010, 11:46 +0100 schrieb Tobias Crefeld:
Am Wed, 3 Feb 2010 11:11:53 +0100 schrieb Christoph Maser cmr@financial.com:
Wieso denn das bitte? Eine Bridge sollte layer2 transparent sein, und darum unterstützt sie normalerweise ARP und STP.
Was ist "layer2 transparent"?
Timo hat recht. Eine Bridge ist ein 2-Port-Switch und der lässt auch nur die Unicasts durch, die auf eine andere collision domain wollen. ARP beinhaltet ja auch broadcasting.
Gruß, Tobias.
Man vergebe mir die flapsige Ausdrucksweise. Aber grundsätzlich ist das was Jan vor hat die 08/15 bridging Firewall:
+----------+ +----------+ | Desktop | | Server | +-----+----+ +-----+----+ | | eth1 eth0 | | +----------+ +----------+ +-------------+---------| Firewall |-----| Router |-- Internet +----------+ +----------+Natürlich sieht man hier an der Firewall nicht auf eth1 den gleichen Traffic wie auf eth0. Allerdings sollte (im Sinne des Diagramms) jeglicher Traffic der an den Router oder das "Internet" gerichtet ist hier auf beiden Interfaces zu sehen sein.
Ja, aber das war ja gar nicht das geschilderte Phänomen. Es ging darum, daß auf eth0 niemals Verkehr zwischen (in Deinem Beispiel) Server und Desktop zu sehen ist, es sei denn, es ist Broadcast. Da wäre dann der Router die Broadcastgrenze.
Um aber noch einen produktiven Faktor mit reinzubringen: Ein Blick auf ebtables könnte lohnenswert sein... ;)
Chris
MsG,
Timo
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Am Wed, 3 Feb 2010 11:58:26 +0100 schrieb Christoph Maser cmr@financial.com:
+----------+ +----------+ | Desktop | | Server | +-----+----+ +-----+----+ | | eth1 eth0 | | +----------+ +----------+ +-------------+---------| Firewall |-----| Router |--Natürlich sieht man hier an der Firewall nicht auf eth1 den gleichen Traffic wie auf eth0.
Es ist (oder war?) Jans Erwartung, dass er exakt denselben Traffic sieht. Das würde eine Funktionalität wie die eines Hubs ohne Switch-Funktion voraussetzen. Oder die eines Monitoring-Port auf einem Switch. Oder die eines Repeater oder Media-Konverters. Diese sind tatsächlich transparent für Ethernet-Frames.
Bei einer Bridge ist das unabhängig vom Einsatz von Werkzeugen wie iptables, arptables & Co. nicht generell zu erwarten.
Umgekehrt kann man bei Einsatz dieser Tools (und Vorhandensein eines genügend großen Wahnsin... äh, Innovationsfaktors) sogar erreichen, dass selbst Verkehr, der die Bridge passiert, verändert ankommt - Stichwort "Transparent NAT".
Gruß, Tobias.
Am Mittwoch, den 03.02.2010, 10:28 +0100 schrieb jan vollme:
i686 i386 GNU/Linux[root@fil-fra network-scripts]#brctl show bridge name bridge id STP enabled interfaces br0 8000.001b21520f78 no eth3 eth2
Da ist dein Problem "STP enabled no", das musst du einschalten, siehe man brctl.
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
-
Christoph Maser -
jan vollme -
Till Maas -
Timo Schoeler -
Tobias Crefeld