345 lines
13 KiB
HTML
345 lines
13 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE>Ethernet Bridge + netfilter Howto: Test your new bridged environment! </TITLE>
|
|
<LINK HREF="Ethernet-Bridge-netfilter-HOWTO-5.html" REL=next>
|
|
<LINK HREF="Ethernet-Bridge-netfilter-HOWTO-3.html" REL=previous>
|
|
<LINK HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Ethernet-Bridge-netfilter-HOWTO-5.html">Next</A>
|
|
<A HREF="Ethernet-Bridge-netfilter-HOWTO-3.html">Previous</A>
|
|
<A HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="TESTING_Testing_grounds"></A> <A NAME="s4">4.</A> <A HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4">Test your new bridged environment! </A></H2>
|
|
|
|
|
|
|
|
|
|
|
|
<H2><A NAME="ss4.1">4.1</A> <A HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4.1">Testing Grounds</A>
|
|
</H2>
|
|
|
|
<P>We imagine this scenario or similar:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
/\
|
|
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
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Our administrative power includes only machines marked with <CODE>own</CODE>, the Router is
|
|
completely off-limits and so is the Internet, of course.<BR>
|
|
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. <BR>
|
|
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..<BR>
|
|
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. <BR>
|
|
So it's up to you to chose your preferred method. But we will handle just the fancy one here ;-)</P>
|
|
|
|
|
|
<H2><A NAME="ss4.2">4.2</A> <A HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4.2">Ping it, Jim!</A>
|
|
</H2>
|
|
|
|
<P>We will configure the Box' eth0 as usual. The bridge's interfaces
|
|
are configured as described in
|
|
<A HREF="Ethernet-Bridge-netfilter-HOWTO-3.html#SETUP_Linux_brctl">Setup</A>.<BR>
|
|
<A NAME="TESTING_routing"></A>
|
|
If we are to use forwarding we might perhaps do this one: ;-)
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Optionally, we set up a default route:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root@bridge:~> route add default gw 10.0.3.129
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Then we set up some iptables rules on host <CODE>bridge</CODE>:
|
|
<A NAME="TESTING_iptables_listing"></A>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
The last line gives us the following output:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
The <CODE>LOG</CODE> target logs every packet via <CODE>syslogd</CODE>. 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.<BR>
|
|
Test this ruleset now. Ping the router interface's IP (195.137.15.7) on host <CODE>box</CODE>:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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:~>
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
By default, we <CODE>DROP</CODE> everything. No response, no logged packet. This netfilter
|
|
setup is designed to <CODE>DROP</CODE> all packets unless we delete the rule that drops every
|
|
packet (rule no. 1 above) before the <CODE>LOG</CODE> target matches:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root@bridge:~> iptables -D FORWARD 1
|
|
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Now, the rules are:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
And any packet may pass through. Test it with a ping on host <CODE>box</CODE>:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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:~>
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Yippeah! The router is alive, up and running. (Well it has been all day long.. ;-)</P>
|
|
<P>
|
|
<DL>
|
|
<DT><B>Important Note:</B><DD><P>
|
|
<A NAME="TESTING_Important_note"></A>
|
|
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.<BR>
|
|
During the test phase, no packet will we forwarded. No ping be answered.
|
|
Remind this!</P>
|
|
</DL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss4.3">4.3</A> <A HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4.3">Actual configuration</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<A NAME="TESTING_actual_configuration"></A>
|
|
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.</P>
|
|
|
|
<H3>Interface configuration</H3>
|
|
|
|
<P>The output of your <CODE>ifconfig</CODE> command might look similar to
|
|
this:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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)
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H3>Routing configuration</H3>
|
|
|
|
<P>The output of your <CODE>route</CODE> command might look similar to
|
|
this:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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:~>
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H3>Iptables configuration</H3>
|
|
|
|
<P>Please have a look at the
|
|
<A HREF="#TESTING_iptables_listing">Ping it, Jim!</A> section.</P>
|
|
|
|
<H2><A NAME="final-note"></A> <A NAME="ss4.4">4.4</A> <A HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4.4">Final note (Important!) </A>
|
|
</H2>
|
|
|
|
<P>I'd like to hear from you! :-)<BR>
|
|
Did you enjoy the trip? <BR>
|
|
Do you miss anything? <BR>
|
|
Need help? (Call you local assistant ;-) or rtfm.<BR>
|
|
You are still online? Then drop me a msg via email. I'd be really glad.<BR>
|
|
Wanna send me a cheque? Pitty, Don't accept these.. (Just kidding;)<BR>
|
|
Make it worth my time, just send me some nice words, that's enough.<BR>
|
|
Nothing motivates more than happy participants giving you valuable feedback.<BR>
|
|
So, go on, invest a minute and hack me a mail!<BR>
|
|
Thank you!</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Nils
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="ss4.5">4.5</A> <A HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4.5">Bug-Notes</A>
|
|
</H2>
|
|
|
|
<P>
|
|
<A NAME="HINT_False_positive"></A>
|
|
Apparently, there must have been a bug in the br-nf code:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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.
|
|
[...]
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Personally, I never had false positives in my log. Maybe, that bug has been
|
|
fixed. This mailed to Bart, he wrote:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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.
|
|
[...]
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
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
|
|
<A HREF="Ethernet-Bridge-netfilter-HOWTO-6.html#LINK_Mailinglist">ethernet bridge mailinglist</A>
|
|
, if you are interested in it's cure.</P>
|
|
|
|
|
|
|
|
<HR>
|
|
<A HREF="Ethernet-Bridge-netfilter-HOWTO-5.html">Next</A>
|
|
<A HREF="Ethernet-Bridge-netfilter-HOWTO-3.html">Previous</A>
|
|
<A HREF="Ethernet-Bridge-netfilter-HOWTO.html#toc4">Contents</A>
|
|
</BODY>
|
|
</HTML>
|