diff --git a/Shorewall-docs2/IPP2P.xml b/Shorewall-docs2/IPP2P.xml index a73652529..d8fb5a61e 100644 --- a/Shorewall-docs2/IPP2P.xml +++ b/Shorewall-docs2/IPP2P.xml @@ -15,7 +15,7 @@ - 2005-10-02 + 2005-10-04 2004 @@ -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 + Let's examine the above rules more carefully. + + 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 Connection Mark which is associated + with the entry in the conntrack table rather that with the individual + packet. You can see connection mark values with the shorewall + show connections command: + + 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] mark=0 use=1 +... + + Connection marks are persistent -- that is, once a connection mark + is set it retains its value until the connection is terminated. + + Netfilter provides features to: + + + + Mark individual packets with a numeric value. + + + + Save the current packet mark value in the connection + mark. + + + + Restore the value in the connection mark to the current + packet. + + + + 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. + + + + Rule 01# restores the connection mark into the current + packet. + + + + Rule 02# tests that restored mark and if it is not equal to + zero, the packet is ACCEPTed (no further processing). + + + + 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. + + + + 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#). + + + + Rule 05# classifies the packet to traffic shaping class 1:12 if + it is going out of eth0 and has mark value 1 + There are two ways that Netfilter/iptables can classify + traffic. It can be classified directly (which is what this example + does) by specifying a classid of the form + <number>:<number> 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:<100 + + mark value>. They may also be classified using an + fwmark classifier 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 + tc filter add 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. + . + + + + Rule 06# classifies the packet to traffic shaping class 2:12 if + it is going out of eth1 and has mark value 1. + + + These are implemented in the /etc/shorewall/tcrules file as follows: @@ -110,5 +205,8 @@ CONTINUE:P - - tcp - - SAVE:P - - tcp - - - 1 1:12 - eth0 - - - - 1 2:12 - eth1 - - - - 1 + + These rules do exactly the same thing as their counterparts + described above. \ No newline at end of file