温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
教会孩们快乐
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
IP addresses to MAC addresses (anti-spoofing rules):
ebtables -A FORWARD -p IPv4 --ip-src 172.16.1.4 -s ! 00:11:22:33:44:55 -j DROP
is an anti-spoofing filter rule. It says that the computer using IP
address 172.16.1.4 has to be the one that uses ethernet card
00:11:22:33:44:55 to send this traffic.Note: this can also be
done using iptables. In iptables it would look like this:
iptables -A FORWARD -s 172.16.1.4 -m mac --mac-source ! 00:11:22:33:44:55 -j DROP
difference is that the frame will be dropped earlier if the
ebtables rule is used, because ebtables inspects the frame before
iptables does. Also note the subtle difference in what is
considered the default type for a source address: an IP address in
iptables, a MAC address in ebtables.
you have many such rules, you can also use the de&amongde&
match to speed up the filtering.
ebtables -N MATCHING-MAC-IP-PAIR ebtables -A FORWARD -p IPv4 --among-dst 00:11:22:33:44:55=172.16.1.4,00:11:33:44:22:55=172.16.1.5 \ -j MATCHING-MAC-IP-PAIR
first make a new user-defined chain de&MATCHING-MAC-IP-PAIRde&
and we send all traffic with matching MAC-IP source address pair to
that chain, using the de&amongde& match. The filtering in
the de&MATCHING-MAC-IP-PAIRde& chain can then assume that
the MAC-IP source address pairs are correct.
section for an application.
ebtables -t nat -A PREROUTING -d 00:11:22:33:44:55 -i eth0 -j dnat --to-destination 54:44:33:22:11:00
will make all frames destined to 00:11:22:33:44:55 that arrived on
interface eth0 be transferred to 54:44:33:22:11:00 instead. As this
change of destination MAC address is done in the de&PREROUTINGde&
chain of the de&natde& table, it is done before the bridge
code makes the forwarding decision. The hosts with addresses
00:11:22:33:44:55 and 54:44:33:22:11:00 therefore don't need to be
on the same side of the bridge. If the host with MAC address
54:44:33:22:11:00 is on the same side of the bridge as where the
packet arrived, this packet won't be sent out again. You can
therefore only use this if the host with the destination MAC
address 54:44:33:22:11:00 is on another side of the bridge than the
sender of the packet. Note that this MAC NAT does not care about
protocols of higher layers. F.e. when the network layer is IP, the
host with MAC ADDRESS 54:44:33:22:11:00 will see that the
destination IP address is not the same as its own IP address and
will probably discard the packet (unless it's a router).If you
want to use IP NAT, use iptables.
forward IPv4 for a specific MAC address:
situation was described by someone:"For a wierd setup
(kind of half a half bridge :-)) I would need a genericMAC-source
based filter. I need to prevent ARPs and other Layer2 basedpackets
(DEC diag. packets, netbios, etc.) from a specific MAC-source
tocross the bridge, to prevent loops."This is
easily solved with ebtables:
ebtables -A FORWARD -s 00:11:22:33:44:55 -p IPV4 -j ACCEPT ebtables -A FORWARD -s 00:11:22:33:44:55 -j DROP
a brouter:
is an example setup for a brouter with the following situation: br0
with ports eth0 and eth1.
ifconfig br0 0.0.0.0 ifconfig eth0 172.16.1.1 netmask 255.255.255.0 ifconfig eth1 172.16.2.1 netmask 255.255.255.0 ebtables -t broute -A BROUTING -p ipv4 -i eth0 --ip-dst 172.16.1.1 -j DROPebtables -t broute -A BROUTING -p ipv4 -i eth1 --ip-dst 172.16.2.1 -j DROP ebtables -t broute -A BROUTING -p arp -i eth0 -d $MAC_OF_ETH0 -j DROP ebtables -t broute -A BROUTING -p arp -i eth1 -d $MAC_OF_ETH1 -j DROP ebtables -t broute -A BROUTING -p arp -i eth0 --arp-ip-dst 172.16.1.1 -j DROP ebtables -t broute -A BROUTING -p arp -i eth1 --arp-ip-dst 172.16.2.1 -j DROP
mentioned in the man pages, the de&DROPde& target in the
de&BROUTINGde& chain actually broutes the frame. This means
the bridge code won't touch the frame and it is sent up to the
higher network layers. This results in the frame entering the box
as if it didn't arrive on a bridge port but on the device
itself.The first two ebtables commands are easy to explain:
they make sure the IP packets that must be routed enter the IP
routing code through the eth0 (resp. eth1) device, not throught the
br0 device. If you want the box to also route traffic with a MAC
destination address different from the router's, you need to use
the de&redirectde& target, which changes the MAC destination
address to the bridge's MAC address (see the subsequent
example).The last four commands are needed to get ARP working.
When the brouter sends an ARP request for, let's say 172.16.1.5,
this request is sent through the eth0 or eth1 device (we assume
there is no route using output device br0). Without the third
ebtables rule, the ARP reply would arrive on the br0 device instead
of the eth{0,1} device, as far as the ARP code can tell. This reply
is then discarded by the ARP code. Using the third rule, the reply
arrives on the eth0 device and the ARP code is happy. So the third
and fourth rules are needed to make the ARP code use the ARP
replies. Without the third rule, the brouter will not send IP
packets to 172.16.1.5 (unless it already knew the MAC address of
172.16.1.5 and therefore didn't send an ARP request in the first
place). The last two commands are needed so that the ARP requests
for 172.16.1.1 and 172.16.2.1 are answered. You can use more
restrictive matching on the ARP packets (e.g. only match on arp
requests in the last two rules).
redirect target:
is a simple example that will make all IP traffic entering a
(forwarding) bridge port be routed instead of bridged (suppose eth0
is a port of the bridge br0):
ebtables -t broute -A BROUTING -i eth0 -p ipv4 -j redirect --redirect-target DROP
mentioned in the man pages, the de&DROPde& target in the
de&BROUTINGde& chain actually broutes the frame. The
de&redirectde& target will trick the network code to think
the packet was originally destined for the box.
the following rule has a similar effect:
ebtables -t nat -A PREROUTING --logical-in br0 -p ipv4 -j redirect --redirect-target ACCEPT
difference is that in the second case the IP code and routing code
will think the IP packet entered through the br0 device. In the
first case the IP code and routing code will think the IP packet
entered through the eth0 device. It depends on the situation in
which chain to use the redirect target. F.e., if your routing table
only uses br0, then the redirect belongs in the PREROUTING chain.
Atomically
load or update a table:
do we want to be able to atomically load or update a table? Because
then the table data is given to the kernel in one step. This is
sometimes desirable to prevent race conditions when adding multiple
rules at once. The most obvious use case, however, is when the
tables are initially populated with rules. Committing the table to
the kernel at once saves a lot of context switching and kernel
time, resulting in much faster configuration. Here is a brief
description how to do this. The examples will use the de&natde&
table, of course this works for any table.The simplest
situation is when the kernel table already contains the right data.
We can then do the following:First we put the kernel's table
into the file de&nat_tablede&:
ebtables --atomic-file nat_table -t nat --atomic-save
we (optionally) zero the counters of the rules in the file:
ebtables -t nat --atomic-file nat_table -Z
bootup we use the following command to get everything into the
kernel table at once:
ebtables --atomic-file nat_table -t nat --atomic-commit
can also build up the complete table in the file. We can use the
environment variable de&EBTABLES_ATOMIC_FILEde&. First we
set the environment variable:
export EBTABLES_ATOMIC_FILE=nat_table
we initialize the file with the default table, which has empty
chains and policy de&ACCEPTde&:
ebtables -t nat --atomic-init
then add our rules, user defined chains, change policies:
ebtables -t nat -A PREROUTING -j DROP
can check the contents of our table with:
ebtables -t nat -L --Lc --Ln
then use the following command to get everything into the kernel
table at once:
ebtables -t nat --atomic-commit
forget to unset the environment variable:
unset EBTABLES_ATOMIC_FILE
all ebtables commands will execute onto the actual kernel table
again, instead of on the file de&nat_tablede&.
with ebtables on interfaces not enslaved to a bridge:
you really need filtering on an interface and can't use a standard
way of doing it (i.e. there is no standard filtering tool for the
protocol), there is a solution if you only need basic filtering.We
consider here the case where basic Appletalk filtering is needed.
As there is no Appletalk filter mechanism for Linux, we need
something else. The example below is for a computer that also uses
the IP protocol. Obviously, if you only need to filter the IP
stuff, just use iptables. The IP protocol is included in this,
because it gives an idea of what configuring could be needed for
the other protocol (e.g. Appletalk). If the computer does indeed
use the IP protocol too, then the following IP stuff will need to
be done.Suppose your current setup consists of device eth0 with
IP address 172.16.1.10.The first three commands make sure
ebtables will see all traffic entering on eth0, which will be a
bridge port of br0. The other commands are purely IP related.First
make a bridge device:
brctl addbr br0
(perhaps) disable the spanning tree protocol on that bridge:
brctl stp br0 off
add the physical device eth0 to the logical bridge device:
brctl addif br0 eth0
the IP address of eth0 to the bridge device and remove it from
ifconfig br0 172.16.1.10 netmask 255.255.255.0 ifconfig eth0 0.0.0.0
routing table must be corrected too, f.e.:
route del -net 172.16.1.0 netmask 255.255.255.0 dev eth0 route add -net 172.16.1.0 netmask 255.255.255.0 dev br0 route del default gateway $DEFAULT_GW dev eth0 route add default gateway $DEFAULT_GW dev br0
now all IP traffic that originally went through eth0 will go
through br0. Note that this is kind of a hack: using a bridge with
only one enslaved device. However, now ebtables will see all the
traffic that passes eth0, because eth0 is now a port of the bridge
device br0.The other protocol used (f.e. Appletalk) will have
to be configured to accept traffic from br0 (instead of eth0) and
to transmit traffic to br0 (instead of eth0).Alternatively,
this can be used in conjunction with the brouter functionality. A
for filtering Appletalk, which can be found in the
section, uses this approach. For performance reasons,
it's actually better to use the brouter approach, see the next
example to find out why.
up traffic destinated to the bridge itself:
some situations the bridge not only serves as a bridge box, but
also talks to other hosts. Packets that arrive on a bridge port and
that are destinated to the bridge box itself will by default enter
the iptables de&INPUTde& chain with the logical bridge port
as input device. These packets will be queued twice by the network
code, the first time they are queued after they are received by the
network device. The second time after the bridge code examined the
destination MAC address and determined it was a locally destinated
packet and therefore decided to pass the frame up to the higher
protocol stack.
way to let locally destinated packets be queued only once is by
brouting them in the de&BROUTINGde& chain of the de&broutede&
table. Suppose br0 has an IP address and that br0's bridge ports do
not have an IP address. Using the following rule should make all
locally directed traffic be queued only once:
ebtables -t broute -A BROUTING -d $MAC_OF_BR0 -p ipv4 -j redirect --redirect-target DROP
replies from the bridge will be sent out through the br0 device
(assuming your routing table is correct and sends all traffic
through br0), so everything keeps working neatly, without the
performance loss caused by the packet being queued twice.
redirect target is needed because the MAC address of the bridge
port is not necessarily equal to the MAC address of the bridge
device. The packets destinated to the bridge box will have a
destination MAC address equal to that of the bridge br0, so that
destination address must be changed to that of the bridge port.
the de&markde& match and target:
there are 3 types of traffic you want to mark. The best mark values
are powers of 2, because these translate to setting one bit in the
de&unsigned longde& mark value. So, as we have three types
of traffic, we will use the mark values 1, 2 and 4.How do we
mark traffic? Simple, filter out the exact traffic you need and
then use the mark target. Example:Mark, in the filter table's
FORWARD chain, all IP traffic that entered through eth0 with the and let later rules have the chance of seeing
the frame/packet.
ebtables -A FORWARD -p ipv4 -i eth0 -j mark --set-mark 2 --mark-target CONTINUE
we want to do something to all frames that are marked with the
first mark value:
ebtables -A FORWARD --mark 1/1
we want to do something to all frames that are marked with either
the first, either the third mark value:
ebtables -A FORWARD --mark /5
+ 4 = 5. We only specified the de&markde& mask, which
results in taking the logical and of the mark value of the frame
with the specified mark mask and checking if the result is
non-zero. So, if the result is non-zero, which means that the mark
value is either 1, either 4, either 5, the rule matches.
that iptables uses the same de&unsigned longde& value for
its de&markde& match and de&MARKde& target. So this
enables communication between ebtables and iptables. Be sure the
mark values used in iptables and those used in ebtables don't
conflict with each other.
de&arpreplyde& for arp requests and letting the arp request
populate the arp cache:
de&arpreplyde& target can only be used in the de&PREROUTINGde&
chain of the de&natde& table and its default target is de&DROPde&.
A rule like below will therefore prevent an update of the arp cache
of the bridge box:
ebtables -t nat -A PREROUTING -p arp --arp-opcode Request -j arpreply \ --arpreply-mac 10:11:12:13:14:15
can be fixed by changing the target to de&ACCEPTde& or
de&CONTINUEde&:
ebtables -t nat -A PREROUTING -p arp --arp-opcode Request -j arpreply \ --arpreply-mac 10:11:12:13:14:15 --arpreply-target ACCEPT
the destination IP and MAC address to the respective broadcast
addresses:
is not possible in a standard way, but it is possible with some
tricks. Suppose you want to direct traffic to 192.168.0.255, then
this should work:
# suppose there is no route to 192.168.0.0 yet route add -net 192.168.0.0 netmask 255.255.255.0 dev br0 ifconfig br0 0.0.0.0 arp -s 192.168.0.255 ff:ff:ff:ff:ff:ff iptables -t nat -A PREROUTING -j DNAT --to-destination 192.168.0.255
bridge device should not have an address in the range of
192.168.0.0/24, because if it does, the routing code won't decide
to send the packet out through the bridge device.
packets to userspace for logging:
de&ulogde& watcher passes the packet to a userspace logging
daemon using netlink multicast sockets. This differs from the log
watcher in the sense that the complete packet is sent to userspace
instead of a descriptive text and that netlink multicast sockets
are used instead of the syslog. This watcher enables parsing of
packets with userspace programs. Sending this information to
userspace is simple, just use the de&ulogde& watcher. The
physical bridge input and output ports are also included in the
netlink messages.
example, the following rule will send all to be forwarded packets
to userspace programs listening on netlink group number 5 before
dropping the packets:
ebtables -A FORWARD --ulog-nlgroup 5 -j DROP
read the packets sent to userspace, a program needs to be written.
Under de&examples/ulog/de& in the ebtables directory you can
find a working example in C that looks for ICMP echo requests and
replies. See de&INSTALLde& for compilation.
J. A. M. Carneiro &gjc_at_inescporto.pt& has written some
Python code to be able to look at the data using Python code. These
are the files he released:
support for running the ebtables tool concurrently:
the ebtables kernel tables is a two-phase process. First, the
userspace program sends the new table to the kernel and receives
the packet counters for the rules in the old table. In a second
phase, the userspace program uses these counter values to determine
the initial counter values of the new table, which is already
active in the kernel. These values are sent to the kernel which
adds these values to the kernel's counter values. Due to this
two-phase process, it is possible to confuse the ebtables userspace
tool when more than one instance is run concurrently. Note that
even in a one-phase process it would be possible to confuse the
ebtables tool supports an option named de&--concurrentde&,
which makes the ebtables tool first acquire a lock on a specific
file before reading and updating the kernel tables. As long as you
make sure all ebtables processes run with this option enabled,
there is no problem in running ebtables processes concurrently. If
your firewall scripts can run concurrently, make sure to enable
this option.
alternative would be to use the tool de&flockde& in your
the ebtables process crashes unexpectedly while holding the file
lock, subsequent execution of the program will fail to acquire the
lock. In this case, you will need to explicitly delete the lock
file: de&/var/lib/ebtables/lockde&.
IP security holes with multiple networks:
the bridge is configured to allow iptables or ip6tables to filter
bridged traffic, care must be taken in order to prevent unforeseen
security holes. The iptables chains are traversed for all IP
packets on all bridges. If there is more than one bridge, you must
make sure that packets forwarded by different bridges don't
interfere in iptables rules. One simple way to avoid this, is by
using different IP subnets for each bridged network. This is not
always possible, of course. A similar concern arrises when you
allow iptables to filter bridged IP traffic encapsulated in a vlan
or pppoe header.
multi-bridge scenario is especially a potential problem for
connection tracking, since this doesn't consider the input and
output interfaces. The vlan/pppoe scenario is also a potential
problem for all other IP traffic, since iptables itself isn't aware
of the vlan id or pppoe session id.
is possible, however, to let iptables indirectly know these details
by using the mark target of ebtables. In the example below, we use
netfilter's connection tracking zone mechanism to separate
connection tracking between the bridged vlan traffic with vlan id 1
# set up the connection tracking zones iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone 1 iptables -t raw -A PREROUTING -m mark --mark 2 -j CT --zone 2 # mark packets according to the vlan id ebtables -t nat -A PREROUTING -p 802_1Q --vlan-id 1 -j mark --mark-set 1 ebtables -t nat -A PREROUTING -p 802_1Q --vlan-id 5 -j mark --mark-set 2
Real-life examples
These example setups were given by ebtables users, and they are very much appreciated. If you have a configuration involving ebtables which you would like to share, please write a little story about it and send it to the so that it can be added here.
Real-life examples Choose one of the examples below
You can also view all examples on .
brouting, MAC snat and MAC dnat all in one
setup and explanation was given by Enrico Ansaloni, who got
things working together with Alessandro Eusebi.
description
802.1Q VLANs, a HP 4000 M switch and a Linux bridge with iptables
and ebtables.The HP switch is used for VLAN switching. The Linux
bridge is used for bridging specific frames and for IP
routing.Obviously good filtering is required to prevent
duplicated traffic.
I use the Linux bridge: I have to bridge the 2 VLANs to let DEC LAT
traffic only go through, while IP traffic has to go under normal
routing decisions: this is done with ebtables.The bridge has 2
IP addresses, one for each VLAN so that routing will work, in
conjuction with iptables eventually to do some traffic shaping and
internal control (allowed tcp ports from inside to outside etc.)
try: assign the 2 IP addresses to the bridge device (br0)
problem with the HP switch is that it doesn't allow the same MAC
address in 2 different ports which is what happens when I connect
the bridge which has 2 cables - it connects into 2 ports - and has 1
MAC this occurs even if the ports belong to different
VLANs: to put it in another way, the HP VLAN implementation doesn't
fully isolate VLANs but checks for MAC address consistency in the
whole switch, regardless of VLAN settings... instead, the Cisco
Catalyst series does that right but it costs 3 times more and my
customer won't pay that much...
try: use ebtables MAC snat to give the two bridge IP addresses
different MAC source addresses
I decided I could try with MAC natting, and I set up ebtables like
ebtables -t nat -A POSTROUTING -o $INSIDE_IF_NAME -s $DMZ_IF_MAC
-j snat --to-source $INSIDE_IF_MAC ebtables -t nat -A PREROUTING -i $INSIDE_IF_NAME -d $INSIDE_IF_MAC
-j dnat --to-destination $DMZ_IF_MAC
you can see, I'm tying to fool the switch into thinking the bridge
has a different MAC address for each interface: the rule is correct,
as I can see by capturing traffic with ethereal, but there's a
problem: ebtables works at layer 2 only, thus correctly natting MAC
address in the layer 2 the switch now accepts the
natted packets but the ARP packets are at layer 3 and they keep the
original MAC address as from the linux kernel network stack, so the
client's reply is wrong and never goes through...
try: use brouting + MAC snat + MAC dnat
stated in the
section on the ebtables hp, I started with this:
***********************************************************&Bridge table: broute
Bridge chain:&BROUTE Policy: ACCEPT nr. of entries: 4 1. -p IPV4 -i eth0 -j DROP count = 47959 2. -p IPV4 -i eth1 -j DROP count = 47 3. -p ARP -i eth0 -j DROP count = 371 4. -p ARP -i eth1 -j DROP count = 141 ***********************************************************
this is not enough... With this rule, IP routing and ARP stuff is
perfectly working for both networks (VLANs) and I can control IP
stuff with iptables, but bridge isn't working yet... that's because
of the duplicate MAC in different VLANs problem of the HP switch:
when I use bridging, the same MAC address of the bridged client
appears on two ports, one for each VLAN, and the switch
automatically deactivates the first port! But I solved this issue
with ebtables MAC NAT, like this:
*********************************************************** Bridge table:&nat
Bridge chain:&PREROUTING Policy:&ACCEPT nr. of entries:&2 1. -d 10:50:da:e7:18:51 -i eth1 -j dnat --to-dst 0:50:da:e7:18:51 --dnat-target ACCEPT&count = 1260 2. -d 10:10:a4:9b:30:d -i eth0 -j dnat --to-dst 0:10:a4:9b:30:d --dnat-target ACCEPT&count = 1252
Bridge chain: OUTPUT Policy: ACCEPT nr. of entries:&0
Bridge chain: POSTROUTING Policy:&ACCEPT nr. of entries:&2 1. -s 0:50:da:e7:18:51 -o eth1 -j snat --to-src 10:50:da:e7:18:51 --snat-target ACCEPT&count = 1362 2. -s 0:10:a4:9b:30:d -o eth0 -j snat --to-src 10:10:a4:9b:30:d --snat-target ACCEPT&count = 1346&***********************************************************
MAC addresses you see are two network client, one for each VLAN.
When a client passes the bridge, I have to change his MAC (i change
the first 00: with 10:) in order to make the switch happy.I did
a small script also, so you can specify a list of MAC addresses for
each VLAN. Here's the script:
*********************************************************** #!/bin/bash ############################################################### # EBTables test script ############################################################### # Binaries
EBTABLES=/usr/local/sbin/ebtables ############################################################### # Interface names
INSIDE_IF_NAME=eth0 DMZ_IF_NAME=eth1 BRIDGE_IF_NAME=br0 ############################################################### # Bridge mac address list
INSIDE_IF_MAC="00:04:76:14:74:99" DMZ_IF_MAC="00:01:03:e2:e9:4c" ############################################################### # Client mac address list
LAN_CLIENT_MACS="00:50:DA:E7:18:51 00:50:DA:E7:F1:A0 00:10:A4:9B:E8:21" DMZ_CLIENT_MACS="00:10:A4:9B:30:0D 00:01:03:E2:12:9C 00:50:DA:E7:11:2B" NEW_PREFIX="10:" ############################################################### # Set default policy # $EBTABLES -P INPUT ACCEPT $EBTABLES -P OUTPUT ACCEPT $EBTABLES -P FORWARD ACCEPT # clear existing tables $EBTABLES -F $EBTABLES -t nat -F $EBTABLES -t broute -F
################################################################ # BRoute
$EBTABLES -t broute -A BROUTE -p ipv4 -i $INSIDE_IF_NAME -j DROP $EBTABLES -t broute -A BROUTE -p ipv4 -i $DMZ_IF_NAME -j DROP $EBTABLES -t broute -A BROUTE -p arp -i $INSIDE_IF_NAME -j DROP $EBTABLES -t broute -A BROUTE -p arp -i $DMZ_IF_NAME -j DROP
################################################################ # Bridged clients
for MAC in $LAN_CLIENT_MACS; do
NEW_MAC="${NEW_PREFIX}`echo ${MAC} | cut -f2- -d':'`"
$EBTABLES -t nat -A POSTROUTING -o $DMZ_IF_NAME -s $MAC -j snat --to-source $NEW_MAC
$EBTABLES -t nat -A PREROUTING -i $DMZ_IF_NAME -d $NEW_MAC -j dnat --to-destination $MAC done
for MAC in $DMZ_CLIENT_MACS; do
NEW_MAC="${NEW_PREFIX}`echo ${MAC} | cut -f2- -d':'`"
$EBTABLES -t nat -A POSTROUTING -o $INSIDE_IF_NAME -s $MAC -j snat --to-source $NEW_MAC
$EBTABLES -t nat -A PREROUTING -i $INSIDE_IF_NAME -d $NEW_MAC -j dnat --to-destination $MAC done
################################################################ # END ################################################################
hope this can be useful to you or someone else... If you're so
unlucky to have to deal with HP 4000 switches and their VLAN
implementation :)
AppleTalk using ebtables
setup and description was given by Ashok Aiyar. The
original website where he posted this setup is no longer available
but the website is archived .
The contents were edited to bring the original text, which dates
from the Linux 2.4 days, up-to-date.
filter AppleTalk?
are many situations where it is appropriate to filter AppleTalk.
Here's one of them. We tunnel/route AppleTalk between five networks
using . There
are very similarly named Tektronix Phaser printers in two of these
networks, and often print jobs intended for one are unintentionally
sent to the other. We would prefer for each of these Phasers to be
visible only in the network in which it is located, and not in all
five networks. Unlike ,
netatalk does not support filtering. Therefore, on this page I
describe one method to add external filters to netatalk, on the
basis of the MAC address associated with an AppleTalk object or
are pros and cons to filtering on the basis of MAC addresses. They
have the advantage of being more robust because AppleTalk node
numbers can change with every reboot, while the MAC address will
not. They have the disadvantage of not being fine- MAC-based
filtering will block all the services associated with the filtered
AppleTalk node. In general, AppleTalk nodes in our networks are
associated with a single service.
versus Ebtables
supports filtering of IPV4, IPV6 and DECnet packets on the basis of
MAC addresses. However such filters do not apply to any other type
of ethernet frame. So, an de&iptablesde& rule such as:
iptables -I INPUT -m mac --mac-source TE:KP:HA:SE:R8:60 -j DROP
in only IPV4, IPV6 and DECnet packets from that source address being
dropped. More to the point, DDP and AARP packets from the same
source address are not dropped.
appeared to be perfectly suited to filter Ethernet frames on the
basis of MAC address as well as ethernet protocol type. However, it
only supports bridge interfaces, and not regular Ethernet
interfaces. , the author of ebtables brought to my attention that a
Linux bridge interface can have just a single Ethernet interface.
Thanks to Bart's generous advice, a working Ethernet filtering setup
is described below.
up Ebtables
setup a bridge with a single interface, first create the bridge
interface (br0). Then add the relevant ethernet interface to the
bridge. Finally, assign to the bridge the IP address previously
assigned to the ethernet interface. The commands to do this are
detailed below:
brctl addbr br0
# create bridge interface brctl stp br0 off
# disable spanning tree protocol on br0 brctl addif br0 eth0
# add eth0 to br0 ifconfig br0 aaa.bbb.ccc.ddd netmask 255.255.255.0 broadcast aaa.bbb.ccc.255 ifconfig eth0 0.0.0.0 route add -net aaa.bbb.ccc.0 netmask 255.255.255.0 br0 route add default gw aaa.bbb.ccc.1 netmask 0.0.0.0 metric 1 br0
network traffic will be routed through the br0 interface rather than
the underlying eth0. de&Atalkdde& can be started to route
AppleTalk between br0 and any other desired interfaces. Note that
de&atalkd.confde& has to be modified so that the reference to
eth0 is replaced with br0. For example, the de&atalkd.confde&
for PC1 shown on my
is modified to:
-seed -phase 2 -net 2253
-zone "Microbio-Immun" tap0 -seed -phase 2 -net 60000 -addr
-zone "Microbio-Immun" tap1 -seed -phase 2 -net 60001 -addr
-zone "Microbio-Immun" tap2 -seed -phase 2 -net 60002 -addr
-zone "Microbio-Immun" tap3 -seed -phase 2 -net 60003 -addr
-zone "Microbio-Immun"
that AppleTalk routing is working, and then proceed to set up
Ethernet filters using de&ebtablesde&. For this the MAC
addresses of the AppleTalk nodes that are not to be routed must be
known. One simple method of discovering the MAC address is to send
the AppleTalk object a few de&aechode& packets, and then read
the MAC address from de&/proc/net/aarpde&. A sample de&ebtablesde&
filter is shown below:
ebtables -P INPUT ACCEPT ebtables -P FORWARD ACCEPT ebtables -P OUTPUT ACCEPT ebtables -A INPUT -p LENGTH -s TE:KP:HA:SE:R8:60 -j DROP
Currently,
de&ebtablesde& doesn't support filtering of 802.2 and 802.3
packets such as the DDP and AARP packets used by AppleTalk. However
all such packets can be dropped on the basis of the length field –
if I understand Bart de Schuymer's explanation correctly. Therefore
in the example above, all ethernet 802.2, 802.3 packets from the
node with the MAC address TE:KP:HA:SE:R8:60 are dropped. This
includes AppleTalk packets, but not IPV4, and ARP packets. This node
is left visible in the network in which it is located, but not in
any networks to which AppleTalk is routed.
Acknowledgements,
Final Comments and Useful Links:
de Schuymer's advice and patient explanations are greatly
appreciated. In my experience de&atalkdde& bound to the br0
interface is as stable as de&atalkdde& bound to the eth0
interface. In addition the MAC address based filters described here
work well for their intended purpose. While this works, there is a
performance penalty associated with receiving all IP traffic through
br0 and not eth0. This is because traffic destined for the bridge is
queued twice (once more than normal) – that's a lot of overhead.
The ebtables de&broutede& table can be used to circumvent
this and directly route the traffic entering the bridge port. This
way it will be queued only once, eliminating the performance
penalty. In the example above:
brctl addbr br0 brctl stp br0 off brctl addif br0 eth0 ifconfig br0 0.0.0.0 ifconfig eth0 a.b.c.d netmask 255.255.255.0 broadcast a.b.c.255
following two ebtables BROUTE table rules should be used:
ebtables -t broute -A BROUTING -p IPv4 -i eth0 --ip-dst a.b.c.d -j DROP ebtables -t broute -A BROUTING -p ARP -i eth0 -d MAC_of_eth0 -j DROP
should still be bound to br0, thus allowing AppleTalk to be filtered
by ebtables. As best as I can tell this configuration eliminates the
performance penalty on IP traffic throughput. Because we
through IP, this configuration removes any throughput
penalties in using a bridge interface and ebtables to route
AppleTalk.
Transparent
routing with Freeswan1
setup was given by Dominique Blas.
Bridge/router
configuration
br0 (192.168.100.254)
+-------------------------+
192.168.100.253 +------------+ -- eth0 ---+
+- eth1 ---------/---------+
+---& Internet
+------------+
+-----------+-------------+
(192.168.100.254)
Corporate network (192.168.0.0/19)
and eth1 without any address.
is built upon eth0 and eth1.
defaults to br0's address.
gateway is, of course, 192.168.100.253.
tunnel is established, route towards 192.168.0.0/19 is created by
freeswan using interface ipsec0. Classical.
configuration
Addressing
scheme : 192.168.100.0/24.
gateway is 192.168.100.253.
the challenge
Automatically
inject packets, for which the destination address is within the
corporate network addressing, to ipsec0.
the other packets going through eth1.
(Internet access through eth1) must respond,
ping 192.168.0.33 (intranet access going through ipsec0) must
can ask why being so complicated. It's enough to configure default
gateway (or a list a subnet in the routing table) on the stations to
point towards the br0 address and the router will do its job routing
toward intranet or towards Internet.Perfectly exact.
but imagine you have several dozens of such local stations without
DHCP to manage their network configurationand you are thousands
of miles away. You can simply send the machine, ask someone to plug
it in the router and in the hub with the correct cables you've
provided.That's all.
ebtables -t nat -A PREROUTING -i eth0 -p ipv4 --ip-dst 192.168.0.0/19 \ -j dnat --to-dst
$MAC_ADDR_OF_IPSEC0 --dnat-target ACCEPT
works and is enough for the challenge.
notice on de&$MAC_ADDR_Of_IPSEC0de&.Since the rule is set
before ipsec is launched the mac address of ipsec0 is not set at
this time. This doesn't matter since ipsec0's mac address will be
the same as that of the outbound interface that is equal to eth1's
mac address.
this rule:
ebtables -t nat -A PREROUTING -i eth0 -p ipv4 --ip-dst 192.168.0.0/19 \ -j dnat --to-dst $MAC_ADDR_OF_ETH1 --dnat-target
course that's only the first step. One can then take into account a
few other things:
protecting
eth1 at the ip level (via iptables) or at the mac level (anti
spoofing via ebtables or iptables),
protecting
intranet from devices attempting to access the tunnel from eth1,
sure such mac address is associated with such ip address without
using de&arp -sde&, using ebtables,
dns client bug on user's inexpensive routers
example was given by Mike Ireton.
just saved our cookies big time. Here's how it did it:
a wireless isp and our wireless subscribers all have inexpensive
soho routers with fixed ip addresses. We recently had to change out
the hardware at one of our main towers (software upgrades, faster
cpu, etc etc) and as a result of doing this, we discovered that
numerous subscribers all of a sudden could not resolve dns. Everyone
continued to have ping and tcp connectivity, but dns wasn't
resolving for them. Rebooting their routers would solve the problem,
but there's a lot of subscribers who depend on this site and we
coulnd't possibly call them all. After looking over packet dumps, it
appears that most of these cheap soho routers have a very subtle bug
which was responsable for the problem - their dns requests were
still bearing the old mac address of the router, while test pings to
them bore the new! (In effect, the embedded dns client in the router
was not re-arping for the gateway and instead using an outdated
cache). This is across several brands of routers too. So the
solution was to install ebtables mac address nat'ing so that
received frames destined for the old mac addresses would be changed
to the new address, thus solving the problem site wide.
Rate shaping This example was given by Dave Stahr (dave&at&).
Goal I'm running Fedora Core 3 with de&bridge-utils-0.9.6-2de& and de&ebtables-v2.0.6de& to rate shape bandwidth for our wireless subscribers, based on their MAC address. This bridge sits between our core wireless link and the switch connected to our servers and internet gateway. A perl script runs out of cron that connects to our mysql database to create the traffic queues automatically. I'm not including that here, but any programmer could figure out how to write their own suited to their own database, etc, or just write the config by hand for smaller networks. We're running on a little 400mhz PentiumII with 128mb RAM and it doesn't even sweat. We have around 500 customers, all rate shaped in their own individual queues. This could hypothetically support up to 20,000 individual traffic queues.
This is a very simple setup, but in trying to figure out how to do it, I found many unanswered posts on many web forums by people trying to do this.
Bridge configuration This gives us the ability to log in to the bridge, as well as give the bridge the ability to connect out to our mysql database server, etc:
------------- ifcfg-br0 ------------- DEVICE=br0 ONBOOT=no BOOTPROTO=static IPADDR=192.168.111.11 NETMASK=255.255.255.0
----------- bridge_up.sh -------------------- #!/bin/bash
ifdown eth0 ifdown eth1
ifconfig eth0 0.0.0.0 up ifconfig eth1 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth0 brctl addif br0 eth1
ifconfig br0 up
----------- bridge_down.sh -------------------- #!/bin/bash
ifdown eth0 ifdown eth1 ifconfig br0 down brctl delbr br0 The rate shaping part We're using de&tcde& to do the deed. This is my first attempt at this, so I may be doing some things wrong, especially with the de&tcde& commands - BUT IT WORKS - so I figure, I'll fix it later. You can use de&ebtables -L --Lcde& to see your customer's usage. I dump this out hourly, adding the de&-Zde& option to zero the counters out, then have a perl script parse that output and dump it into a mysql table where I can make better use of it.
--------------------------- rateshape ----------------------- #!/bin/bash # #
All Rates are in Kbits, so in order to gets Bytes divide by 8 #
e.g. 25Kbps == 3.125KB/s # TC=/sbin/tc EBTABLES=/sbin/ebtables
# Location of ebtables
cd /usr/local/bridge
tc_start() {
$TC qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 mpu 64
$TC qdisc add dev eth1 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 mpu 64
#Customer A #Two MACs: 00:0D:BD:A4:E1:C8 and 00:20:78:B0:25:7D #256kbps download speed ${TC} class add dev eth0 parent 1:0 classid 1:1 cbq rate 256KBit allot 1514 prio 1 avpkt 1000 bounded ${TC} filter add dev eth0 parent 1:0 protocol ip handle 1 fw flowid 1:1 ${EBTABLES} -A FORWARD -d 00:0D:BD:A4:E1:C8 -j mark --set-mark 1 --mark-target ACCEPT ${EBTABLES} -A FORWARD -d 00:20:78:B0:25:7D -j mark --set-mark 1 --mark-target ACCEPT #128kbps upload speed ${TC} class add dev eth1 parent 1:0 classid 1:1 cbq rate 128KBit allot 1514 prio 1 avpkt 1000 bounded ${TC} filter add dev eth1 parent 1:0 protocol ip handle 1 fw flowid 1:1 ${EBTABLES} -A FORWARD -s 00:0D:BD:A4:E1:C8 -j mark --set-mark 1 --mark-target ACCEPT ${EBTABLES} -A FORWARD -s 00:20:78:B0:25:7D -j mark --set-mark 1 --mark-target ACCEPT
#Customer B #MAC Address: 00:0D:BD:A4:D6:54 #800kbps download speed ${TC} class add dev eth0 parent 1:0 classid 1:2 cbq rate 800KBit allot 1514 prio 1 avpkt 1000 bounded ${TC} filter add dev eth0 parent 1:0 protocol ip handle 2 fw flowid 1:2 ${EBTABLES} -A FORWARD -d 00:0D:BD:A4:D6:54 -j mark --set-mark 2 --mark-target ACCEPT #64kbps upload speed ${TC} class add dev eth1 parent 1:0 classid 1:2 cbq rate 64KBit allot 1514 prio 1 avpkt 1000 bounded ${TC} filter add dev eth1 parent 1:0 protocol ip handle 2 fw flowid 1:2 ${EBTABLES} -A FORWARD -s 00:0D:BD:A4:D6:54 -j mark --set-mark 2 --mark-target ACCEPT
#Customer C #MAC Address: 00:0A:5E:22:D1:A3 #do not rate shape! ${EBTABLES} -A FORWARD -s 00:0A:5E:22:D1:A3 -j ACCEPT ${EBTABLES} -A FORWARD -d 00:0A:5E:22:D1:A3 -j ACCEPT
#Block anything we didn't specify above.&${EBTABLES} -A FORWARD -j DROP --log
#&my config has over 500 customers and over 1100 MAC addresses& #Just keep incrementing the classid, handle, flowid, and mark values for each customer's #individual speed queues. }
tc_stop() {
./save_and_reset_counters
${EBTABLES} -F
$TC qdisc del dev eth0 root
$TC qdisc del dev eth1 root }
tc_restart() {
tc_show() {
echo "eth0"
$TC qdisc show dev eth0
$TC class show dev eth0
$TC filter show dev eth0
echo "eth1"
$TC qdisc show dev eth1
$TC class show dev eth1&}
tc_stop() {
./save_and_reset_counters
${EBTABLES} -F
$TC qdisc del dev eth0 root
$TC qdisc del dev eth1 root }
tc_restart() {
tc_show() {
echo "eth0"
$TC qdisc show dev eth0
$TC class show dev eth0
$TC filter show dev eth0
echo "eth1"
$TC qdisc show dev eth1
$TC class show dev eth1
$TC filter show dev eth1
} case "$1" in
echo -n "Starting bandwidth shaping: "
echo "done"
echo -n "Stopping bandwidth shaping: "
echo "done"
echo -n "Restarting bandwidth shaping: "
tc_restart
echo "done"
echo "Usage: rateshape {start|stop|restart|show}"
;;&esac*********************************************************************ebtables DROP vs iptables DROP*********************************************************************
In iptables which in most cases is being used to filter network traffic the DROP target means "packet disapear". 说明：在ip层上传输的报文，DROP代表的是将报文消毁。In
ebtables a "-j redirect --redirect-target DROP" means "packet be gone
from the bridge into the upper layers of the kernel such as
routing\forwarding" 说明：也就是说在ebtables链条上，“-j redirect --redirect-target DROP”实际意义上是将在桥上（二层：以MAC地址为认别依据）传送的报文发配到路由层（三层：以ip地址为识别依据）上去分捡分发。Since
the ebtables works in the link layer of the connection in order to
intercept the connection we must "redirect" the traffic to the level
which iptables will be able to intercept\tproxy. 说明：也就是说，ebtables工作在链路层，为了将报文拦动进行透明代理分发，所以我们就必须将报文转移到ip层（iptable层）路径上才能实现拦劫与透明代理。A picture of the netfilter flow to illustrate:
ebtables Configuration Rules
Bridging configuration in Linux is done with the ebtables utility. You
also need to follow all the steps for setting up the Squid box as a
router device. These bridging rules are additional steps to move packets
from bridging mode to routing mode: ## interface facing clients
CLIENT_IFACE=eth0
## interface facing Internet
INET_IFACE=eth1
ebtables -t broute -A BROUTING \
-i $CLIENT_IFACE -p ipv6 --ip6-proto tcp --ip6-dport 80 \
-j redirect --redirect-target DROP
ebtables -t broute -A BROUTING \
-i $CLIENT_IFACE -p ipv4 --ip-proto tcp --ip-dport 80 \
-j redirect --redirect-target DROP
ebtables -t broute -A BROUTING \
-i $INET_IFACE -p ipv6 --ip6-proto tcp --ip6-sport 80 \
-j redirect --redirect-target DROP
ebtables -t broute -A BROUTING \
-i $INET_IFACE -p ipv4 --ip-proto tcp --ip-sport 80 \
-j redirect --redirect-target DROP
cd /proc/sys/net/bridge/
for i in *
echo 0 & $i
The bridge interfaces also need to be configured with public IP
addresses for Squid to use in its normal operating traffic (DNS, ICMP,
TPROXY failed requests, peer requests, etc)***************************ebtables 例子说明：***************************ebtables -A FORWARD -p ipv4 –ip_proto tcp -i eth0 -j DROP等同于：ebtables -t filter -A FORWARD -p ipv4 -ip_proto tcp -i eth0 -j DROP&&&&&&&&&& 表示意义是：默认使用filter表（功能表）提供的配套功能，凡是从eth0端口进来的tcp包，都不转发（或不桥接）。但是在broute表中，drop与accept的实际意义就不一样了，我们看一看作者的简介：ebtables的broute功能表中drop与accept的特殊意义
-t, --table&&&&&&&&&&&&& 1)filter& is the default table and contains three built-in chains:&&&&&&&&&&&& :: INPUT (for frames destined for the bridge itself, on& the& level& of& the& MAC destination address),&&&&&&&&&&&& :: OUTPUT (for locally-generated or (b)routed frames) and FORWARD (for frames being forwarded& by the bridge).&&&&&&&&&&&&& ::nat& is& mostly& used& to& change the mac addresses and contains three built-in chains: PREROUTING (for altering frames& as& soon as& they& come& in),& OUTPUT& (for altering locally generated or& (b)routed frames before they are bridged) and& POSTROUTING& (for altering& frames& as& they are about to go out). A small note on the naming of chains PREROUTING and& POSTROUTING:& it& would& be& more accurate to call them PREFORWARDING and POSTFORWARDING, but& for all those who come from the iptables world to ebtables it is& easier to have the same names. Note that you can change the name& (-E) if you don't like the default.&&&&&&&&&&&&& 2)broute is used to make a brouter& & & & & & & & & & & & & & && it& has& one& built-in& chain: BROUTING. & & & & & & & The targets DROP and ACCEPT have a special meaning in& the broute table (these names are used instead of more& descriptive& names& to keep the implementation generic).& &&&&&&&&&&&&& !!DROP actually means the fr&&&&&&&&&&&&& !!ACCEPT means& the& frame& has& to& be bridged. The BROUTING chain is traversed very early.&&&&&&&&&&&&& However, it is only traversed by frames& entering& on& a& bridge& port that is in forwarding state. Normally those frames would be& bridged, but you can decide otherwise here. The redirect& target& is very handy here.&&&&&&&& 总之，ebtables中的表与链与iptables中表与链有不同意义。特别是在broute表中的BROUTING链中，更表示的是ACCEPT表示的是直接进行桥接，而drop则表示的是将报文从二层桥（broute）上分发到三层路由（iptables）上去处理。实际上在broute表链上大多结合“-j redirect --redirect-target”来使用，更为方便。&&&&&&&& ebtables的链表时序&『附』关于ebtables的功能理解可以参看：&&&&&&&&&&& http://blog.csdn.net/u/article/details/
阅读(4587)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'Ebtables funcation Introduction(最权威的EBTABLES使用说明)',
blogAbstract:'
-----Base example and real-life examples from
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}}