forked from extern/shorewall_code
ebe6ff9749
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1903 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
457 lines
18 KiB
XML
457 lines
18 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<article>
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>Traffic Shaping/Control</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate>2005-01-14</pubdate>
|
|
|
|
<copyright>
|
|
<year>2001-2005</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
1.2 or any later version published by the Free Software Foundation; with
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
|
License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<section>
|
|
<title>Introduction</title>
|
|
|
|
<para>Shorewall does not do any type of Traffic Shaping/Bandwidth
|
|
management itself but it does contain some facilities to intergrate with
|
|
traffic shaping/control solutions. In order to use traffic shaping with
|
|
Shorewall, it is essential that you get a copy of the <ulink
|
|
url="http://ds9a.nl/lartc">Linux Advanced Routing and Shaping
|
|
HOWTO</ulink>, version 0.3.0 or later or <ulink
|
|
url="http://www.tldp.org/HOWTO/Traffic-Control-HOWTO/">The Traffic Control
|
|
HOWTO</ulink>. It is also necessary to be running Linux Kernel 2.4.18 or
|
|
later. Shorewall traffic shaping support consists of the following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>A new <emphasis role="bold">TC_ENABLED</emphasis> parameter in
|
|
/etc/shorewall.conf.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A new <emphasis role="bold">CLEAR_TC</emphasis> parameter in
|
|
/etc/shorewall.conf (Added in Shorewall 1.3.13). When Traffic Shaping
|
|
is enabled (TC_ENABLED=Yes), the setting of this variable determines
|
|
whether Shorewall clears the traffic shaping configuration during
|
|
Shorewall [re]start and Shorewall stop.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">/etc/shorewall/tcrules</emphasis> - A file
|
|
where you can specify firewall marking of packets. The firewall mark
|
|
value may be used to classify packets for traffic
|
|
shaping/control.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">/etc/shorewall/tcstart </emphasis>- A
|
|
user-supplied file that is sourced by Shorewall during
|
|
<quote>shorewall start</quote> and which you can use to define your
|
|
traffic shaping disciplines and classes. I have provided a <ulink
|
|
url="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</ulink> that
|
|
does table-driven CBQ shaping but if you read the traffic shaping
|
|
sections of the HOWTO mentioned above, you can probably code your own
|
|
faster than you can learn how to use my sample. I personally use
|
|
<ulink url="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</ulink> (see
|
|
below). HTB support may eventually become an integral part of
|
|
Shorewall since HTB is a lot simpler and better-documented than CBQ.
|
|
As of 2.4.20, HTB is a standard part of the kernel but iproute2 must
|
|
be patched in order to use it.</para>
|
|
|
|
<para>In tcstart, when you want to run the <quote>tc</quote> utility,
|
|
use the run_tc function supplied by shorewall if you want tc errors to
|
|
stop the firewall.</para>
|
|
|
|
<para>You can generally use off-the-shelf traffic shaping scripts by
|
|
simply copying them to /etc/shorewall/tcstart. I use <ulink
|
|
url="http://lartc.org/wondershaper/">The Wonder Shaper </ulink>(HTB
|
|
version) that way (i.e., I just copied wshaper.htb to
|
|
/etc/shorewall/tcstart and modified it according to the Wonder Shaper
|
|
README). <emphasis role="bold">WARNING</emphasis>: If you use use
|
|
Masquerading or SNAT (i.e., you only have one external IP address)
|
|
then listing internal hosts in the NOPRIOHOSTSRC variable in the
|
|
wshaper[.htb] script won't work. Traffic shaping occurs after SNAT has
|
|
already been applied so when traffic shaping happens, all outbound
|
|
traffic will have as a source address the IP addresss of your
|
|
firewall's external interface.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">/etc/shorewall/tcclear</emphasis> - A
|
|
user-supplied file that is sourced by Shorewall when it is clearing
|
|
traffic shaping. This file is normally not required as Shorewall's
|
|
method of clearing qdisc and filter definitions is pretty
|
|
general.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Shorewall allows you to start traffic shaping when Shorewall itself
|
|
starts or it allows you to bring up traffic shaping when you bring up your
|
|
interfaces.</para>
|
|
|
|
<para>To start traffic shaping when Shorewall starts:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Set TC_ENABLED=Yes and CLEAR_TC=Yes</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Supply an /etc/shorewall/tcstart script to configure your
|
|
traffic shaping rules.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Optionally supply an /etc/shorewall/tcclear script to stop
|
|
traffic shaping. That is usually unnecessary.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If your tcstart script uses the <quote>fwmark</quote>
|
|
classifier, you can mark packets using entries in
|
|
/etc/shorewall/tcrules.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>To start traffic shaping when you bring up your network interfaces,
|
|
you will have to arrange for your traffic shaping configuration script to
|
|
be run at that time. How you do that is distribution dependent and will
|
|
not be covered here. You then should:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Set TC_ENABLED=Yes and CLEAR_TC=No</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear
|
|
scripts.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If your tcstart script uses the <quote>fwmark</quote>
|
|
classifier, you can mark packets using entries in
|
|
/etc/shorewall/tcrules.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Kernel Configuration</title>
|
|
|
|
<para>This screen shot show how I've configured QoS in my Kernel:<graphic
|
|
align="center" fileref="images/QoS.png" /></para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>/etc/shorewall/tcrules</title>
|
|
|
|
<para>The fwmark classifier provides a convenient way to classify packets
|
|
for traffic shaping. The /etc/shorewall/tcrules file provides a means for
|
|
specifying these marks in a tabular fashion.</para>
|
|
|
|
<para>Normally, packet marking occurs in the PREROUTING chain before any
|
|
address rewriting takes place. This makes it impossible to mark inbound
|
|
packets based on their destination address when SNAT or Masquerading are
|
|
being used. Beginning with Shorewall 1.3.12, you can cause packet marking
|
|
to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option in
|
|
shorewall.conf.</para>
|
|
|
|
<important>
|
|
<para>Unlike entries in <filename><ulink
|
|
url="Documentation.htm#Rules">/etc/shorewall/rules</ulink></filename>,
|
|
evaluation of entries in <filename>/etc/shorewall/tcrules</filename>
|
|
continues after a match. So the final mark assigned to each packet is
|
|
determined by the <emphasis role="bold">last</emphasis> matching entry
|
|
in the <filename>/etc/shorewall/tcrules</filename> file.</para>
|
|
</important>
|
|
|
|
<para>Columns in the file are as follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>MARK - Specifies the mark value is to be assigned in case of a
|
|
match. This is an integer in the range 1-255. Beginning with Shorewall
|
|
version 1.3.14, this value may be optionally followed by
|
|
<quote>:</quote> and either <quote>F</quote> or <quote>P</quote> to
|
|
designate that the marking will occur in the FORWARD or PREROUTING
|
|
chains respectively. If this additional specification is omitted, the
|
|
chain used to mark packets will be determined by the setting of the
|
|
MARK_IN_FORWARD_CHAIN option in shorewall.conf.</para>
|
|
|
|
<para>This possible values in this field were expanded in Shorewall
|
|
version 2.2.0:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If your kernel and iptables include CONNMARK support then
|
|
you can also mark the connection rather than the packet</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The mark value may be optionally followed by "/" and a
|
|
mask value (used to determine those bits of the connection
|
|
mark to actually be set).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The mark and optional mask are then followed by one
|
|
of:<simplelist>
|
|
<member>C: Mark the connection in the chain determined by
|
|
the setting of MARK_IN_FORWARD_CHAIN</member>
|
|
|
|
<member>CF: Mark the conneciton in the FORWARD
|
|
chain</member>
|
|
|
|
<member>CP: Mark the connection in the PREROUTING
|
|
chain.</member>
|
|
</simplelist></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A classification of the form <major>:<minor>
|
|
where <major> and <minor> are integers. Corresponds to
|
|
the 'class' specification in these traffic shaping
|
|
modules:<simplelist>
|
|
<member>- atm</member>
|
|
|
|
<member>- cbq</member>
|
|
|
|
<member>- dsmark</member>
|
|
|
|
<member>- pfifo_fast</member>
|
|
|
|
<member>- htb</member>
|
|
|
|
<member>- prio</member>
|
|
</simplelist>Classification always occurs in the POSTROUTING
|
|
chain. This feature requires Shorewall 2.2.0 and requires that
|
|
your kernel and iptables include CLASSIFY target support.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RESTORE[/mask] -- restore the packet's mark from the
|
|
connection's mark using the supplied mask if any. Your kernel and
|
|
iptables must include CONNMARK support. As iabove, may be followed
|
|
by ":P" or ":F</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>SAVE[/mask] -- save the packet's mark to the connection's
|
|
mark using the supplied mask if any. Your kernel and iptables must
|
|
include CONNMARK support. As above, may be followed by ":P" or
|
|
":F</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>CONTINUE -- don't process any more marking rules in the
|
|
table. As above, may be followed by ":P" or ":F".</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>SOURCE - The source of the packet. If the packet originates on
|
|
the firewall, place <quote>fw</quote> in this column. Otherwise, this
|
|
is a comma-separated list of interface names, IP addresses, MAC
|
|
addresses in Shorewall Format and/or Subnets.</para>
|
|
|
|
<para>Examples <programlisting> eth0
|
|
192.168.2.4,192.168.1.0/24</programlisting></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>DEST -- Destination of the packet. Comma-separated list of IP
|
|
addresses and/or subnets.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>PROTO - Protocol - Must be the name of a protocol from
|
|
/etc/protocol, "ipp2p", a number or "all". For "ipp2p", your kernel
|
|
and iptables must have ipp2p match support from <ulink
|
|
url="http://www.netfilter.org">Netfilter
|
|
Patch_o_matic_ng</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>PORT(S) - Destination Ports. A comma-separated list of Port
|
|
names (from /etc/services), port numbers or port ranges (e.g., 21:22);
|
|
if the protocol is <quote>icmp</quote>, this column is interpreted as
|
|
the destination icmp type(s). If the protocol is "ipp2p", then this
|
|
column is interpreted as an ipp2p option without the leading "--"
|
|
(default "ipp2p"). For a list of value ipp2p options, as root type
|
|
<command>iptables -m ipp2p --help</command>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>CLIENT PORT(S) (Renamed SOURCE PORT(S) in Shorewall 2.2.0) -
|
|
(Optional) Source port(s). If omitted, any source port is acceptable.
|
|
Specified as a comma-separate list of port names, port numbers or port
|
|
ranges.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>USER (Added in Shorewall version 1.4.10) - (Optional) This
|
|
column may only be non-empty if the SOURCE is the firewall itself.
|
|
When this column is non-empty, the rule applies only if the program
|
|
generating the output is running under the effective user and/or
|
|
group. It may contain :</para>
|
|
|
|
<para>[<user name or number>]:[<group name or
|
|
number>]</para>
|
|
|
|
<para>The colon is optionnal when specifying only a user.</para>
|
|
|
|
<para>Examples : john: / john / :users / john:users</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>TEST (added in Shorewall version 2.2.0). Defines a test on the
|
|
existing packet or connection mark. The rule will match only if the
|
|
test returns true. Tests have the format</para>
|
|
|
|
<programlisting>[!]<value>[/<mask>][:C]</programlisting>
|
|
|
|
<para>where</para>
|
|
|
|
<simplelist>
|
|
<member>! Inverts the test (not equal)</member>
|
|
|
|
<member><<emphasis>value</emphasis>> Value of the packet or
|
|
connection mark.</member>
|
|
|
|
<member><<emphasis>mask</emphasis>> A mask to be applied to
|
|
the mark before testing</member>
|
|
|
|
<member>:C Designates a connection mark. If omitted, the packet
|
|
mark's value is tested.</member>
|
|
</simplelist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<example>
|
|
<title></title>
|
|
|
|
<para>All packets arriving on eth1 should be marked with 1. All packets
|
|
arriving on eth2 and eth3 should be marked with 2. All packets
|
|
originating on the firewall itself should be marked with 3.</para>
|
|
|
|
<programlisting>#MARK SOURCE DESTINATION PROTO PORT(S) SOURCE PORT(S) USER/GROUP TEST
|
|
1 eth1 0.0.0.0/0 all
|
|
2 eth2 0.0.0.0/0 all
|
|
2 eth3 0.0.0.0/0 all
|
|
3 fw 0.0.0.0/0 all</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title></title>
|
|
|
|
<para>All GRE (protocol 47) packets not originating on the firewall and
|
|
destined for 155.186.235.151 should be marked with 12.</para>
|
|
|
|
<programlisting>#MARK SOURCE DESTINATION PROTO PORT(S) SOURCE PORT(S) USER/GROUP TEST
|
|
12 0.0.0.0/0 155.182.235.151 47</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title></title>
|
|
|
|
<para>All SSH packets originating in 192.168.1.0/24 and destined for
|
|
155.186.235.151 should be marked with 22.</para>
|
|
|
|
<programlisting>#MARK SOURCE DESTINATION PROTOCOL PORT(S) SOURCE PORT(S) USER/GROUP TEST
|
|
22 192.168.1.0/24 155.182.235.151 tcp 22</programlisting>
|
|
</example>
|
|
</section>
|
|
|
|
<section>
|
|
<title>My Current Setup</title>
|
|
|
|
<para>I am currently using the HTB version of <ulink
|
|
url="http://lartc.org/wondershaper/">The Wonder Shaper </ulink>(I just
|
|
copied wshaper.htb to /etc/shorewall/tcstart and modified it as shown in
|
|
the Wondershaper README). WonderShaper DOES NOT USE THE
|
|
/etc/shorewall/tcrules file.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>My Old Setup</title>
|
|
|
|
<para>I have also run with the following set of hand-crafted rules in my
|
|
<emphasis role="bold">/etc/shorewall/tcstart</emphasis> file.</para>
|
|
|
|
<blockquote>
|
|
<programlisting>run_tc qdisc add dev eth0 root handle 1: htb default 30
|
|
|
|
run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k
|
|
echo <quote> Added Top Level Class -- rate 384kbit</quote>
|
|
|
|
run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
|
|
run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
|
|
run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit ceil 384kbit burst 15k quantum 1500 prio 1
|
|
echo <quote> Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit</quote>
|
|
|
|
run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
|
|
run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
|
|
run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
|
|
echo <quote> Enabled PFIFO on Second Level Classes</quote>
|
|
|
|
run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
|
|
run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
|
|
run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
|
|
echo <quote> Defined fwmark filters</quote>
|
|
</programlisting>
|
|
</blockquote>
|
|
|
|
<para>My tcrules file that went with this tcstart file is shown in Example
|
|
1 above. When I was using these rules:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>I wanted to allow up to 140kbits/second for traffic outbound
|
|
from my DMZ (eth1 -- note that the ceiling is set to 384kbit so
|
|
outbound DMZ traffic can use all available bandwidth if there is no
|
|
traffic from the local systems or from my laptop or firewall).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>My laptop (which at that time connected via eth3) and local
|
|
systems (eth2) could use up to 224kbits/second.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>My firewall could use up to 20kbits/second.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Once www.shorewall.net was moved off-site, I no longer needed these
|
|
shaping rules and The Wonder Shaper does all that I now require.</para>
|
|
</section>
|
|
</article> |