extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-22 14:20:40 +01:00
Code Issues Packages Projects Releases Wiki Activity

Try to clarify IPP2P

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2800 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-10-05 16:31:15 +00:00
parent eb43db253f
commit c6d76edc6d
1 changed files with 99 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

100
Shorewall-docs2/IPP2P.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2005-10-02</pubdate>
<pubdate>2005-10-04</pubdate>
<copyright>
<year>2004</year>
@ -99,6 +99,101 @@
05# iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 1 -j CLASSIFY --set-class 1:12
06# iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 1 -j CLASSIFY --set-class 2:12</programlisting>
<para>Let's examine the above rules more carefully.</para>
<para>The individual packets of a P2P data stream do not all carry
tell-tale signs that are identifiable as being a particular P2P
application. So simply asking the ipp2p match code to mark each individual
packet isn't enough because only those packets that carry these tell-tale
signs will be marked. Fortunately, Netfilter provides a different type of
mark -- the <firstterm>Connection Mark</firstterm> which is associated
with the entry in the conntrack table rather that with the individual
packet. You can see connection mark values with the <command>shorewall
show connections</command> command:</para>
<programlisting>gateway:/etc/test# shorewall show connections
Shorewall-2.5.6 Connections at gateway - Tue Oct 4 15:45:11 PDT 2005
tcp 6 269712 ESTABLISHED src=192.168.3.8 dst=206.124.146.177 sport=50584 dport=993 packets=4899
bytes=302282 src=206.124.146.177 dst=192.168.3.8 sport=993 dport=50584 packets=7760 bytes=10032928 [ASSURED] <emphasis
role="bold">mark=0</emphasis> use=1
...</programlisting>
<para>Connection marks are persistent -- that is, once a connection mark
is set it retains its value until the connection is terminated. </para>
<para>Netfilter provides features to:</para>
<orderedlist>
<listitem>
<para>Mark individual packets with a numeric value.</para>
</listitem>
<listitem>
<para>Save the current packet mark value in the connection
mark.</para>
</listitem>
<listitem>
<para>Restore the value in the connection mark to the current
packet.</para>
</listitem>
</orderedlist>
<para>The strategy employed in the above rules is to mark the connection
of each P2P session with a mark value of 1. That way, each packet that is
part of the session can be marked using the 'Restore' function and can be
classified accordingly.</para>
<orderedlist>
<listitem>
<para>Rule 01# restores the connection mark into the current
packet.</para>
</listitem>
<listitem>
<para>Rule 02# tests that restored mark and if it is not equal to
zero, the packet is ACCEPTed (no further processing).</para>
</listitem>
<listitem>
<para>Rule 03# asks the ipp2p match module to examine the packet and
if it is identifiable as part of a P2P session, mark the packet with
value 1.</para>
</listitem>
<listitem>
<para>Rule 04# saves the current packet mark in the conntrack table if
the current mark value is 1 (in other words, if it was marked by rule
03#).</para>
</listitem>
<listitem>
<para>Rule 05# classifies the packet to traffic shaping class 1:12 if
it is going out of eth0 and has mark value 1<footnote>
<para>There are two ways that Netfilter/iptables can classify
traffic. It can be classified directly (which is what this example
does) by specifying a <firstterm>classid</firstterm> of the form
&lt;number&gt;:&lt;number&gt; in the MARK column. That is the
preferred method. A classid is specified when a traffic shaping
class is defined. tc4shorewall assigns a classid of 1:&lt;100 +
mark value&gt;. They may also be classified using an
<firstterm>fwmark classifier</firstterm> which causes the traffic
shaping code to classify the traffic based in the packet mark
value. That is done by the traffic shaping solution using the
<command>tc filter add</command> command. The built-in
tc4shorewall shaper uses this command so if you are using the
built-in traffic shaping solution, you may use either
method.</para>
</footnote>.</para>
</listitem>
<listitem>
<para>Rule 06# classifies the packet to traffic shaping class 2:12 if
it is going out of eth1 and has mark value 1.</para>
</listitem>
</orderedlist>
<para>These are implemented in the /etc/shorewall/tcrules file as
follows:</para>
@ -110,5 +205,8 @@ CONTINUE:P - - tcp - -
SAVE:P - - tcp - - - 1
1:12 - eth0 - - - - 1
2:12 - eth1 - - - - 1 </programlisting>
<para>These rules do exactly the same thing as their counterparts
described above.</para>
</section>
</article>