Simon Kelley | 7de060b | 2011-08-26 17:24:52 +0100 | [diff] [blame] | 1 | Linux iptables includes that ability to mark individual network packets |
| 2 | with a "firewall mark". Additionally there is a component called |
| 3 | "conntrack" which tries to string sequences of related packets together |
| 4 | into a "connection" (it even relates sequences of UDP and ICMP packets). |
| 5 | There is a related mark for a connection called a "connection mark". |
| 6 | Marks can be copied freely between the firewall and connection marks |
| 7 | |
| 8 | Using these two features it become possible to tag all related traffic |
| 9 | in arbitrary ways, eg authenticated users, traffic from a particular IP, |
| 10 | port, etc. Unfortunately any kind of "proxy" breaks this relationship |
| 11 | because network packets go in one side of the proxy and a completely new |
| 12 | connection comes out of the other side. However, sometimes, we want to |
| 13 | maintain that relationship through the proxy and continue the connection |
| 14 | mark on packets upstream of our proxy |
| 15 | |
| 16 | DNSMasq includes such a feature enabled by the --conntrack |
| 17 | option. This allows, for example, using iptables to mark traffic from |
| 18 | a particular IP, and that mark to be persisted to requests made *by* |
| 19 | DNSMasq. Such a feature could be useful for bandwidth accounting, |
| 20 | captive portals and the like. Note a similar feature has been |
| 21 | implemented in Squid 2.2 |
| 22 | |
| 23 | |
| 24 | As an example consider the following iptables rules: |
| 25 | |
| 26 | |
| 27 | 1) iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark |
| 28 | 2) iptables -t mangle -A PREROUTING -m mark --mark 0 -s 192.168.111.137 |
| 29 | -j MARK --set-mark 137 |
| 30 | 3) iptables -t mangle -A PREROUTING -j CONNMARK --save-mark |
| 31 | |
| 32 | 4) iptables -t mangle -A OUTPUT -m mark ! --mark 0 -j CONNMARK --save-mark |
| 33 | |
| 34 | 1-3) are all applied to the PREROUTING table and affect all packets |
| 35 | entering the firewall. |
| 36 | |
| 37 | 1) copies any existing connection mark into the firewall mark. 2) Checks |
| 38 | the packet not already marked and if not applies an arbitrary mark based |
| 39 | on IP address. 3) Saves the firewall mark back to the connection mark |
| 40 | (which will persist it across related packets) |
| 41 | |
| 42 | 4) is applied to the OUTPUT table, which is where we first see packets |
| 43 | generated locally. DNSMasq will have already copied the firewall mark |
| 44 | from the request, across to the new packet, and so all that remains is |
| 45 | for iptables to copy it to the connection mark so it's persisted across |
| 46 | packets. |
| 47 | |
| 48 | Note: iptables can be quite confusing to the beginner. The following |
| 49 | diagram is extremely helpful in understanding the flows |
| 50 | http://linux-ip.net/nf/nfk-traversal.png |
| 51 | Additionally the following URL contains a useful "starting guide" on |
| 52 | linux connection tracking/marking |
| 53 | http://home.regit.org/netfilter-en/netfilter-connmark/ |
| 54 | |