mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-16 19:30:44 +01:00
597cfce50d
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4964 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
477 lines
18 KiB
XML
477 lines
18 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<refentry>
|
|
<refmeta>
|
|
<refentrytitle>shorewall-tcrules</refentrytitle>
|
|
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>tcrules</refname>
|
|
|
|
<refpurpose>Shorewall Packet Marking rules file</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>/etc/shorewall/</command>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>Entries in this file cause packets to be marked as a means of
|
|
classifying them for traffic control or policy routing.</para>
|
|
|
|
<important>
|
|
<para>Unlike rules in the shorewall-rules(5) file, evaluation of rules
|
|
in this file will continue after a match. So the final mark for each
|
|
packet will be the one assigned by the LAST tcrule that matches.</para>
|
|
|
|
<para>If you use multiple internet providers with the 'track' option, in
|
|
/etc/shorewall/providers be sure to read the restrictions at
|
|
http://shorewall.net/MultiISP.html.</para>
|
|
</important>
|
|
|
|
<para>The columns in the file are as follows.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MARK/CLASSIFY</emphasis></term>
|
|
|
|
<listitem>
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>A mark value which is an integer in the range
|
|
1-255.</para>
|
|
|
|
<para>Normally will set the mark value. If preceded by a
|
|
vertical bar ("|"), the mark value will be logically ORed with
|
|
the current mark value to produce a new mark value. If preceded
|
|
by an ampersand ("&"), will be logically ANDed with the
|
|
current mark value to produce a new mark value.</para>
|
|
|
|
<para>Both "|" and "&" require Extended MARK Target support
|
|
in your kernel and iptables; neither may be used with connection
|
|
marks (see below).</para>
|
|
|
|
<para>If HIGH_ROUTE_MARKS=Yes in shorewall.conf then you may
|
|
also specify a value in the range 0x0100-0xFF00 with the
|
|
low-order byte being zero. Such values may only be used in the
|
|
PREROUTING chain(value followed by <emphasis
|
|
role="bold">:F</emphasis> or you have set
|
|
MARK_IN_FORWARD_CHAIN=Yes in shorewall conf and have not
|
|
followed the value with :P) or the OUTPUT chain (SOURCE is
|
|
<emphasis role="bold">$FW</emphasis>).</para>
|
|
|
|
<para>May optionally be followed by <emphasis
|
|
role="bold">:P</emphasis> or <emphasis role="bold">:F</emphasis>
|
|
where<emphasis role="bold"> :P</emphasis> indicates that marking
|
|
should occur in the PREROUTING chain and <emphasis
|
|
role="bold">:F</emphasis> indicates that marking should occur in
|
|
the FORWARD chain. If neither <emphasis
|
|
role="bold">:P</emphasis> nor <emphasis
|
|
role="bold">:F</emphasis> follow the mark value then the chain
|
|
is determined by the setting of MARK_IN_FORWARD_CHAIN in
|
|
shorewall.conf(5).</para>
|
|
|
|
<para>If your kernel and iptables include CONNMARK support then
|
|
you can also mark the connection rather than the packet.</para>
|
|
|
|
<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). The mark and optional mask are then
|
|
followed by one of:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">C</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Mark the connection in the chain determined by the
|
|
setting of MARK_IN_FORWARD_CHAIN</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">CF</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Mark the connection in the FORWARD chain</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">CP</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Mark the connection in the PREROUTING chain.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A classification (classid) of the form
|
|
<emphasis>major</emphasis>:<emphasis>minor</emphasis> where
|
|
<emphasis>major</emphasis> and <emphasis>minor</emphasis> are
|
|
integers. Corresponds to the 'class' specification in these
|
|
traffic shaping modules:</para>
|
|
|
|
<programlisting> atm
|
|
cbq
|
|
dsmark
|
|
pfifo_fast
|
|
htb
|
|
prio</programlisting>
|
|
|
|
<para>Classification occurs in the POSTROUTING chain except when
|
|
the <emphasis role="bold">SOURCE</emphasis> is <emphasis
|
|
role="bold">$FW</emphasis>[:<emphasis>address</emphasis>] in
|
|
which case marking occurs in the OUTPUT chain.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis
|
|
role="bold">RESTORE</emphasis>[/<emphasis>mask</emphasis>] --
|
|
restore the packet's mark from the connection's mark using the
|
|
supplied mask if any. Your kernel and iptables must include
|
|
CONNMARK support.</para>
|
|
|
|
<para>As in a) above, may be followed by <emphasis
|
|
role="bold">:P</emphasis> or <emphasis
|
|
role="bold">:F</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis
|
|
role="bold">SAVE</emphasis>[/<emphasis>mask</emphasis>] -- save
|
|
the packet's mark to the connection's mark using the supplied
|
|
mask if any. Your kernel and iptables must include CONNMARK
|
|
support.</para>
|
|
|
|
<para>As in a) above, may be followed by <emphasis
|
|
role="bold">:P</emphasis> or <emphasis
|
|
role="bold">:F</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">CONTINUE</emphasis> Don't process
|
|
any more marking rules in the table.</para>
|
|
|
|
<para>As in a) above, may be followed by <emphasis
|
|
role="bold">:P</emphasis> or <emphasis
|
|
role="bold">:F</emphasis></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">COMMENT</emphasis> -- the rest of
|
|
the line will be attached as a comment to the Netfilter rule(s)
|
|
generated by the following entries. The comment will appear
|
|
delimited by "/* ... */" in the output of <command>shorewall
|
|
show mangle</command></para>
|
|
|
|
<para>To stop the comment from being attached to further rules,
|
|
simply include COMMENT on a line by itself.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SOURCE</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Source of the packet. A comma-separated list of interface
|
|
names, IP addresses, MAC addresses and/or subnets for packets being
|
|
routed through a common path. List elements may also consist of an
|
|
interface name followed by ":" and an address (e.g.,
|
|
eth1:192.168.1.0/24). For example, all packets for connections
|
|
masqueraded to eth0 from other interfaces can be matched in a single
|
|
rule with several alternative SOURCE criteria. However, a connection
|
|
whose packets gets to eth0 in a different way, e.g., direct from the
|
|
firewall itself, needs a different rule.</para>
|
|
|
|
<para>Accordingly, use $<emphasis role="bold">FW</emphasis> in its
|
|
own separate rule for packets originating on the firewall. In such a
|
|
rule, the MARK column may NOT specify either <emphasis
|
|
role="bold">:P</emphasis> or <emphasis role="bold">:F</emphasis>
|
|
because marking for firewall-originated packets always occurs in the
|
|
OUTPUT chain.</para>
|
|
|
|
<para>MAC addresses must be prefixed with "~" and use "-" as a
|
|
separator.</para>
|
|
|
|
<para>Example: ~00-A0-C9-15-39-78</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DEST</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Destination of the packet. Comma separated list of IP
|
|
addresses and/or subnets. If your kernel and iptables include
|
|
iprange match support, IP address ranges are also allowed. List
|
|
elements may also consist of an interface name followed by ":" and
|
|
an address (e.g., eth1:192.168.1.0/24). If the <emphasis
|
|
role="bold">MARK</emphasis> column specificies a classification of
|
|
the form <emphasis>major</emphasis>:<emphasis>minor</emphasis> then
|
|
this column may also contain an interface name.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">PROTO</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Protocol - Must be <emphasis role="bold">tcp</emphasis>,
|
|
<emphasis role="bold">udp</emphasis>, <emphasis
|
|
role="bold">icmp</emphasis>, <emphasis
|
|
role="bold">ipp2p</emphasis>,<emphasis role="bold">
|
|
ipp2p:udp</emphasis>, <emphasis role="bold">ipp2p:all</emphasis> a
|
|
<emphasis>number</emphasis>, or <emphasis
|
|
role="bold">all</emphasis>. <emphasis role="bold">ipp2p</emphasis>
|
|
requires ipp2p match support in your kernel and iptables.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">PORT(S)</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Destination Ports. A comma-separated list of Port names (from
|
|
services(5)), <emphasis>port number</emphasis>s or <emphasis>port
|
|
range</emphasis>s; if the protocol is <emphasis
|
|
role="bold">icmp</emphasis>, this column is interpreted as the
|
|
destination icmp-type(s).</para>
|
|
|
|
<para>If the protocol is <emphasis role="bold">ipp2p</emphasis>,
|
|
this column is interpreted as an ipp2p option without the leading
|
|
"--" (example <emphasis role="bold">bit</emphasis> for bit-torrent).
|
|
If no PORT is given, <emphasis role="bold">ipp2p</emphasis> is
|
|
assumed.</para>
|
|
|
|
<para>This column is ignored if PROTOCOL = all but must be entered
|
|
if any of the following field is supplied. In that case, it is
|
|
suggested that this field contain "-"</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SOURCE PORT(S)</emphasis>
|
|
(Optional)</term>
|
|
|
|
<listitem>
|
|
<para>Source port(s). If omitted, any source port is acceptable.
|
|
Specified as a comma-separated list of port names, port numbers or
|
|
port ranges.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">USER</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>This column may only be non-empty if the SOURCE is the
|
|
firewall itself.</para>
|
|
|
|
<para>The column may contain:</para>
|
|
|
|
<para>[!][<emphasis>user name or number</emphasis>][:<emphasis>group
|
|
name or number</emphasis>][+<emphasis>program
|
|
name</emphasis>]</para>
|
|
|
|
<para>When this column is non-empty, the rule applies only if the
|
|
program generating the output is running under the effective
|
|
<emphasis>user</emphasis> and/or <emphasis>group</emphasis>
|
|
specified (or is NOT running under that id if "!" is given).</para>
|
|
|
|
<para>Examples:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>joe</term>
|
|
|
|
<listitem>
|
|
<para>program must be run by joe</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>:kids</term>
|
|
|
|
<listitem>
|
|
<para>program must be run by a member of the 'kids'
|
|
group</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>!:kids</term>
|
|
|
|
<listitem>
|
|
<para>program must not be run by a member of the 'kids'
|
|
group</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>+upnpd</term>
|
|
|
|
<listitem>
|
|
<para>#program named upnpd</para>
|
|
|
|
<important>
|
|
<para>The ability to specify a program name was removed from
|
|
Netfilter in kernel version 2.6.14.</para>
|
|
</important>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>TEST</term>
|
|
|
|
<listitem>
|
|
<para>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>
|
|
|
|
<para>[<emphasis
|
|
role="bold">!</emphasis>]<emphasis>value</emphasis>[/<emphasis>mask</emphasis>][<emphasis
|
|
role="bold">:C</emphasis>]</para>
|
|
|
|
<para>Where:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>!</term>
|
|
|
|
<listitem>
|
|
<para>Inverts the test (not equal)</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis>value</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Value of the packet or connection mark.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis>mask</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>A mask to be applied to the mark before testing.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">:C</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Designates a connection mark. If omitted, the packet
|
|
mark's value is tested.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>If you don't want to define a test but need to specify
|
|
anything in the following columns, place a "-" in this field.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LENGTH</emphasis> (Optional)</term>
|
|
|
|
<listitem>
|
|
<para>Packet Length. This field, if present allow you to match the
|
|
length of a packet against a specific value or range of values. You
|
|
must have iptables length support for this to work. A range is
|
|
specified in the form
|
|
<emphasis>min</emphasis>:<emphasis>max</emphasis> where either
|
|
<emphasis>min</emphasis> or <emphasis>max</emphasis> (but not both)
|
|
may be omitted. If <emphasis>min</emphasis> is omitted, then 0 is
|
|
assumed; if <emphasis>max</emphasis> is omitted, than any packet
|
|
that is <emphasis>min</emphasis> or longer will match.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">TOS</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Type of service. Either a standard name, or a numeric value to
|
|
match.</para>
|
|
|
|
<programlisting> <emphasis role="bold">Minimize-Delay</emphasis> (16)
|
|
<emphasis role="bold">Maximize-Throughput</emphasis> (8)
|
|
<emphasis role="bold">Maximize-Reliability</emphasis> (4)
|
|
<emphasis role="bold">Minimize-Cost</emphasis> (2)
|
|
<emphasis role="bold">Normal-Service</emphasis> (0)</programlisting>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Example</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Example 1:</term>
|
|
|
|
<listitem>
|
|
<para>Mark all ICMP echo traffic with packet mark 1. Mark all peer
|
|
to peer traffic with packet mark 4.</para>
|
|
|
|
<para>This is a little more complex than otherwise expected. Since
|
|
the ipp2p module is unable to determine all packets in a connection
|
|
are P2P packets, we mark the entire connection as P2P if any of the
|
|
packets are determined to match.</para>
|
|
|
|
<para>We assume packet/connection mark 0 means unclassified.</para>
|
|
|
|
<programlisting> #MARK/ SOURCE DEST PROTO PORT(S) SOURCE USER TEST
|
|
#CLASSIFY PORT(S)
|
|
1 0.0.0.0/0 0.0.0.0/0 icmp echo-request
|
|
1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
|
|
RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0
|
|
CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0
|
|
4 0.0.0.0/0 0.0.0.0/0 ipp2p:all
|
|
SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0</programlisting>
|
|
|
|
<para>If a packet hasn't been classifed (packet mark is 0), copy the
|
|
connection mark to the packet mark. If the packet mark is set, we're
|
|
done. If the packet is P2P, set the packet mark to 4. If the packet
|
|
mark has been set, save it to the connection mark.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>FILES</title>
|
|
|
|
<para>/etc/shorewall/tcrules</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See ALSO</title>
|
|
|
|
<para>shorewall(8), shorewall-accounting(5), shorewall-actions(5),
|
|
shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5),
|
|
shorewall-ipsec(5), shorewall-maclist(5), shorewall-masq(5),
|
|
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
|
|
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
|
|
shorewall-route_rules(5), shorewall-routestopped(5), shorewall-rules(5),
|
|
shorewall.conf(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
|
|
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
|
|
</refsect1>
|
|
</refentry> |