Let's take a brief look at a conntrack entry and how to read them in
/proc/net/ip_conntrack. This gives a list of all the
current entries in your conntrack database. If you have the
ip_conntrack module loaded, a cat
of /proc/net/ip_conntrack might look like:
tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \
dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \
dport=32775 [ASSURED] use=2
This example contains all the information that the conntrack module
maintains to know which state a specific connection is in. First of all, we
have a protocol, which in this case is tcp. Next, the same value
in normal decimal coding. After this, we see how long this conntrack entry has
to live. This value is set to 117 seconds right now and is decremented
regularly until we see more traffic. This value is then reset to the default
value for the specific state that it is in at that relevant point of time.
Next comes the actual state that this entry is in at the present point of
time. In the above mentioned case we are looking at a packet that is in the
SYN_SENT state. The internal value of a
connection is slightly different from the ones used externally with
iptables. The
value SYN_SENT tells us that we are looking
at a connection that has only seen a TCP SYN packet
in one direction. Next, we see the source IP
address, destination IP address,
source port and destination
port. At this point we see a specific keyword that tells us that
we have seen no return traffic for this connection. Lastly, we
see what we expect of return packets. The information details the
source IP address and destination IP
address (which are both inverted, since the packet is
to be directed back to us). The same thing goes for the
source port and destination
port of the connection. These are the values that should be of
any interest to us.
The connection tracking entries may take on a series of different values,
all specified in the conntrack headers available in
linux/include/netfilter-ipv4/ip_conntrack*.h files.
These values are dependent on which sub-protocol of
IP we use. TCP,
UDP or ICMP protocols
take specific default values as specified in
linux/include/netfilter-ipv4/ip_conntrack.h. We will
look closer at this when we look at each of the protocols; however, we
will not use them extensively through this chapter, since they are not used
outside of the conntrack internals. Also, depending on how this state
changes, the default value of the time until the connection is destroyed
will also change.
 | Recently there was a new patch made available in iptables patch-o-matic,
called tcp-window-tracking. This patch adds, among other things, all of
the above timeouts to special sysctl variables, which means that they can
be changed on the fly, while the system is still running. Hence, this
makes it unnecessary to recompile the kernel every time you want to change
the timeouts.
These can be altered via using specific system calls available in the
/proc/sys/net/ipv4/netfilter directory. You should
in particular look at the
/proc/sys/net/ipv4/netfilter/ip_ct_* variables.
|
When a connection has seen traffic in both directions, the conntrack entry
will erase the [UNREPLIED] flag, and then
reset it. The entry that tells us that the connection has not seen any
traffic in both directions, will be replaced by the
[ASSURED] flag, to be found close to the end
of the entry. The [ASSURED] flag tells us
that this connection is assured and that it will not be erased if we reach the
maximum possible tracked connections. Thus, connections marked as
[ASSURED] will not be erased, contrary to
the non-assured connections (those not marked as
[ASSURED]). How many connections that the
connection tracking table can hold depends upon a variable that can be set
through the ip-sysctl functions in recent kernels. The default value held by
this entry varies heavily depending on how much memory you have. On 128 MB of
RAM you will get 8192 possible entries, and at 256 MB of RAM, you will get
16376 entries. You can read and set your settings through the
/proc/sys/net/ipv4/ip_conntrack_max setting.
A different way of doing this, that is more efficient, is to set the hashsize
option to the ip_conntrack module once this is loaded.
Under normal circumstances ip_conntrack_max equals 8 * hashsize. In other
words, setting the hashsize to 4096 will result in ip_conntrack_max being set
to 32768 conntrack entries. An example of this would be:
work3:/home/blueflux# modprobe ip_conntrack hashsize=4096
work3:/home/blueflux# cat /proc/sys/net/ipv4/ip_conntrack_max
32768
work3:/home/blueflux#
