Indice de la Documentación
9.4 CONTROL DE TRAFICO (TRAFFIC SHAPING AND CONTROL)
Shorewall has limited support for traffic shaping/control. In order to use traffic shaping
under Shorewall, it is essential that you get a copy of the Linux Advanced Routing and
Shaping HOWTO, version 0.3.0 or later. It is also necessary to be running Linux Kernel
2.4.18 or later.
Shorewall traffic shaping support consists of the following:
ˇ A new TC_ENABLED parameter in /etc/shorewall.conf. Traffic Shaping also requires that you
enable packet mangling.
ˇ A new CLEAR_TC 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.
ˇ /etc/shorewall/tcrules - A file where you can specify firewall marking of packets. The
firewall mark value may be used to classify packets for traffic shaping/control.
ˇ /etc/shorewall/tcstart - A user-supplied file that is sourced by Shorewall during
"shorewall start" and which you can use to define your traffic shaping disciplines and
classes. I have provided a sample 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 HTB (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.
In tcstart, when you want to run the 'tc' utility, use the run_tc function supplied by
shorewall if you want tc errors to stop the firewall.
You can generally use off-the-shelf traffic shaping scripts by simply copying them to
/etc/shorewall/tcstart. I use The Wonder Shaper (HTB version) that way (i.e., I just copied
wshaper.htb to /etc/shorewall/tcstart and modified it according to the Wonder Shaper
README). WARNING: 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.
ˇ /etc/shorewall/tcclear - 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.
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.
To start traffic shaping when Shorewall starts:
1. Set TC_ENABLED=Yes and CLEAR_TC=Yes
2. Supply an /etc/shorewall/tcstart script to configure your traffic shaping rules.
3. Optionally supply an /etc/shorewall/tcclear script to stop traffic shaping. That is
usually unnecessary.
4. If your tcstart script uses the 'fwmark' classifier, you can mark packets using entries
in /etc/shorewall/tcrules.
5.
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:
1. Set TC_ENABLED=Yes and CLEAR_TC=No
2. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.
4. If your tcstart script uses the 'fwmark' classifier, you can mark packets using entries
in /etc/shorewall/tcrules.
9.4.1 CONFIGURACIÓN /ETC/SHOREWALL/TCRULES
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.
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.
Columns in the file are as follows:
ˇ 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 ":" and either 'F' or 'P' 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.
Example - 5
ˇ SOURCE - The source of the packet. If the packet originates on the firewall, place "fw" in
this column. Otherwise, this is a comma-separated list of interface names, IP addresses, MAC
addresses in Shorewall Format and/or Subnets.
Examples
eth0
192.168.2.4,192.168.1.0/24
ˇ DEST -- Destination of the packet. Comma-separated list of IP addresses and/or subnets.
ˇ PROTO - Protocol - Must be the name of a protocol from /etc/protocol, a number or "all"
ˇ 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 "icmp", this column is
interpreted as the destination icmp type(s).
ˇ CLIENT PORT(S) - (Optional) Port(s) used by the client. If omitted, any source port is
acceptable. Specified as a comma-separate list of port names, port numbers or port ranges.
Example 1 - 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.
MARK SOURCE DEST PROTO PORT(S) CLIENT PORT(S)
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
Example 2 - All GRE (protocol 47) packets not originating on the firewall and destined for
155.186.235.151 should be marked with 12.
MARK SOURCE DEST PROTO PORT(S) CLIENT PORT(S)
12 0.0.0.0/0 155.186.235.151 47
Example 3 - All SSH packets originating in 192.168.1.0/24 and destined for 155.186.235.151
should be marked with 22.
MARK SOURCE DEST PROTO PORT(S) CLIENT PORT(S)
22 192.168.1.0/24 155.186.235.151 tcp 22
9.4.2 CONFIGURACIÓN DEMO
While I am currently using the HTB version of The Wonder Shaper (I just copied wshaper.htb
to /etc/shorewall/tcstart and modified it as shown in the Wondershaper README), I have also
run with the following set of hand-crafted rules in my /etc/shorewall/tcstart file:
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 " Added Top Level Class -- rate 384kbit"
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 " Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
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 " Enabled PFIFO on Second Level Classes"
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 " Defined fwmark filters"
My tcrules file that went with this tcstart file is shown in Example 1 above. You can look
at my configuration to see why I wanted shaping of this type.
1. I wanted to allow up to 140kbits/second for traffic outbound from my DMZ (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).
2. My laptop and local systems could use up to 224kbits/second.
3. My firewall could use up to 20kbits/second.
You see the rest of my Shorewall configuration to see how this fit in.
Indice de la Documentación
|
