mirror of https://github.com/tLDP/LDP
951 lines
34 KiB
Plaintext
951 lines
34 KiB
Plaintext
<!doctype linuxdoc system>
|
|
<!-- $Id$ -->
|
|
<!-- Last checkout: $Date$ -->
|
|
<!-- Created: 2002-06-08, 10:59:43 Nils.Radtke_@_Think-Future.de -->
|
|
<!-- Last modified: Wed 2005-07-13, 01:54:03 CEST (+0200) -> radtkens
|
|
-->
|
|
<!-- Email updated versions to:
|
|
Mendel told me to send new versions to submit@en.tldp.org and subscribe to
|
|
http://lists.tldp.org/
|
|
gleu@wanadoo.fr, emmajane@tldp.org, joyg@us.ibm.com, discuss@en.tldp.org
|
|
with Subject:
|
|
UPDATE: Ethernet Bridge + netfilter HOWTO
|
|
Greg told me to send it additionally to these:
|
|
submit@en.tldp.org gferg@fergusontechgroup.com
|
|
-->
|
|
<article>
|
|
|
|
<title>Ethernet Bridge + netfilter Howto
|
|
|
|
<author><url url="mailto:Nils.Radtke_@_Think-Future.de" name="Nils Radtke">
|
|
|
|
<date>v0.8, July 2005
|
|
<!--
|
|
send email to jdinkel_@_gmail.com James Dinkel, jdinkel_@_gmail.com
|
|
-->
|
|
|
|
<abstract>
|
|
Setting up an ethernet bridge gives us the chance to integrate a surveying and/or
|
|
regulating instance transparently into an existing network. This setup requires no
|
|
changes to the logical network topology. It is accomplished by plugging the ethernet
|
|
bridge in the physical network topology between the network itself and the routing
|
|
instance (that piece of hardware connected to the Internet).
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<p>
|
|
This Howto is available in
|
|
<url url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO/other_formats/" name="other formats">.
|
|
Preferably downloadable:
|
|
<url url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO/Ethernet-Bridge-netfilter-HOWTO.tar.gz" name="documentation tarball">.
|
|
You may find this Howto as part of the
|
|
<url url="http://www.tldp.org/docs.html#howto" name="Linux Documentation Project">.
|
|
|
|
<p>
|
|
Looking for other languages? See the
|
|
<url url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO_de/" name="German version">, then!
|
|
And as of march 2003 there is a french version available with courtesy of François Romieu and Guillaume Lelarge: <url url="http://fr.tldp.org/HOWTO/lecture/Ethernet-Bridge-netfilter-HOWTO.html" name="French version">.
|
|
Today, some day in july 2005, I stumbled across an italian version of this HOWTO! Unfortunately there's no translator's note in the document, courtesy is unbeknownst so far: <url url="http://ftp-ildp.httpdnet.com/Ethernet-Bridge-netfilter-HOWTO" name="Italian version">.
|
|
|
|
<p>
|
|
<descrip>
|
|
<tag>2005-07-12:</tag>
|
|
Added link to italian version of this HOWTO (see above).
|
|
Plus a section about making the changes
|
|
<ref id="reboot" name="reboot-persistent">, a note about
|
|
<ref id="kernel-2.6" name="2.6 kernel not working as expected">
|
|
and the <ref id="user-exp" name="user experiences-section">.
|
|
Included the <ref id="final-note" name="Final note-section">. :)
|
|
|
|
<tag>2005-06-06:</tag>
|
|
Unfortunately, the linux documentation project does not
|
|
respond actively to update requests. This results in an outdated
|
|
version of the on www.tldp.org site. Use this site instead, if you
|
|
want to stick with the most actual version of the HOWTO.
|
|
Blame the tldp people.
|
|
|
|
<tag>2004-08-03:</tag>
|
|
Carsten (C DOT Lueth AT fielmann DOT com) has found a variant for <url url="http://www.tecchannel.de/software/1387/0.html" name="MS Windows (TM) systems">.
|
|
|
|
<tag>2004-06-13:</tag>
|
|
Update on used kernel versions,
|
|
warning about <ref id="HINT_cutoff" name="remote administering">,
|
|
<ref id="HINT_netfilter_debugging" name="netfilter debugging"> code.
|
|
New translation available: French (link c. f. above).
|
|
Discontinued german version.
|
|
|
|
<tag>2002-09-19:</tag>
|
|
links about ebtables have been updated in the
|
|
"Related Topics" Section. Added note about
|
|
<ref id="HINT_False_positive" name=""false positive" br-nf debugging output">.
|
|
|
|
<tag>2002-10-08:</tag>
|
|
Added section <ref id="TESTING_actual_configuration" name="Actual configuration">
|
|
and hints about routing in
|
|
<ref id="BRIDGE_routing" name="Setting up the routing">,
|
|
<ref id="TESTING_routing" name="Ping it, Jim!">
|
|
, resp.
|
|
</descrip>
|
|
|
|
|
|
|
|
<!-- #################### -->
|
|
<!-- ### introduction ### -->
|
|
<sect>Introduction
|
|
<p>
|
|
Ethernet bridges connect two or more distinct ethernet segments transparently.
|
|
<newline>
|
|
An ethernet bridge distributes ethernet frames coming in on one port to other
|
|
ports associated to the bridge interface. This is accomplished with
|
|
brain: Whenever the bridge knows on which port the MAC address to which the
|
|
frame is to be delivered is located it forwards this frame only to this only
|
|
port instead of polluting all ports together.
|
|
<p>
|
|
Ethernet interfaces can be added to an existing bridge interface
|
|
and become then (logical) ports of the bridge interface.
|
|
<p>
|
|
Putting a netfilter structure on top of a bridge interface renders the
|
|
bridge capable of servicing filtering mechanisms. This way, a
|
|
transparent filtering instance can be created. It even needs no IP address
|
|
assigned to work. Of course, you can assign an IP address to the bridge
|
|
interface for maintenance purposes ( certainly, with ssh only ;-).
|
|
<p>
|
|
The advantage of this system is evident. Transparency alleviates the network
|
|
administrator of the pain of restructuring the network topology. And users may
|
|
not notice the existence of the bridge but their connection beeing
|
|
blocked. Also, users are not disturbed while working (think of a company where
|
|
network connection loss pays alot).
|
|
<p>
|
|
The other common case is a client beeing connected to the global web via a
|
|
leased router. As the providers seldomly grant administration privileges on
|
|
their leasing hardware, the client cannot change the interconnecting
|
|
configuration. But, of course, the client has a network running, and wants
|
|
to spend at least as possible, he does not want to reconfigure his entire
|
|
network. And he does not need to if he uses a bridging device.
|
|
<!--Bridging: Legt die Ethernet frames eines Segmentes auf das Interface
|
|
eines anderen Segmentes. FW auf der Ethernet Bridge ermoeglicht die
|
|
Verbindungskontrolle.
|
|
Eine Ethernet Bridge ist fuer die verbundenen Netzwerke nicht sichtbar.
|
|
Sie kann 2 oder mehr Ethernet Segmente verbinden, ohne Eingriff in die
|
|
bestehende Netzwerk-Topologie. Ein weiterer Vorteil eroeffnet sich, wenn
|
|
der Router nach extern nicht der eigenen Administration angehoert und
|
|
somit eine Modifikation der Netzwerk-Topologie ausgeschlossen ist.
|
|
-->
|
|
|
|
<!-- ### introduction ### -->
|
|
<!-- #################### -->
|
|
|
|
|
|
<!-- ############ -->
|
|
<!-- ### make ### -->
|
|
<sect>Required software
|
|
<p>
|
|
This software setup is needed on the ethernet bridge computer. According to our <ref id="TESTING_Testing_grounds" name="Testing grounds">.
|
|
|
|
<sect1>Featured Linux kernel <label id="kernel-2.6">
|
|
<p>
|
|
|
|
Use of kernel 2.6 is not yet a good idea. Yes, it's astonishing. The why the
|
|
bridging code
|
|
breaks and where it does so has not yet come to my and others attention, I
|
|
cannot recommend kernels of the 2.6 series. You have the clou? Assure yourself
|
|
the credit, mail the solution to me (e-mail address at entry page).
|
|
See also <ref id="kernel-notes" name="Kernel-Notes"> for additional
|
|
information on this. So far, use kernel 2.4 series.
|
|
<newline>
|
|
As of kernel version <em/2.4.18/ there's already support for the Ethernet Bridge
|
|
capability built-in. No patches needed so far.
|
|
Regarding later kernel versions, it must be stated that <em/2.4.23/ might be less recommendable, especially in conjunction with ebtables and netfilter-bridging. Later versions seem advisable.
|
|
<newline>
|
|
The following paragraph is outdated now (2005-07-12) as all we need is present in kernel. You may skip this paragraph, it is only retained for legacy:<newline>
|
|
But if we intend to use netfilter capabilities, because we want to run iptables on our new Linux router/fw box, we still need to apply a patch.
|
|
Any patches needed can be found and downloaded on the <ref id="LINK_Bridge-home" name="sourceforge Ethernet Bridge homepage">.
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> cd /usr/src/
|
|
root@bridge:~> wget -c http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff
|
|
root@bridge:~> cd /usr/src/linux/
|
|
root@bridge:~> patch -p1 -i ../bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff
|
|
</verb>
|
|
</tscreen>
|
|
|
|
Supposedly we want netfilter support on our bridge interface and we have already
|
|
patched the vanillal kernel we may now activate some necessary kernel configuration
|
|
items. On how to build a private kernel image see the
|
|
<url url="http://www.think-future.de/DOCUMENTATION/CD-Net-Install-HOWTO/CD-Net-Install-HOWTO-4.html#Kernel_Configuration" name="CD-Net-Install-HOWTO, Toolbox">.
|
|
Oh, yeah, it's still in German only. Hm, I should fix this some time, but time lacks... Any volunteers? (deadly silence is cracking.. ;)
|
|
|
|
Nevertheless, we start by now:
|
|
In
|
|
<tscreen>
|
|
<verb>
|
|
Code maturity level options
|
|
</verb>
|
|
</tscreen>
|
|
we activate
|
|
<tscreen>
|
|
<verb>
|
|
[*] Prompt for development and/or incomplete code/drivers
|
|
</verb>
|
|
</tscreen>
|
|
and in
|
|
<tscreen>
|
|
<verb>
|
|
Loadable module support
|
|
</verb>
|
|
</tscreen>
|
|
<tscreen>
|
|
<verb>
|
|
[*] Enable loadable module support
|
|
[*] Set version information on all module symbols
|
|
[*] Kernel module loader
|
|
</verb>
|
|
</tscreen>
|
|
Ok, so far so good.
|
|
Now, we go to
|
|
<tscreen>
|
|
<verb>
|
|
Networking options
|
|
</verb>
|
|
</tscreen>
|
|
and mark
|
|
<tscreen>
|
|
<verb>
|
|
[*] Network packet filtering (replaces ipchains)
|
|
[ ] Network packet filtering debugging
|
|
</verb>
|
|
</tscreen>
|
|
<label id="HINT_netfilter_debugging">
|
|
<descrip>
|
|
<tag>Note:</tag>
|
|
Previously, the above debugging option had been selected. For now,
|
|
unless you want your <tt>/var/log/</tt>-partition being filled up in
|
|
short-time distance, deactivate this option.
|
|
<newline>
|
|
If this options is activated, messages similar to the following appear
|
|
in counts of thousands in dmesg and <tt>/var/log/{kern.log,debug,syslog,messages}</tt>:
|
|
<tscreen>
|
|
<verb>
|
|
skb: pf=2 (unowned) dev=br0 len=52
|
|
PROTO=6 156.136.32.121:3709 192.168.101.2:112 L=52 S=0x00 I=35470 F=0x4000 T=51
|
|
nf_hook: hook 1 already set.
|
|
skb: pf=2 (unowned) dev=br0 len=52
|
|
PROTO=6 156.136.32.121:3709 192.168.101.2:112 L=52 S=0x00 I=35470 F=0x4000 T=51
|
|
nf_hook: hook 0 already set.
|
|
skb: pf=2 (unowned) dev=br0 len=52
|
|
PROTO=6 192.168.101.11:2828 192.168.101.2:202 L=52 S=0x10 I=63 F=0x4000 T=64
|
|
nf_hook: hook 1 already set.
|
|
skb: pf=2 (unowned) dev=br0 len=52
|
|
PROTO=6 192.168.101.11:2828 192.168.101.2:202 L=52 S=0x10 I=63 F=0x4000 T=64
|
|
nf_hook: hook 3 already set.
|
|
skb: pf=7 (owned) dev=eth1 len=1500
|
|
</verb>
|
|
</tscreen>
|
|
|
|
</descrip>
|
|
|
|
Furthermore, in
|
|
<tscreen>
|
|
<verb>
|
|
IP: Netfilter Configuration --->
|
|
</verb>
|
|
</tscreen>
|
|
we mark any item we need as module.
|
|
Now the long awaited item: activate
|
|
<tscreen>
|
|
<verb>
|
|
<M> 802.1d Ethernet Bridging
|
|
</verb>
|
|
</tscreen>
|
|
as well as
|
|
<tscreen>
|
|
<verb>
|
|
[*] netfilter (firewalling) support
|
|
</verb>
|
|
</tscreen>
|
|
<descrip>
|
|
<tag>Note:</tag>
|
|
The above entry is available only if we successfully patched our kernel!
|
|
</descrip>
|
|
|
|
Finally, we just need a successful
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> make dep clean bzImage modules modules_install
|
|
</verb>
|
|
</tscreen>
|
|
cycle and we're done.
|
|
Don't forget to edit <tt>/etc/lilo.conf</tt> and do
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> lilo -t
|
|
root@bridge:~> lilo
|
|
root@bridge:~> reboot
|
|
</verb>
|
|
</tscreen>
|
|
, though.
|
|
|
|
<descrip>
|
|
<tag>Hint:</tag>
|
|
Perhaps we might mark our new kernel as the bridge kernel? We
|
|
<tt/vi/ the toplevel Makefile in our kernel sources and edit the head
|
|
line called <tt>EXTRAVERSION =</tt>.
|
|
We may actually set it to, say <em/bridge/? ;-)
|
|
<newline>
|
|
After the <tt/modules_install/ we find the fresh modules in
|
|
<tt>/lib/modules/2.4.18bridge</tt>
|
|
<newline>
|
|
For debian users (eventually use <tt>export PATCH_THE_KERNEL=YES</tt>
|
|
before and --added_patches your_patches with make-kpkg):
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> make-kpkg --revision=tf.1.0 kernel_image
|
|
</verb>
|
|
</tscreen>
|
|
</descrip>
|
|
|
|
<sect1>Userspace tool: <tt/brctl/
|
|
<p>
|
|
Once our kernel has the capabilities needed to perform Ethernet Bridge and netfilter
|
|
actions, we prepare the user space tool <tt/brctl/. <tt/brctl/ is the configuration
|
|
tool we use to <ref id="SETUP_Linux_brctl" name="set up"> anything to suit our needs.
|
|
|
|
We <ref id="LINK_Bridge-home" name="download the source tarball">, unpack it and
|
|
change directory into it.
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> wget -c http://bridge.sourceforge.net/bridge-utils/bridge-utils-0.9.5.tar.gz
|
|
root@bridge:~> tar xvzf bridge-utils-0.9.5.tar.gz
|
|
root@bridge:~> cd bridge-utils-0.9.5
|
|
</verb>
|
|
</tscreen>
|
|
At this time, read the <tt/README/ and the files in the <tt>doc/</tt> subdirectory.
|
|
Then do a simple make and copy the resulting <tt>brctl/brctl</tt> executable to
|
|
<tt>/sbin/</tt>.
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> make
|
|
root@bridge:~> cp -vi brctl/brctl /sbin/
|
|
</verb>
|
|
</tscreen>
|
|
This is it. Go for <ref id="SETUP_Linux_brctl" name="Setup"> now.
|
|
|
|
<sect1> Kernel-Notes <label id="kernel-notes">
|
|
<p>
|
|
Symptom: Anything during setup works but packets do no longer traverse as they did in 2.4 the bridge interfaces.
|
|
<newline>
|
|
ipuk s (qasuari_ @ _yahoo.com) wrote (about june 2005):
|
|
<tscreen>
|
|
<verb>
|
|
[...]
|
|
I have to compile my kernel from 2.4.18-14 to 2.6.0 and activate
|
|
bridge-netfilter&ebtables.
|
|
After compiling, i can't ping from a host to interface of linux box.
|
|
Linux box just have 1 interface.whats wrong with my compilation ???
|
|
[...]
|
|
</verb>
|
|
</tscreen>
|
|
|
|
<!-- ### make ### -->
|
|
<!-- ############ -->
|
|
|
|
<!-- ############# -->
|
|
<!-- ### Setup ### -->
|
|
<sect>Set Linux up to serve<label id="SETUP_Linux_brctl">
|
|
<p>
|
|
|
|
<sect1>Setting up the bridge
|
|
<p>
|
|
We need Linux to know about the bridge. First tell it that we want one virtual
|
|
ethernet bridge interface: (this is to be executed on host <tt/bridge/, of course.
|
|
See <ref id="TESTING_Testing_grounds" name="Testing grounds">)
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> brctl addbr br0
|
|
</verb>
|
|
</tscreen>
|
|
Second, we do not need the STP (Spanning Tree Protocol). I.e. we do only have
|
|
one single router, so a loop is highly improbable. We may then deactivate this feature.
|
|
(Results in less polluted networking environment, too):
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> brctl stp br0 off
|
|
</verb>
|
|
</tscreen>
|
|
After these preparations, we now do finally some effective commands. We add our two
|
|
(or even more) physical ethernet interfaces. That means, we attach them to the just
|
|
born logical (virtual) bridge interface <tt/br0/.
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> brctl addif br0 eth0
|
|
root@bridge:~> brctl addif br0 eth1
|
|
</verb>
|
|
</tscreen>
|
|
<label id="HINT_cutoff">
|
|
<descrip>
|
|
<tag/Important Note:/
|
|
People sent me emails that it would have helped them if I stressed more
|
|
clearly the risk of being cut off. So listen at this point to my
|
|
warnings:
|
|
<newline>
|
|
If you read this, you are one (small) step before you _might_ cut
|
|
yourself off your box you are going to subverse to a bridging device.
|
|
<newline>
|
|
If you love living on bleeding edges, it is now the instant to prepare
|
|
your first aid material. You will likely need it.
|
|
<newline>
|
|
If you do not have physical access, nor does another person within your
|
|
range:
|
|
<newline>
|
|
DO NOT PROCEED UNLESS YOUR FINGERS LEFT THE KEYBOARD IN FRONT OF YOU
|
|
AND YOUR EYES FIXED REFLECTIVELY SOMETHING OTHER THAN YOUR CONSOLE.
|
|
<newline>
|
|
You have been warned, now. No responsability is assumed for anything
|
|
at all.
|
|
</descrip>
|
|
Now, our two previously physical ethernet interfaces became a logical bridge port each.
|
|
Erm, ok, there were and will be the physical devices. They are still there,
|
|
go have a look ;-) But now they became part of the logical bridge device and
|
|
therefore need no IP configuration any longer. So release the IPs:
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> ifconfig eth0 down
|
|
root@bridge:~> ifconfig eth1 down
|
|
root@bridge:~> ifconfig eth0 0.0.0.0 up
|
|
root@bridge:~> ifconfig eth1 0.0.0.0 up
|
|
</verb>
|
|
</tscreen>
|
|
Great! We now have a box w/o any IP attached. So if you were configuring your future
|
|
fw/router via TP, go for your local console now ;-)) You have a serial console? Happy one :-)
|
|
<newline>
|
|
<descrip>
|
|
<tag/Optional:/
|
|
We tell Linux the new (logical) interface and associate one single IP with it:
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> ifconfig br0 10.0.3.129 up
|
|
</verb>
|
|
</tscreen>
|
|
</descrip>
|
|
And we're done.
|
|
<newline>
|
|
Read the <ref id="TESTING_Important_note" name="Important Note">!
|
|
|
|
<sect1>Setting up the routing
|
|
<p>
|
|
<label id="BRIDGE_routing">
|
|
In case we are configuring a gateway we enable the forwarding in
|
|
the linux kernel.
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
|
|
</verb>
|
|
</tscreen>
|
|
Our box already has an IP assigned but no default route. We
|
|
solve this now:
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> route add default gw 10.0.3.129
|
|
</verb>
|
|
</tscreen>
|
|
Finally, we should have a working net from, to and through the gateway.
|
|
|
|
<sect1>Make it happen again! <label id="reboot">
|
|
<p>
|
|
Aka: We need the changes to persist reboots.
|
|
<newline>
|
|
To do so, you need some sh-style script and put this in the appropriate
|
|
system boot-up directory: <tt>/etc/init.d/</tt>
|
|
<newline>
|
|
Secondly, you create the link in your runlevel directory.
|
|
The correct directory depends on your gusto and of course on your linux
|
|
distribution.
|
|
Common runlevel values on workstations are <tt/2/, <tt/3/ and <tt/5/.
|
|
Examples are: <tt>/etc/rc?.d/</tt> (replace the ? with the right runlevel)
|
|
<newline>
|
|
Also, you need an idea as when your network interfaces are torn up.
|
|
For now, we assume, your network interfaces are activated at system priority
|
|
<tt/S/ so we need not to care of.
|
|
If you ever should feel the need to know exactly, look in <tt>/etc/rcS.d/</tt>.
|
|
We just want the bridge to be up and operable as soon as possible and so chose
|
|
our priority to be <tt/10/. (Make sure, no service requiring bridging devices
|
|
is started before, read: with priority-values less than <tt/10/)
|
|
<newline>
|
|
For now, we assume, your runlevel is <tt/5/:
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> mv -i bridge.sh /etc/init.d/
|
|
root@bridge:~> cd /etc/rc5.d/
|
|
root@bridge:~> ln -s ../init.d/bridge.sh S10bridge.sh
|
|
</verb>
|
|
</tscreen>
|
|
Virtually any distribution provides you with some runlevel-checker or
|
|
equivalent tool that assists you in the tedious job of administering runlevel
|
|
links. Consult your distro-documentation on this.
|
|
<newline>
|
|
Hint: debian has update-rc.d, redhat and successors have chkconfig.
|
|
Finally, SuSE evidentally has also it's own tool, too (of which I don't
|
|
recall the name easily..).
|
|
<newline>
|
|
Wondering about the contents of bridge.sh? ;-)
|
|
<tscreen>
|
|
<verb>
|
|
#!/bin/bash
|
|
PATH="/sbin:/usr/sbin:/usr/local/sbin";
|
|
slaveIfs="1 2 3 4 6 7 8 9 10";
|
|
cmd="$1";
|
|
[ -z "$cmd" ] && cmd="start";
|
|
case "$cmd" in
|
|
start)
|
|
brctl addbr br0;
|
|
brctl stp br0 on;
|
|
brctl addif br0 eth0;
|
|
brctl addif br0 eth1;
|
|
(ifdown eth0 1>/dev/null 2>&1;);
|
|
(ifdown eth1 1>/dev/null 2>&1;);
|
|
ifconfig eth0 0.0.0.0 up;
|
|
ifconfig eth1 0.0.0.0 up;
|
|
ifconfig br0 10.0.3.129 broadcast 10.0.3.255 netmask 255.255.255.0 up ### Adapt to your needs.
|
|
route add default gw 10.0.3.129; ### Adapt to your needs.
|
|
for file in br0 eth0 eth1;
|
|
do
|
|
echo "1" > /proc/sys/net/ipv4/conf/${file}/proxy_arp;
|
|
echo "1" > /proc/sys/net/ipv4/conf/${file}/forwarding;
|
|
done;
|
|
echo "1" > /proc/sys/net/ipv4/ip_forward;
|
|
;;
|
|
stop)
|
|
brctl delif br0 eth0;
|
|
brctl delif br0 eth1;
|
|
ifconfig br0 down;
|
|
brctl delbr br0;
|
|
#ifup eth0; ### Adapt to your needs.
|
|
#ifup eth1; ### Adapt to your needs.
|
|
;;
|
|
restart,reload)
|
|
$0 stop;
|
|
sleep 3;
|
|
$0 start;
|
|
;;
|
|
esac;
|
|
</verb>
|
|
</tscreen>
|
|
And, yes, make it executable..
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> chmod 700 /etc/init.d/bridge.sh
|
|
</verb>
|
|
</tscreen>
|
|
After all, make sure your bridge survives unattended reboots. It's the
|
|
same story as with backups: you should test it before you need it.
|
|
|
|
|
|
<!-- ### Setup ### -->
|
|
<!-- ############# -->
|
|
|
|
<!-- ############### -->
|
|
<!-- ### Testing ### -->
|
|
<sect>Test your new bridged environment! <label id="TESTING_Testing_grounds">
|
|
<p>
|
|
|
|
|
|
|
|
<sect1>Testing Grounds
|
|
<p>
|
|
We imagine this scenario or similar:
|
|
<tscreen>
|
|
<verb>
|
|
/\
|
|
Ethernet Ethernet ATM /-/ \
|
|
--------- --------- --------- /-/ |
|
|
| Box |----------|Bridge |----------|Router |-----| Inter- \
|
|
--------- --------- --------- \ net ---|
|
|
^ ^ ^ ^ \ /
|
|
| | | | \---/
|
|
eth0 eth0 eth1 if0 ^
|
|
| | | | |
|
|
10.0.3.2 none/10.0.3.1 195.137.15.7 anything else
|
|
\ /
|
|
\ /
|
|
^ \-br0-/
|
|
| ^ ^
|
|
| ^ | |
|
|
| | | |
|
|
own own foreign hostile
|
|
</verb>
|
|
</tscreen>
|
|
Our administrative power includes only machines marked with <tt/own/, the Router is
|
|
completely off-limits and so is the Internet, of course.
|
|
<newline>
|
|
That means, if we want to control the flying bits'n'bytes on the ethernet wire we can
|
|
chose to integrate a common firewall or file in a bridge.
|
|
<newline>
|
|
Drawback of the standard
|
|
way is you have to change the default gateway route on every and any single host in
|
|
your net. And this is really a heavy weighting drawback, nobody wants to change more
|
|
than 5 default routes on 5 different hosts more than one time. Keep the time in mind,
|
|
this will consume, also! Not to forget, this is a error-prone way to handle the more
|
|
about security..
|
|
<newline>
|
|
The other way is clean, less time-consuming, more secure and less error-prone.
|
|
More secure in that we won't have the need to assign any IP address. No IP, no danger.
|
|
So far the theory, we hope, our stacks are safe. (Although this hope should better not
|
|
relied on..) The overall advantage is, this bridge-setup is completely transparent,
|
|
no IP, MAC, .. changes at all.
|
|
<newline>
|
|
So it's up to you to chose your preferred method. But we will handle just the fancy one here ;-)
|
|
|
|
|
|
<sect1>Ping it, Jim!
|
|
<p>
|
|
We will configure the Box' eth0 as usual. The bridge's interfaces
|
|
are configured as described in <ref id="SETUP_Linux_brctl" name="Setup">.
|
|
<newline>
|
|
<label id="TESTING_routing">
|
|
If we are to use forwarding we might perhaps do this one: ;-)
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
|
|
</verb>
|
|
</tscreen>
|
|
Optionally, we set up a default route:
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> route add default gw 10.0.3.129
|
|
</verb>
|
|
</tscreen>
|
|
Then we set up some iptables rules on host <tt/bridge/:
|
|
<label id="TESTING_iptables_listing">
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> iptables -P FORWARD DROP
|
|
root@bridge:~> iptables -F FORWARD
|
|
root@bridge:~> iptables -I FORWARD -j ACCEPT
|
|
root@bridge:~> iptables -I FORWARD -j LOG
|
|
root@bridge:~> iptables -I FORWARD -j DROP
|
|
root@bridge:~> iptables -A FORWARD -j DROP
|
|
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
|
|
</verb>
|
|
</tscreen>
|
|
The last line gives us the following output:
|
|
<tscreen>
|
|
<verb>
|
|
Chain FORWARD (policy DROP 0 packets, 0 bytes)
|
|
num pkts bytes target prot opt in out source destination
|
|
1 0 0 DROP all -- any any anywhere anywhere
|
|
2 0 0 LOG all -- any any anywhere anywhere LOG level warning
|
|
3 0 0 ACCEPT all -- any any anywhere anywhere
|
|
4 0 0 DROP all -- any any anywhere anywhere
|
|
</verb>
|
|
</tscreen>
|
|
The <tt/LOG/ target logs every packet via <tt/syslogd/. Beware, this is intended for
|
|
testing purposes only, remove in production environment. Else you end up either with
|
|
filled logs and harddisk partitions by you yourself or anyone else does this Denial
|
|
of Service to you. You've been warned.
|
|
<newline>
|
|
Test this ruleset now. Ping the router interface's IP (195.137.15.7) on host <tt/box/:
|
|
<tscreen>
|
|
<verb>
|
|
root@box:~> ping -c 3 195.137.15.7
|
|
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
|
|
--- router.provider.net ping statistics ---
|
|
3 packets transmitted, 0 received, 100% loss, time 2020ms
|
|
^C
|
|
root@box:~>
|
|
</verb>
|
|
</tscreen>
|
|
By default, we <tt/DROP/ everything. No response, no logged packet. This netfilter
|
|
setup is designed to <tt/DROP/ all packets unless we delete the rule that drops every
|
|
packet (rule no. 1 above) before the <tt/LOG/ target matches:
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> iptables -D FORWARD 1
|
|
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
|
|
</verb>
|
|
</tscreen>
|
|
Now, the rules are:
|
|
<tscreen>
|
|
<verb>
|
|
Chain FORWARD (policy DROP 0 packets, 0 bytes)
|
|
num pkts bytes target prot opt in out source destination
|
|
2 0 0 LOG all -- any any anywhere anywhere LOG level warning
|
|
3 0 0 ACCEPT all -- any any anywhere anywhere
|
|
4 0 0 DROP all -- any any anywhere anywhere
|
|
</verb>
|
|
</tscreen>
|
|
And any packet may pass through. Test it with a ping on host <tt/box/:
|
|
<tscreen>
|
|
<verb>
|
|
root@box:~> ping -c 3 195.137.15.7
|
|
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
|
|
64 bytes from router.provider.net (195.137.15.7): icmp_seq=1 ttl=255 time=0.103 ms
|
|
64 bytes from router.provider.net (195.137.15.7): icmp_seq=2 ttl=255 time=0.082 ms
|
|
64 bytes from router.provider.net (195.137.15.7): icmp_seq=3 ttl=255 time=0.083 ms
|
|
|
|
--- router.provider.net ping statistics ---
|
|
3 packets transmitted, 3 received, 0% loss, time 2002ms
|
|
rtt min/avg/max/mdev = 0.082/0.089/0.103/0.012 ms
|
|
root@box:~>
|
|
</verb>
|
|
</tscreen>
|
|
Yippeah! The router is alive, up and running. (Well it has been all day long.. ;-)
|
|
|
|
<descrip>
|
|
<tag/Important Note:/ <label id="TESTING_Important_note">
|
|
When we just fired up the bridge interface it takes about roughly 30 seconds
|
|
until the bridge is fully operational. This is due the 30-seconds-learning phase
|
|
of the bridge interface. During this phase, the bridge ports are learning what
|
|
MAC addresses exist on what port. The bridge author, Lennert, tells us in his
|
|
TODO file, the 30-seconds-learning phase is subjected to some improvement in a
|
|
timely manner some time.
|
|
<newline>
|
|
During the test phase, no packet will we forwarded. No ping be answered.
|
|
Remind this!
|
|
</descrip>
|
|
|
|
<sect1>Actual configuration
|
|
<p>
|
|
<label id="TESTING_actual_configuration">
|
|
This section is intended to give you, dear reader, some hints about
|
|
how your system should look and feel after having processed this
|
|
howto successfully.
|
|
|
|
<sect2>Interface configuration
|
|
<p>
|
|
The output of your <tt/ifconfig/ command might look similar to
|
|
this:
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> ifconfig
|
|
br0 Link encap:Ethernet HWaddr 00:04:75:81:D2:1D
|
|
inet addr:10.0.3.129 Bcast:195.30.198.255 Mask:255.255.255.128
|
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|
RX packets:826 errors:0 dropped:0 overruns:0 frame:0
|
|
TX packets:737 errors:0 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:0
|
|
RX bytes:161180 (157.4 Kb) TX bytes:66708 (65.1 Kb)
|
|
|
|
eth0 Link encap:Ethernet HWaddr 00:04:75:81:ED:B7
|
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|
RX packets:5729 errors:0 dropped:0 overruns:0 frame:0
|
|
TX packets:3115 errors:0 dropped:0 overruns:0 carrier:656
|
|
collisions:0 txqueuelen:100
|
|
RX bytes:1922290 (1.8 Mb) TX bytes:298837 (291.8 Kb)
|
|
Interrupt:11 Base address:0xe400
|
|
|
|
eth1 Link encap:Ethernet HWaddr 00:04:75:81:D2:1D
|
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|
RX packets:0 errors:0 dropped:0 overruns:1 frame:0
|
|
TX packets:243 errors:0 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:100
|
|
RX bytes:342 (342.0 b) TX bytes:48379 (47.2 Kb)
|
|
Interrupt:7 Base address:0xe800
|
|
|
|
lo Link encap:Local Loopback
|
|
inet addr:127.0.0.1 Mask:255.0.0.0
|
|
UP LOOPBACK RUNNING MTU:16436 Metric:1
|
|
RX packets:1034 errors:0 dropped:0 overruns:0 frame:0
|
|
TX packets:1034 errors:0 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:0
|
|
RX bytes:82068 (80.1 Kb) TX bytes:82068 (80.1 Kb)
|
|
</verb>
|
|
</tscreen>
|
|
|
|
<sect2>Routing configuration
|
|
<p>
|
|
The output of your <tt/route/ command might look similar to
|
|
this:
|
|
<tscreen>
|
|
<verb>
|
|
root@bridge:~> route -n
|
|
Kernel IP routing table
|
|
Destination Gateway Genmask Flags Metric Ref Use Iface
|
|
10.0.3.129 0.0.0.0 255.255.255.128 U 0 0 0 br0
|
|
0.0.0.0 10.0.3.129 0.0.0.0 UG 0 0 0 br0
|
|
root@bridge:~>
|
|
</verb>
|
|
</tscreen>
|
|
|
|
<sect2>Iptables configuration
|
|
<p>
|
|
Please have a look at the
|
|
<ref id="TESTING_iptables_listing" name="Ping it, Jim!"> section.
|
|
|
|
<sect1>Final note (Important!) <label id="final-note">
|
|
<p>
|
|
I'd like to hear from you! :-)
|
|
<newline>
|
|
Did you enjoy the trip?
|
|
<newline>
|
|
Do you miss anything?
|
|
<newline>
|
|
Need help? (Call you local assistant ;-) or rtfm.
|
|
<newline>
|
|
You are still online? Then drop me a msg via email. I'd be really glad.
|
|
<newline>
|
|
Wanna send me a cheque? Pitty, Don't accept these.. (Just kidding;)
|
|
<newline>
|
|
Make it worth my time, just send me some nice words, that's enough.
|
|
<newline>
|
|
Nothing motivates more than happy participants giving you valuable feedback.
|
|
<newline>
|
|
So, go on, invest a minute and hack me a mail!
|
|
<newline>
|
|
Thank you!
|
|
<p>
|
|
<tscreen>
|
|
<verb>
|
|
Nils
|
|
</verb>
|
|
</tscreen>
|
|
|
|
|
|
<sect1>Bug-Notes
|
|
<p>
|
|
<label id="HINT_False_positive">
|
|
Apparently, there must have been a bug in the br-nf code:
|
|
<tscreen>
|
|
<verb>
|
|
From: Bart De Schuymer <bart.de.schuymer_@_pandora.be>
|
|
Date: Sun, 1 Sep 2002 21:52:46 +0200
|
|
To: Nils Radtke <Nils.Radtke_@_Think-Future.de>
|
|
Subject: Re: Ethernet-Brigde-netfilter-HOWTO
|
|
|
|
Hello Nils,
|
|
|
|
[...]
|
|
Also, network packet filtering debugging is generally a bad idea with the
|
|
br-nf patch. It can gives a lot of false warnings (about bugs) in the logs.
|
|
[...]
|
|
</verb>
|
|
</tscreen>
|
|
|
|
Personally, I never had false positives in my log. Maybe, that bug has been
|
|
fixed. This mailed to Bart, he wrote:
|
|
<tscreen>
|
|
<verb>
|
|
From: Bart De Schuymer <bart.de.schuymer_@_pandora.be>
|
|
Date: Mon, 2 Sep 2002 18:30:25 +0200
|
|
To: Nils Radtke <Nils.Radtke_@_Think-Future.de>
|
|
Subject: Re: Ethernet-Brigde-netfilter-HOWTO
|
|
|
|
On Monday 02 September 2002 00:39, Nils Radtke wrote:
|
|
> Will the revision of the nf-debug code in br-nf be subject of improvement?
|
|
|
|
I must admit I haven't been running any kernel with netfilter debugging
|
|
lately. It sure used to give false positives a few months ago (the bridge
|
|
mailing list has posts about that), I've been lacking time to see why and if
|
|
it is still the case. It's on my todo list.
|
|
[...]
|
|
</verb>
|
|
</tscreen>
|
|
But (as of writing this 2002-09-19) I haven't found an official announcement,
|
|
this particular bug has been closed. So have a constant look at this topic on
|
|
the
|
|
<ref id="LINK_Mailinglist" name="ethernet bridge mailinglist">
|
|
, if you are interested in it's cure.
|
|
|
|
|
|
<!-- ### Testing ### -->
|
|
<!-- ############### -->
|
|
|
|
<!-- ######################## -->
|
|
<!-- ### user experiences ### -->
|
|
<sect>User experiences <label id="user-exp">
|
|
<p>
|
|
<sect1>Fedora Core 3
|
|
<p>
|
|
James Dinkel (jdinkel_ @ _gmail.com) wrote on Tue, 8 Mar 2005 10:59:22 -0600:
|
|
<tscreen>
|
|
<verb>
|
|
[...]
|
|
I am using Fedora Core 3 and all I had to do was "yum install bridge-utils"
|
|
to use the brctl command. I didn't have to do any kernel recompiling or
|
|
configurations or messing with kernel modules.
|
|
It was very easy.
|
|
[...]
|
|
</verb>
|
|
</tscreen>
|
|
|
|
<!-- ### user experiences ### -->
|
|
<!-- ######################## -->
|
|
|
|
|
|
<!-- ############# -->
|
|
<!-- ### links ### -->
|
|
<sect>Links
|
|
<p>
|
|
The Howto's author may be contacted via <url url="mailto:Ethernet-Bridge-netfilter-Howto_@_Think-Future.de" name="e-mail">.
|
|
<newline>
|
|
<url url="http://Think-Future.de/" name="Howto Author's homepage">.
|
|
|
|
<sect1>Ethernet-Bridge
|
|
<p>
|
|
<itemize>
|
|
<item>
|
|
<label id="LINK_Mailinglist">
|
|
<tt><url url="http://www.math.leidenuniv.nl/pipermail/bridge/" name="Ethernet Bridge Mailinglist"></tt>
|
|
</item>
|
|
|
|
<item>
|
|
<label id="LINK_Bridge-home">
|
|
User space utilities, patches, etc.:
|
|
<tt><url url="http://bridge.sourceforge.net" name="Home of Linux kernel Ethernet Bridge"></tt>
|
|
</item>
|
|
|
|
<item>
|
|
<label id="LINK_Bridge-stp-howto">
|
|
<tt><url url="http://www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/index.html" name="Bridge-STP-HOWTO"></tt>
|
|
</item>
|
|
|
|
<item>
|
|
<label id="LINK_Enterprise_fw">
|
|
<tt><url url="./additional_docs/Firewalling_for_Free.pdf" name="Firewalling for Free, Shawn Grimes"></tt>
|
|
</item>
|
|
|
|
</itemize>
|
|
|
|
|
|
<sect1>Related Topics
|
|
<p>
|
|
<itemize>
|
|
<item>
|
|
Filtering on frame level, Ethernet-Bridging-Tables:
|
|
<newline>
|
|
<tt><url url="http://sourceforge.net/projects/ebtables" name="ebtables, sourceforge"></tt>
|
|
<newline>
|
|
<tt><url url="http://users.pandora.be/bart.de.schuymer/ebtables/properties.html" name="ebtables, supported features"></tt>
|
|
<newline>
|
|
<tt>ebtables, examples: <url url="http://users.pandora.be/bart.de.schuymer/ebtables/examples.html" name="basic">, <url url="http://users.pandora.be/bart.de.schuymer/ebtables/battlefield_examples.html" name="advanced"></tt>
|
|
</item>
|
|
|
|
<item>
|
|
IP mode, Linux Bridge extension:
|
|
<tt><url url="http://www.ssi.bg/~ja/" name="IP mode, LVS"></tt>
|
|
</item>
|
|
|
|
<item>
|
|
Linux in High-Availability environments:
|
|
<tt><url url="http://www.linux-ha.org/" name="High-Availability Linux"></tt>
|
|
</item>
|
|
|
|
<item>
|
|
Linux Virtual Server:
|
|
<tt><url url="http://www.linuxvirtualserver.org/" name="LVS"></tt>
|
|
</item>
|
|
|
|
</itemize>
|
|
|
|
<!-- ### links ### -->
|
|
<!-- ############# -->
|
|
|
|
|
|
<!-- ### inf.misc_make ### -->
|
|
<!-- ###################### -->
|
|
|
|
</article>
|
|
<!-- EOF -->
|
|
<!-- vim:tw=256:et:sts=2:st=2:sw=2:com+=b\:###:fo+=cqtr:tags=ctags:
|
|
-->
|