On 6/7/2007 12:12 AM, Greg Scott wrote:
The IP Address for br0 is 1.2.3.2. I setup a system at 1.2.3.1 and
had it ping 1.2.3.2. Everything behaved as expected. With bridging
turned on, none of the iptables rules made any difference, so I
commented them out. With the cable plugged into eth0, none of the
pings replied. Tcpdump on the 1.2.3.2 box didn't even show anything
coming into br0. Connecting to eth1 or eth2, pings replied and
tcpdump showed the ICMP going back and forth on br0. Setting br0 to
1.2.3.2 and eth1 to 10.0.0.1, my external host could ping both IP
Addresses when I fudged in appropriate routes on my test system.
Ok, good to know.
The only other thing that I can think of why you might bind your IP
address(es) to the physical interface verses the bridge interface is if
you were not wanting to bridge IP, but some other non routeable
protocol, say NetBEUI. (But why would you want to do that???) In this
scenario, it would be perfectly normal to use a bridging router to
bridge any thing but IP and route IP.
Here are a couple of my challenges.
I want to block anything coming in from the Internet claiming to come
from 10/8, or 172.16/12 or 192.168/16. But anything from these
address blocks from any trusted eth-- interface should be OK. Easy
to do with pure routing, seems a little more challenging with
bridging. I think I can whip up some rules, but they depend on
ebtables filtering by physical eth-- port.
You should be able to easily do this with a few EBTables rules. Just
check the source IP of the packets as they come in eth0.
ebtables -t filter -N bogonsFromNet -P RETURN
ebtables -t filter -A bogonsFromNet -s 10.0.0.0/8 -j DROP
ebtables -t filter -A bogonsFromNet -s 172.16.0.0/12 -j DROP
ebtables -t filter -A bogonsFromNet -s 192.168.0.0/16 -j DROP
ebtables -t filter -A INPUT -j bogonsFromNet
ebtables -t filter -A FORWARD -j bogonsFromNet
(Note: This is untested.)
If I have things correct, this should be a simple chain that checks the
source IP and blocks drops them if they match. The (new) chain its self
has a default policy of RETURN to return back to the chain that jumped
to it.
You might want to expand your bogons list a bit more to include some
more forbidden networks. I.e. Test Net 192.0.2.x/24... RFC 3330 is
your friend in this matter.
I have a public /24 block, call it 1.2.3.nnn. Some of these are on
eth0, some on eth1, a few others on eth2. Bridging seems to handle
this nicely. eth0 faces the Internet. I am a little nervous in
packaging all this. Let's say something goes haywire in startup,
before I run the brctl stuff. Or let's say something bad happens and
bridging goes haywire. If eth0 has no IP Address, I have no remote
access to the box. So I'd like to at least give an IP Address to
eth0. This seems to work, but like I said, it's not documented to
work. It just hit me what's bugging me - it bugs me to give an IP
Address to a logical device and cut off any kind of fallback access
to the physical device. Maybe I'm looking for trouble that's not
there and creating problems I don't need just because bridging is so
new in my little world. I wonder what others have done in this
situation?
I don't think you are being too paranoid, but I think you should be
aware of something I have run in to in my own testing.
If I have eth0 up with an IP address w.x.y.z and I am connected to it
(via ssh) and I enslave it to a bridge (bri0) (I like 3 letter / 1
number device names) my connection goes dead. I have to try
reconnecting or log in to console and move the IP to the bridge. Well,
at least I think that's what I have to do, it's been too long sense I
last did it and I don't remember the details. You may want to play with
this. The reason that I bring it up is that I think an IP address on
the ether interface is different than an IP address on the enslaved
ether interface. Your mileage may vary. What I'm worried about is that
if the bridging code is seeing the traffic before the system's IP stack
sees it (supported by the fact that you can use EBTables to filter it),
you are still passing through the bridging code even with the IP address
on the enslaved ether interface.
I have personally used bridging extensively for the past 4+ years and
I've been ABSOLUTELY THRILLED with it. I have some systems with four
interfaces bridged together with all IPs on the bri0 interface. I have
another system that is 802.1q trunking to a Layer 2 managed switch with
25+ VLAN interfaces on the trunk. I'm then bridging the 25+ VLANs plus
the enslaved ether interface in one bridge with the IP bound to bri0. I
then have EBTables dividing up what access each VLAN has. Specifically,
each VLAN can communicate with the bri0 interface and the bri0 interface
can communicate with all VLANs, but the VLANs can not communicate with
each other. I even threw in ARP tables and EBTables to masquerade MAC
addresses b/c the managed switch that I was working with could only see
any given MAC on one VLAN. Let's just say this was fun to set up. In
the end, the system has been up and running with out problems at multi
megabit speeds for 3+ years.
And then there's my PPTP clients. I give these guys a 10.0.0.xxx IP
Address with a gateway of 10.0.0.1. This was all part of the eth1
LAN when it was a pure router. I suppose in this bridging setup, I
could make 10.0.0.1 an alias for br0 and leave eth1 with no IP
Address. This just takes a little getting used to I guess.
I don't think you should be scared of bridging and / or EBTables. With
them you can do a LOT of things you could not do other wise.
Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
