|
[-]
[+]
|
Changed |
conntrack-tools.changes
|
|
|
|
[-]
[+]
|
Changed |
conntrack-tools.spec
^
|
|
|
|
[-]
[+]
|
Deleted |
conntrack-tools-1.4.0.tar.bz2/doc/manual/conntrack-tools.html
^
|
| @@ -1,569 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The conntrack-tools user manual</title><link rel="stylesheet" type="text/css" href="docbook.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div class="book" title="The conntrack-tools user manual"><div class="titlepage"><div><div><h1 class="title"><a id="conntrack-tools-how-to"></a>The conntrack-tools user manual</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Pablo</span> <span class="surname">Neira Ayuso</span></h3><div class="affiliation"><div class="address"><p><br />
- <code class="email"><<a class="email" href="mailto:pablo@netfilter.org">pablo@netfilter.org</a>></code><br />
- </p></div></div></div></div></div><div><p class="releaseinfo">
- This document details how to install and configure the
- <a class="ulink" href="http://conntrack-tools.netfilter.org" target="_top">conntrack-tools</a>
- >= 1.4.0. This document will evolve in the future to cover new features
- and changes.</p></div><div><p class="copyright">Copyright © 2008-2012 Pablo Neira Ayuso</p></div><div><div class="legalnotice" title="Legal Notice"><a id="idp1019616"></a><p>
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.2
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
- A copy of the license is included in the section entitled "GNU
- Free Documentation License".
- </p></div></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="chapter"><a href="#introduction">1. Introduction</a></span></dt><dt><span class="chapter"><a href="#what">2. What are the conntrack-tools?</a></span></dt><dt><span class="chapter"><a href="#requirements">3. Requirements</a></span></dt><dt><span class="chapter"><a href="#Installation">4. Installation</a></span></dt><dt><span class="chapter"><a href="#conntrack">5. Using conntrack: the command line interface</a></span></dt><dt><span class="chapter"><a href="#settingup">6. Setting up conntrackd: the daemon</a></span></dt><dd><dl><dt><span class="sect1"><a href="#sync">State table synchronization</a></span></dt><dd><dl><dt><span class="sect2"><a href="#sync-requirements">Requirements</a></span></dt><dt><span class="sect2"><a href="#sync-configure">Configuring the daemon</a></span></dt><dt><span class="sect2"><a href="#sync-pb">Active-Backup setup</a></span></dt><dt><span class="sect2"><a href="#sync-aa">Active-Active setup</a></span></dt><dt><span class="sect2"><a href="#sync-launch">Launching conntrackd</a></span></dt><dt><span class="sect2"><a href="#sync-options">Other configuration options</a></span></dt></dl></dd><dt><span class="sect1"><a href="#helpers">User-space helpers</a></span></dt><dt><span class="sect1"><a href="#sync-trouble">Troubleshooting</a></span></dt></dl></dd></dl></div><div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="introduction"></a>Chapter 1. Introduction</h2></div></div></div><p>This document should be a kick-off point to install and configure the
- <a class="ulink" href="http://conntrack-tools.netfilter.org" target="_top">conntrack-tools</a>.
- If you find any error or imprecision in this document, please send an email
- to the author, it will be appreciated.</p><p>In this document, the author assumes that the reader is familiar with firewalling concepts and iptables in general. If this is not your case, I suggest you to read the iptables documentation before going ahead. Moreover, the reader must also understand the difference between <span class="emphasis"><em>stateful</em></span> and <span class="emphasis"><em>stateless</em></span> firewalls. If this is not your case, I strongly suggest you to read the article <a class="ulink" href="http://people.netfilter.org/pablo/docs/login.pdf" target="_top">Netfilter's Connection Tracking System</a> published in <span class="emphasis"><em>:login; the USENIX magazine</em></span>. That document contains a general description that should help to clarify the concepts.</p><p>If you do not fulfill the previous requirements, this documentation is likely to be a source of frustration. Probably, you wonder why I'm insisting on these prerequisites too much, the fact is that if your iptables rule-set is <span class="emphasis"><em>stateless</em></span>, it is very likely that the <span class="emphasis"><em>conntrack-tools</em></span> will not be of any help for you. You have been warned!</p></div><div class="chapter" title="Chapter 2. What are the conntrack-tools?"><div class="titlepage"><div><div><h2 class="title"><a id="what"></a>Chapter 2. What are the conntrack-tools?</h2></div></div></div><p>The conntrack-tools are a set of free software tools for GNU/Linux that allow system administrators interact, from user-space, with the in-kernel <a class="ulink" href="http://people.netfilter.org/pablo/docs/login.pdf" target="_top">Connection Tracking System</a>, which is the module that enables stateful packet inspection for iptables. Probably, you did not hear about this module so far. However, if any of the rules of your rule-set use the <span class="emphasis"><em>state</em></span> or <span class="emphasis"><em>ctstate</em></span> iptables matches, you are indeed using it.
-
- </p><p>The <a class="ulink" href="http://conntrack-tools.netfilter.org" target="_top">conntrack-tools</a> package contains two programs:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>conntrack</em></span> is command line interface conntrack provides a more flexible interface to the connnection tracking system than /proc/net/ip_conntrack. With conntrack, you can show, delete and update the existing state entries; and you can also listen to flow events.</p></li><li class="listitem"><p><span class="emphasis"><em>conntrackd</em></span> is the user-space connection tracking daemon. This daemon can be used to deploy fault-tolerant GNU/Linux firewalls but you can also use it to collect flow-based statistics of the firewall use.</p></li></ul></div><p>Although the name of both tools is very similar - and you can blame me for that, I'm not a marketing guy - they are used for very different tasks.</p></div><div class="chapter" title="Chapter 3. Requirements"><div class="titlepage"><div><div><h2 class="title"><a id="requirements"></a>Chapter 3. Requirements</h2></div></div></div><p>You have to install the following software in order to get the <span class="emphasis"><em>conntrack-tools</em></span> working. Make sure that you have installed them correctly before going ahead:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://www.kernel.org" target="_top">Linux kernel</a> version >= 2.6.18 that, at least, has support for:</p><div class="itemizedlist"><ul class="itemizedlist" type="circle"><li class="listitem"><p>Connection Tracking System.</p><div class="itemizedlist"><ul class="itemizedlist" type="square"><li class="listitem"><p>CONFIG_NF_CONNTRACK=m</p></li><li class="listitem"><p>CONFIG_NF_CONNTRACK_IPV4=m</p></li><li class="listitem"><p>CONFIG_NF_CONNTRACK_IPV6=m (if your setup supports IPv6)</p></li></ul></div></li><li class="listitem"><p>nfnetlink: the generic messaging interface for Netfilter.</p><div class="itemizedlist"><ul class="itemizedlist" type="square"><li class="listitem"><p>CONFIG_NETFILTER_NETLINK=m</p></li></ul></div></li><li class="listitem"><p>nf_conntrack_netlink: the messaging interface for the Connection Tracking System.</p><div class="itemizedlist"><ul class="itemizedlist" type="square"><li class="listitem"><p>CONFIG_NF_CT_NETLINK=m</p></li></ul></div></li><li class="listitem"><p>connection tracking event notification API: the flow-based event notification interface.</p><div class="itemizedlist"><ul class="itemizedlist" type="square"><li class="listitem"><p>CONFIG_NF_CONNTRACK_EVENTS=y</p></li></ul></div></li></ul></div><div class="note" title="Verifying kernel support" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Verifying kernel support"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Verifying kernel support</th></tr><tr><td align="left" valign="top"><p>
- Make sure you have loaded <span class="emphasis"><em>nf_conntrack</em></span>, <span class="emphasis"><em>nf_conntrack_ipv4</em></span> (if your setup also supports IPv6, <span class="emphasis"><em>nf_conntrack_ipv6</em></span>) and <span class="emphasis"><em>nf_conntrack_netlink</em></span>.
- </p></td></tr></table></div></li><li class="listitem"><p>libnfnetlink: the netfilter netlink library use the official release available in <a class="ulink" href="http://www.netfilter.org" target="_top">netfilter.org</a></p></li><li class="listitem"><p>libnetfilter_conntrack: the netfilter netlink library use the official release available in <a class="ulink" href="http://www.netfilter.org" target="_top">netfilter.org</a></p></li></ul></div></div><div class="chapter" title="Chapter 4. Installation"><div class="titlepage"><div><div><h2 class="title"><a id="Installation"></a>Chapter 4. Installation</h2></div></div></div><p>To compile and install the <span class="emphasis"><em>conntrack-tools</em></span> run the following commands:</p><pre class="programlisting">
- (non-root)$ tar xvjf conntrack-tools-x.x.x.tar.bz2
- (non-root)$ cd conntrack-tools-x.x.x
- (non-root)$ ./configure --prefix=/usr
- (non-root)$ make
- (root) # make install</pre><div class="note" title="Fedora Users" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Fedora Users"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Fedora Users</th></tr><tr><td align="left" valign="top"><p>If you are installing the libraries in /usr/local/, do not forget to do the following things:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; export PKG_CONFIG_PATH</p></li><li class="listitem"><p>Add `/usr/local/lib' to your /etc/ld.so.conf file and run `ldconfig'</p></li></ul></div><p>Check `ldd' for trouble-shooting, read <a class="ulink" href="http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html" target="_top">this</a> for more information on how libraries work.</p></td></tr></table></div><div class="note" title="Verifying kernel support" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Verifying kernel support"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Verifying kernel support</th></tr><tr><td align="left" valign="top"><p>To check that the modules are enabled in the kernel, run <span class="emphasis"><em>`conntrack -E'</em></span> and generate traffic, you should see flow events reporting new connections and updates.
- </p></td></tr></table></div></div><div class="chapter" title="Chapter 5. Using conntrack: the command line interface"><div class="titlepage"><div><div><h2 class="title"><a id="conntrack"></a>Chapter 5. Using conntrack: the command line interface</h2></div></div></div><p>The <span class="emphasis"><em>/proc/net/ip_conntrack</em></span> interface is very limited as it only allows you to display the existing flows, their state and other information:</p><pre class="programlisting">
- # cat /proc/net/ip_conntrack
- tcp 6 431982 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34846 dport=993 packets=169 bytes=14322 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34846 packets=113 bytes=34787 [ASSURED] mark=0 secmark=0 use=1
- tcp 6 431698 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34849 dport=993 packets=244 bytes=18723 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34849 packets=203 bytes=144731 [ASSURED] mark=0 secmark=0 use=1
- </pre><p>The command line tool <span class="emphasis"><em>conntrack</em></span> can be used to display the same information:</p><pre class="programlisting">
- # conntrack -L
- tcp 6 431982 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34846 dport=993 packets=169 bytes=14322 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34846 packets=113 bytes=34787 [ASSURED] mark=0 secmark=0 use=1
- tcp 6 431698 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34849 dport=993 packets=244 bytes=18723 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34849 packets=203 bytes=144731 [ASSURED] mark=0 secmark=0 use=1
-conntrack v0.9.7 (conntrack-tools): 2 flow entries have been shown.
- </pre><p>You can natively filter the output without using <span class="emphasis"><em>grep</em></span>:</p><pre class="programlisting">
- # conntrack -L -p tcp --dport 34856
- tcp 6 431982 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34846 dport=993 packets=169 bytes=14322 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34846 packets=113 bytes=34787 [ASSURED] mark=0 secmark=0 use=1
-conntrack v0.9.7 (conntrack-tools): 1 flow entries have been shown.
- </pre><p>Update the mark based on a selection, this allows you to change the mark of an entry without using the CONNMARK target:</p><pre class="programlisting">
- # conntrack -U -p tcp --dport 3486 --mark 10
- tcp 6 431982 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34846 dport=993 packets=169 bytes=14322 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34846 packets=113 bytes=34787 [ASSURED] mark=1 secmark=0 use=1
-conntrack v0.9.7 (conntrack-tools): 1 flow entries has been updated.
- </pre><p>Delete one entry, this can be used to block traffic if:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>You have a stateful rule-set that blocks traffic in INVALID state.</p></li><li class="listitem"><p>You have set <span class="emphasis"><em>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose</em></span> or <span class="emphasis"><em>/proc/sys/net/netfilter/nf_conntrack_tcp_loose</em></span>, depending on your kernel version, to zero.</p></li></ul></div><pre class="programlisting">
- # conntrack -D -p tcp --dport 3486
- tcp 6 431982 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34846 dport=993 packets=169 bytes=14322 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34846 packets=113 bytes=34787 [ASSURED] mark=1 secmark=0 use=1
-conntrack v0.9.7 (conntrack-tools): 1 flow entries has been deleted.
- </pre><p>Display the connection tracking events:</p><pre class="programlisting">
- # conntrack -E
- [NEW] udp 17 30 src=192.168.2.100 dst=192.168.2.1 sport=57767 dport=53 [UNREPLIED] src=192.168.2.1 dst=192.168.2.100 sport=53 dport=57767
- [UPDATE] udp 17 29 src=192.168.2.100 dst=192.168.2.1 sport=57767 dport=53 src=192.168.2.1 dst=192.168.2.100 sport=53 dport=57767
- [NEW] tcp 6 120 SYN_SENT src=192.168.2.100 dst=66.102.9.104 sport=33379 dport=80 [UNREPLIED] src=66.102.9.104 dst=192.168.2.100 sport=80 dport=33379
- [UPDATE] tcp 6 60 SYN_RECV src=192.168.2.100 dst=66.102.9.104 sport=33379 dport=80 src=66.102.9.104 dst=192.168.2.100 sport=80 dport=33379
- [UPDATE] tcp 6 432000 ESTABLISHED src=192.168.2.100 dst=66.102.9.104 sport=33379 dport=80 src=66.102.9.104 dst=192.168.2.100 sport=80 dport=33379 [ASSURED]
-</pre><p>You can also display the existing flows in XML format, filter the output based on the NAT handling applied, etc.</p></div><div class="chapter" title="Chapter 6. Setting up conntrackd: the daemon"><div class="titlepage"><div><div><h2 class="title"><a id="settingup"></a>Chapter 6. Setting up conntrackd: the daemon</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#sync">State table synchronization</a></span></dt><dd><dl><dt><span class="sect2"><a href="#sync-requirements">Requirements</a></span></dt><dt><span class="sect2"><a href="#sync-configure">Configuring the daemon</a></span></dt><dt><span class="sect2"><a href="#sync-pb">Active-Backup setup</a></span></dt><dt><span class="sect2"><a href="#sync-aa">Active-Active setup</a></span></dt><dt><span class="sect2"><a href="#sync-launch">Launching conntrackd</a></span></dt><dt><span class="sect2"><a href="#sync-options">Other configuration options</a></span></dt></dl></dd><dt><span class="sect1"><a href="#helpers">User-space helpers</a></span></dt><dt><span class="sect1"><a href="#sync-trouble">Troubleshooting</a></span></dt></dl></div><p>The daemon <span class="emphasis"><em>conntrackd</em></span> supports two working modes:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>State table synchronization</em></span>: the daemon can be used to synchronize the connection tracking state table between several firewall replicas. This can be used to deploy fault-tolerant stateful firewalls. This is the main feature of the daemon.</p></li><li class="listitem"><p><span class="emphasis"><em>Flow-based statistics collection</em></span>: the daemon can be used to collect flow-based statistics. This feature is similar to what <a class="ulink" href="http://www.netfilter.org/projects/ulogd/" target="_top">ulogd-2.x</a> provides.</p></li></ul></div><div class="sect1" title="State table synchronization"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="sync"></a>State table synchronization</h2></div></div></div><div class="sect2" title="Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="sync-requirements"></a>Requirements</h3></div></div></div><p>In order to get <span class="emphasis"><em>conntrackd</em></span> working in synchronization mode, you have to fulfill the following requirements:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>A <span class="emphasis"><em>high availability manager</em></span> like <a class="ulink" href="http://www.keepalived.org" target="_top">keepalived</a> that manages the virtual IPs of the
- firewall cluster, detects errors, and decide when to migrate the virtual IPs
- from one firewall replica to another. Without it, <span class="emphasis"><em>conntrackd</em></span> will not work appropriately.</p><p>The state synchronization setup requires a working installation of <a class="ulink" href="http://www.keepalived.org" target="_top">keepalived</a>, preferibly a recent version. Check if your distribution comes with a recent packaged version. Otherwise, you may compile it from the sources.
- </p><p>
- There is a very simple example file in the <span class="emphasis"><em>conntrackd</em></span>
- sources to setup a simple HA cluster with keepalived (see the file
- keepalived.conf under the doc/sync/ directory). This file can be used to
- set up a simple VRRP cluster composed of two machines that hold the virtual
- IPs 192.168.0.100 on eth0 and 192.168.1.100 on eth1.</p><p>If you are not familiar with <span class="emphasis"><em>keepalived</em></span>, please
- read the official documentation available at the keepalived website
- (<a class="ulink" href="http://www.keepalived.org" target="_top">http://www.keepalived.org</a>).</p><p>If you use a different high availability manager, make sure it works correctly before going ahead.</p></li><li class="listitem"><p>A dedicated link. The dedicated link between the firewalls is used
- to transmit and receive the state information. The use of a dedicated link
- is mandatory for security reasons as someone may pick the state information
- that is transfered between the firewalls.</p></li><li class="listitem"><p>A well-formed stateful rule-set. Otherwise you are likely to experience
- problems during the fail-over. An example of a well-formed stateful iptables
- rule-set is available in the <a class="ulink" href="http://conntrack-tools.netfilter.org/testcase.html" target="_top">conntrack-tools website</a>.</p></li><li class="listitem"><p>If your Linux kernel is < 2.6.22, you have to disable TCP window
- tracking:
- </p><pre class="programlisting">
- # echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
- </pre><p>
- </p></li></ol></div></div><div class="sect2" title="Configuring the daemon"><div class="titlepage"><div><div><h3 class="title"><a id="sync-configure"></a>Configuring the daemon</h3></div></div></div><p>The daemon <span class="emphasis"><em>conntrackd</em></span> in synchronization mode
- supports up to three replication approaches:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>notrack</em></span>: this approach is the most simple as
- it is based on a best effort replication protocol, ie. unreliable
- protocol. This protocol sends and receives the state information
- without performing any specific checking.
- </p></li><li class="listitem"><p><span class="emphasis"><em>ft-fw</em></span>: this approach is based on a reliable
- protocol that performs message tracking. Thus, the protocol can recover
- from message loss, re-ordering and corruption.</p></li><li class="listitem"><p><span class="emphasis"><em>alarm</em></span>: this approach is spamming. It is based
- on a alarm-based protocol that periodically re-sends the flow state to
- the backup firewall replicas. This protocol consumes a lot of bandwidth
- but it resolves synchronization problems fast.</p></li></ul></div><p>The three existing approaches are soft real-time asynchronous
- replication protocols that are aimed to have negligible impact in terms
- of latency and bandwidth throughput in the stateful firewall filtering.</p><p>To configure <span class="emphasis"><em>conntrackd</em></span> in any of the existing
- synchronization modes, you have to copy the example configuration file to
- the directory /etc/conntrackd/ on every firewall replica. Note that
- <span class="emphasis"><em>_type_</em></span> is the synchronization type selected.</p><pre class="programlisting">
- (conntrack-tools-x.x.x)# cp doc/_type_/conntrackd.conf /etc/conntrackd/conntrackd.conf
-</pre><p>
- Do not forget to edit the files before going ahead. There are several
- parameters that you have to tune to adapt the example configuration file
- to your setup.
-</p><div class="note" title="Configuration file location" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Configuration file location"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Configuration file location</th></tr><tr><td align="left" valign="top"><p>If you don't want to put the config file under /etc/conntrackd/, just tell conntrackd where to find it passing the option -C.</p></td></tr></table></div></div><div class="sect2" title="Active-Backup setup"><div class="titlepage"><div><div><h3 class="title"><a id="sync-pb"></a>Active-Backup setup</h3></div></div></div><div class="note" title="Stateful firewall architectures" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Stateful firewall architectures"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Stateful firewall architectures</th></tr><tr><td align="left" valign="top"><p>A good reading to extend the information about firewall architectures is <a class="ulink" href="http://1984.lsi.us.es/~pablo/docs/intcomp09.pdf" target="_top">Demystifying cluster-based fault-tolerant firewalls</a> published in IEEE Internet Computing magazine.
- </p></td></tr></table></div><p>In the Active-Backup setup, one of the stateful firewall replicas
- filters traffic and the other acts as backup. If you use this approach,
- you have to copy the script <span class="emphasis"><em>primary-backup.sh</em></span> to:
- </p><pre class="programlisting">
- (conntrack-tools-x.x.x)# cp doc/sync/primary-backup.sh /etc/conntrackd/
-</pre><p>The HA manager invokes this script when a transition happens, ie. If
- a stateful firewall replica:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>becomes active to recover the filtering.</p></li><li class="listitem"><p>becomes backup.</p></li><li class="listitem"><p>hits failure (this is available if the HA manager has a failure state, which is true for <a class="ulink" href="http://www.keepalived.org" target="_top">keepalived</a>.</p></li></ul></div><p>The script is simple, and it contains the different actions that
- <span class="emphasis"><em>conntrackd</em></span> performs to recover the filtering or
- purge obsolete entries from the state table, among others. The script is
- commented, you can have a look at it if you need further information.</p></div><div class="sect2" title="Active-Active setup"><div class="titlepage"><div><div><h3 class="title"><a id="sync-aa"></a>Active-Active setup</h3></div></div></div><p>The Active-Active setup consists of having more than one stateful
- firewall replicas actively filtering traffic. Thus, we reduce the resource
- waste that implies to have a backup firewall which does nothing.</p><p>We can classify the type of Active-Active setups in several
- families:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Symmetric path routing</em></span>: The stateful firewall
- replicas share the workload in terms of flows, ie. the packets that are
- part of a flow are always filtered by the same firewall.</p></li><li class="listitem"><p><span class="emphasis"><em>Asymmetric multi-path routing</em></span>: The packets that
- are part of a flow can be filtered by whatever stateful firewall in the
- cluster. Thus, every flow-states have to be propagated to all the firewalls
- in the cluster as we do not know which one would be the next to filter a
- packet. This setup goes against the design of stateful firewalls as we
- define the filtering policy based on flows, not in packets anymore.
- </p></li></ul></div><p>As for 0.9.8, the design of <span class="emphasis"><em>conntrackd</em></span> allows you
- to deploy an symmetric Active-Active setup based on a static approach.
- For example, assume that you have two virtual IPs, vIP1 and vIP2, and two
- firewall replicas, FW1 and FW2. You can give the virtual vIP1 to the
- firewall FW1 and the vIP2 to the FW2.
- </p><p>Unfortunately, you will have to wait for the support for the
- Active-Active setup based on dynamic approach, ie. a workload sharing setup
- without directors that allow the stateful firewall share the filtering.</p><p>On the other hand, the asymmetric scenario may work if your setup
- fulfills several strong assumptions. However, in the opinion of the author
- of this work, the asymmetric setup goes against the design of stateful
- firewalls and <span class="emphasis"><em>conntrackd</em></span>. Therefore, you have two
- choices here: you can deploy an Active-Backup setup or go back to your
- old stateless rule-set (in that case, the conntrack-tools will not be
- of any help anymore, of course).</p></div><div class="sect2" title="Launching conntrackd"><div class="titlepage"><div><div><h3 class="title"><a id="sync-launch"></a>Launching conntrackd</h3></div></div></div><p>
- Once you have configured <span class="emphasis"><em>conntrackd</em></span>, you can run in
- <span class="emphasis"><em>console mode</em></span> which is an interactive mode, in that case
- type 'conntrackd' as root.</p><pre class="programlisting">(root)# conntrackd</pre><p>If you want to run <span class="emphasis"><em>conntrackd</em></span> in <span class="emphasis"><em>daemon
- mode</em></span>, then type:</p><pre class="programlisting">(root)# conntrackd -d</pre><p>You can verify that conntrackd is running by checking the log messages
- via <span class="emphasis"><em>ps</em></span>. Moreover, if <span class="emphasis"><em>conntrackd</em></span> is
- running fine, you can dump the current status of the daemon:</p><pre class="programlisting">
- # conntrackd -s
- cache internal:
- current active connections: 4
- connections created: 4 failed: 0
- connections updated: 0 failed: 0
- connections destroyed: 0 failed: 0
-
- cache external:
- current active connections: 0
- connections created: 0 failed: 0
- connections updated: 0 failed: 0
- connections destroyed: 0 failed: 0
-
- traffic processed:
- 0 Bytes 0 Pckts
-
- multicast traffic:
- 352 Bytes sent 0 Bytes recv
- 22 Pckts sent 0 Pckts recv
- 0 Error send 0 Error recv
-
- multicast sequence tracking:
- 0 Pckts mfrm 0 Pckts lost
- </pre><p>This command displays the number of entries in the internal and
- external cache:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>The internal cache contains the states that this firewall replica is filtering, ie. this is a cache of the kernel state table.
- </p></li><li class="listitem"><p>The external cache contains the states that the other firewall replica is filtering.
- </p></li></ul></div><p>You can dump the internal cache with the following command:</p><pre class="programlisting">
- # conntrackd -i
- tcp 6 ESTABLISHED src=192.168.2.100 dst=139.174.175.20 sport=58491 dport=993 src=139.174.175.20 dst=192.168.2.100 sport=993 dport=58491 [ASSURED] mark=0 secmark=0 [active since 536s]
- tcp 6 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=38211 dport=993 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=38211 [ASSURED] mark=0 secmark=0 [active since 536s]
- tcp 6 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=38209 dport=993 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=38209 [ASSURED] mark=0 secmark=0 [active since 536s]
- tcp 6 TIME_WAIT src=192.168.2.100 dst=74.125.45.166 sport=42593 dport=80 src=74.125.45.166 dst=192.168.2.100 sport=80 dport=42593 [ASSURED] [active since 165s]
- tcp 6 ESTABLISHED src=192.168.2.100 dst=139.174.175.20 sport=37962 dport=993 src=139.174.175.20 dst=192.168.2.100 sport=993 dport=37962 [ASSURED] mark=0 secmark=0 [active since 536s]
- </pre><p>You can dump the external cache with the following command:</p><pre class="programlisting"># conntrackd -e</pre><p>If the replication works fine, <span class="emphasis"><em>conntrackd -s</em></span>
- displays the active's internal cache should display the same number of
- entries than the backup's external cache and vice-versa.</p><p>To verify that the recovery works fine, if you trigger a fail-over,
- the log files should display the following information:</p><pre class="programlisting">
- [Thu Sep 18 18:03:02 2008] (pid=9759) [notice] committing external cache
- [Thu Sep 18 18:03:02 2008] (pid=9759) [notice] Committed 1545 new entries</pre><p>This means that the state entries have been injected into the kernel correctly.</p></div><div class="sect2" title="Other configuration options"><div class="titlepage"><div><div><h3 class="title"><a id="sync-options"></a>Other configuration options</h3></div></div></div><p>The daemon allows several configuration options that you may want to
- enable. This section contains some information about them.</p><div class="sect3" title="Disabling external cache"><div class="titlepage"><div><div><h4 class="title"><a id="sync-disable-external"></a>Disabling external cache</h4></div></div></div><p>It is possible to disable the external cache. Thus,
- <span class="emphasis"><em>conntrackd</em></span> directly injects the flow-states into the
- in-kernel Connection Tracking System of the backup firewall. You can do it
- by enabling the <span class="emphasis"><em>DisableExternalCache</em></span> option in the
- <span class="emphasis"><em>conntrackd.conf</em></span> configuration file:
- </p><pre class="programlisting">
-Sync {
- Mode FTFW {
- [...]
- DisableExternalCache Off
- }
-}
- </pre><p>You can also use this option with the NOTRACK and ALARM modes. This
- increases CPU consumption in the backup firewall but now you do not need
- to commit the flow-states during the master failures since they are already
- in the in-kernel Connection Tracking table. Moreover, you save memory in
- the backup firewall since you do not need to store the foreign flow-states
- anymore.
- </p></div><div class="sect3" title="Disabling internal cache"><div class="titlepage"><div><div><h4 class="title"><a id="sync-disable-internal"></a>Disabling internal cache</h4></div></div></div><p>You can also disable the internal cache by means of the
- <span class="emphasis"><em>DisableInternalCache</em></span> option in the
- <span class="emphasis"><em>conntrackd.conf</em></span> configuration file:
- </p><pre class="programlisting">
-Sync {
- Mode NOTRACK {
- [...]
- DisableInternalCache Off
- }
-}
- </pre><p>However, this option is only available for the NOTRACK mode. This
- mode provides unreliable flow-state synchronization between firewalls.
- Thus, if flow-states are lost during the synchronization, the protocol
- provides no way to recover them.</p></div><div class="sect3" title="Using UDP, TCP or multicast for flow-state synchronization"><div class="titlepage"><div><div><h4 class="title"><a id="sync-transport-protocol"></a>Using UDP, TCP or multicast for flow-state synchronization</h4></div></div></div><p>You can use up to three different transport layer protocols to
- synchronize flow-state changes between the firewalls: UDP, TCP and
- Multicast. UDP and multicast are unreliable but together with the FT-FW
- mode provide partial reliable flow-state synchronization.
- </p><p>The preferred choice is FT-FW over UDP, or multicast alternatively.
- TCP introduces latency in the flow-state synchronization due to the
- congestion control. Under flow-state message are lost, the FIFO delivery
- becomes also a problem since the backup firewall quickly gets out of
- sync. For that reason, its use is discouraged. Note that using TCP only
- makes sense with the NOTRACK mode.
- </p></div><div class="sect3" title="Redundant dedicated links"><div class="titlepage"><div><div><h4 class="title"><a id="sync-redundant-link"></a>Redundant dedicated links</h4></div></div></div><p>You can set redundant dedicated links without using bonding, you have
- to configure as many redundant links as you want in the configuration file.
- In case of failure of the master dedicated link, conntrackd failovers to one
- of the backups. An example of this configuration is the following:
- </p><pre class="programlisting">
-Sync {
- Mode FTFW {
- [...]
- }
- # default master dedicated link
- UDP Default {
- IPv4_address 192.168.2.1
- IPv4_Destination_Address 192.168.2.2
- Port 3780
- Interface eth3
- SndSocketBuffer 24985600
- RcvSocketBuffer 24985600
- Checksum on
- }
- # backup dedicated link
- UDP {
- IPv4_address 192.168.1.3
- IPv4_Destination_Address 192.168.1.4
- Port 3780
- Interface eth2
- SndSocketBuffer 24985600
- RcvSocketBuffer 24985600
- Checksum on
- }
- [...]
-}
- </pre></div><div class="sect3" title="Filtering Connection tracking events with iptables"><div class="titlepage"><div><div><h4 class="title"><a id="sync-iptables-filtering"></a>Filtering Connection tracking events with iptables</h4></div></div></div><p>Since Linux kernel >= 2.6.34, iptables provides the
- <span class="emphasis"><em>CT</em></span> iptables target that allows to reduce the
- amount of Connection Tracking events that are delivered to user-space.
- However, you will have to use a Linux kernel >= 2.6.38 to profit
- from this feature, since several aspects of the event filtering were
- broken.</p><p>The following example shows how to only generate the
- <span class="emphasis"><em>assured</em></span> and <span class="emphasis"><em>destroy</em></span>
- events:</p><pre class="programlisting">
- # iptables -I PREROUTING -t raw -j CT --ctevents assured,destroy
- </pre><div class="note" title="Assured flows" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Assured flows"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Assured flows</th></tr><tr><td align="left" valign="top"><p>One flow is assured if the firewall has seen traffic for it in
- both directions.</p></td></tr></table></div><p>Reducing the amount of events generated helps to reduce CPU
- consumption in the active firewall.</p></div><div class="sect3" title="Synchronization of expectations"><div class="titlepage"><div><div><h4 class="title"><a id="sync-expect"></a>Synchronization of expectations</h4></div></div></div><div class="note" title="Check your Linux kernel version first" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Check your Linux kernel version first"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Check your Linux kernel version first</th></tr><tr><td align="left" valign="top"><p>
- The synchronization of expectations require a Linux kernel >= 3.5
- to work appropriately.
- </p></td></tr></table></div><p>The connection tracking system provides helpers that allows you to
- filter multi-flow application protocols like FTP, H.323 and SIP among many
- others. These protocols usually split the control and data traffic in
- different flows. Moreover, the control flow usually announces layer 3 and
- 4 information to let the other peer know where the data flows will be
- open. This sort of protocols require that the firewall inspects the
- content of the packet, otherwise filtering by layer 3 and 4 selectors
- like addresses and ports become a real nightmare. Netfilter already
- provides the so-called <span class="emphasis"><em>helpers</em></span> that track this
- protocol aspects to allow deploying appropriate filtering. These
- helpers create <span class="emphasis"><em>expectation</em></span> entries that
- represent expected traffic that will arrive to the firewall according
- to the inspected packets.</p><p>In case that you have enabled tracking of these protocols, you
- may want to enable the state-synchronization of expectation as well.
- Thus, established flows for this specific protocols will not suffer
- any disruption.</p><p>To enable the expectation support in the configuration file, you
- have to use the following option:</p><pre class="programlisting">
-Sync {
- ...
- Options {
- ExpectationSync {
- ftp
- sip
- ras # for H.323
- q.931 # for H.323
- h.245 # for H.323
- }
- }
-}</pre><p>The example above enables the synchronization of the expectations
- for the FTP, SIP and H.323 helpers.</p><p>In my testbed, there are two firewalls in a primary-backup
- configuration running keepalived. They use a couple of floating cluster
- IP address (192.168.0.100 and 192.168.1.100) that are used by the client.
- These firewalls protect one FTP server (192.168.1.2) that will be accessed
- by one client.</p><p>In ASCII art, it looks like this:</p><pre class="programlisting">
- 192.168.0.100 192.168.1.100
- eth1 eth2
- fw-1
- / \ FTP
- client ------ ------ server
- 192.168.0.2 \ / 192.168.1.2
- fw-2
- </pre><p>This is the rule-set for the firewalls:</p><pre class="programlisting">
- -A FORWARD -m state --state RELATED -j ACCEPT
- -A FORWARD -i eth2 -m state --state ESTABLISHED -j ACCEPT
- -A FORWARD -i eth1 -p tcp -m tcp --dport 21 --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j ACCEPT
- -A FORWARD -i eth1 -p tcp -m state --state ESTABLISHED -j ACCEPT
- -A FORWARD -m state --state INVALID -j LOG --log-prefix "invalid: "</pre><p>Before going ahead, make sure <span class="emphasis"><em>nf_conntrack_ftp</em></span> is
- loaded.</p><p>The following steps detail how to check that the expectation support
- works fine with FTP traffic:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Switch to the client. Start one FTP control connection to one
- server that is protected by the firewalls, enter passive mode:</p><pre class="programlisting">
- (term-1) user@client$ nc 192.168.1.2 21
- 220 dummy FTP server
- USER anonymous
- 331 Please specify the password.
- PASS nothing
- 230 Login successful.
- PASV
- 227 Entering Passive Mode (192,168,1,2,163,11).</pre><p>This means that port 163*256+11=41739 will be used for the data
- traffic. I suggest you to read <a class="ulink" href="http://www.freefire.org/articles/ftpexample.php" target="_top">djb's FTP protocol description</a> in case that you
- don't understand how this calculation is done.</p></li><li class="listitem"><p> Switch to fw-1 (primary) to check that the expectation is in the
- internal cache.</p><pre class="programlisting">
- root@fw1# conntrackd -i exp
- proto=6 src=192.168.0.2 dst=192.168.1.2 sport=0 dport=41739 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.0.2 master-dst=192.168.1.2 sport=36390 dport=21 helper=ftp [active since 5s]
- </pre></li><li class="listitem"><p> Switch to fw-2 (backup) to check that the expectation has been
- successfully replicated.</p><pre class="programlisting">
- root@fw2# conntrackd -e exp
- proto=6 src=192.168.0.2 dst=192.168.1.2 sport=0 dport=41739 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.0.2 master-dst=192.168.1.2 sport=36390 dport=21 [active since 8s]
- </pre></li><li class="listitem"><p>Make the primary firewall fw-1 fail. Now fw-2 becomes primary.</p></li><li class="listitem"><p>Switch to fw-2 (primary) to commit the external cache into the
- kernel. The logs should display that the commit was successful:</p><pre class="programlisting">
- root@fw2# tail -100f /var/log/conntrackd.log
- [Wed Dec 7 22:16:31 2011] (pid=19195) [notice] committing external cache: expectations
- [Wed Dec 7 22:16:31 2011] (pid=19195) [notice] Committed 1 new entries
- [Wed Dec 7 22:16:31 2011] (pid=19195) [notice] commit has taken 0.000366 seconds</pre></li><li class="listitem"><p> Switch to the client. Open a new terminal and connect to the port that
- has been announced by the server:</p><pre class="programlisting">
- (term-2) user@client$ nc -vvv 192.168.1.2 41739
- (UNKNOWN) [192.168.1.2] 41739 (?) open</pre></li><li class="listitem"><p>Switch to term-1 and ask for the file listing:</p><pre class="programlisting">
- [...]
- 227 Entering Passive Mode (192,168,1,2,163,11).
- LIST</pre></li><li class="listitem"><p>Switch to term-2, it should display the listing. That means
- everything has worked fine.</p></li></ol></div><p>You may want to try disabling the expectation support and
- repeating the steps to check that <span class="emphasis"><em>it does not work</em></span>
- without the state-synchronization.</p></div></div></div><div class="sect1" title="User-space helpers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="helpers"></a>User-space helpers</h2></div></div></div><div class="note" title="Check your Linux kernel version first" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: Check your Linux kernel version first"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Check your Linux kernel version first</th></tr><tr><td align="left" valign="top"><p>
- The user-space helper infrastructure requires a Linux kernel >= 3.6
- to work appropriately.
- </p></td></tr></table></div><p>Connection tracking helpers allows you to filter multi-flow protocols
-that usually separate control and data traffic into different flows.
-These protocols usually violate network layering by including layer 3/4
-details, eg. IP address and TCP/UDP ports, in their application protocol
-(which resides in layer 7). This is problematic for gateways since they
-operate at packet-level, ie. layers 3/4, and therefore they miss this
-important information to filter these protocols appropriately.</p><p>Helpers inspect packet content (at layer 7) and create the so-called
-expectations. These expectations are added to one internal table
-that resides in the gateway. For each new packet arriving to the
-gateway, the gateway first looks up for matching expectations. If
-there is any, then this flow is accepted since it's been expected.
-Note this lookup only occurs for the first packet that is part of one
-newly established flow, not for all packets.</p><p>Since 1.4.0, conntrackd provides the infrastructure to develop
-helpers in user-space. The main features of the user-space infrastructure
-for helpers are:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Rapid connection tracking helper development, as developing code
-in user-space is usually faster.</p></li><li class="listitem"><p>Reliability: A buggy helper does not crash the kernel. If the helper
-fails, ie. the conntrackd crashes, Moreover, we can monitor the helper process
-and restart it in case of problems.</p></li><li class="listitem"><p>Security: Avoid complex string matching and mangling in
-kernel-space running in privileged mode. Going further, we can even think
-about running user-space helper as a non-root process.</p></li><li class="listitem"><p>It allows the development of very specific helpers for
-proprietary protocols that are not standard. This is the case of the SQL*net
-helper. Implementing this in kernel-space may be problematic, since
-this may not be accepted for ainline inclusion in the Linux kernel.
-As an alternative, we can still distribute this support as separate
-patches. However, my personal experience is that, given that the
-kernel API/ABI is not stable, changes in the interface lead to the
-breakage of the patch. This highly increase the overhead in the
-maintainance.</p></li></ul></div><p>Currently, the infrastructure supports the following user-space helpers:
-</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Oracle*TNS, to support its special <span class="emphasis"><em>Redirect</em></span> message.</p></li><li class="listitem"><p>NFSv3, mind that version 4 does not require this helper.</p></li><li class="listitem"><p>FTP (this helper is also available in kernel-space).</p></li></ul></div><p>The following steps describe how to enable the RPC portmapper helper for NFSv3 (this is similar for other helpers):</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Register user-space helper:
-
-</p><pre class="programlisting">
-nfct helper add rpc inet udp
-nfct helper add rpc inet tcp
-</pre><p>
-
-This registers the portmapper helper for both UDP and TCP (NFSv3 traffic goes both over TCP and UDP).
-</p></li><li class="listitem"><p>Add iptables rule using the CT target:
-
-</p><pre class="programlisting">
-# iptables -I OUTPUT -t raw -p udp --dport 111 -j CT --helper rpc
-# iptables -I OUTPUT -t raw -p tcp --dport 111 -j CT --helper rpc
-</pre><p>
-
-With this, packets matching port TCP/UDP/111 are passed to user-space for
-inspection. If there is no instance of conntrackd configured to support
-user-space helpers, no inspection happens and packets are not sent to
-user-space.</p></li><li class="listitem"><p>Add configuration to conntrackd.conf:
-
-</p><pre class="programlisting">
-Helper {
- Type rpc inet udp {
- QueueNum 1
- QueueLen 10240
- Policy rpc {
- ExpectMax 1
- ExpectTimeout 300
- }
- }
- Type rpc inet tcp {
- QueueNum 2
- QueueLen 10240
- Policy rpc {
- ExpectMax 1
- ExpectTimeout 300
- }
- }
-}
-</pre><p>
-
-This configures conntrackd to use NFQUEUE queue numbers 1 and 2 to send traffic
-for inspection to user-space</p><div class="note" title="If you have some custom libnetfilter_queue application" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note: If you have some custom libnetfilter_queue application"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">If you have some custom libnetfilter_queue application</th></tr><tr><td align="left" valign="top"><p>
- Make sure your queue numbers do not collide with those used in your
- conntrackd.conf file.
- </p></td></tr></table></div></li></ol></div><p>Now you can test this (assuming you have some working NFSv3 setup) with:
-
-</p><pre class="programlisting">
-mount -t nfs -onfsvers=3 mynfs.server.info:/srv/cvs /mnt/
-</pre><p>
-
-</p><p>You should see new expectations being added via:
-
-</p><pre class="programlisting">
-# conntrack -E expect
- [NEW] 300 proto=17 src=1.2.3.4 dst=1.2.3.4 sport=0 dport=54834 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=1.2.3.4 master-dst=1.2.3.4 sport=58190 dport=111 PERMANENT class=0 helper=rpc
- [NEW] 300 proto=6 src=1.2.3.4 dst=1.2.3.4 sport=0 dport=2049 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=1.2.3.4 master-dst=1.2.3.4 sport=55450 dport=111 PERMANENT class=0 helper=rpc
- [NEW] 300 proto=17 src=1.2.3.4 dst=1.2.3.4 sport=0 dport=58031 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=1.2.3.4 master-dst=1.2.3.4 sport=56309 dport=111 PERMANENT class=0 helper=rpc
-</pre><p>
-</p></div><div class="sect1" title="Troubleshooting"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="sync-trouble"></a>Troubleshooting</h2></div></div></div><p>Problems with <span class="emphasis"><em>conntrackd</em></span>? The following list
- of questions should help for troubleshooting:</p><div class="qandaset" title="Frequently Asked Questions"><a id="idp5407120"></a><dl><dt>1. <a href="#idp5407376">
- I see packets lost in conntrackd -s
- </a></dt><dt>2. <a href="#idp5410960">
- The log messages report that the maximum netlink socket buffer has been reached.
- </a></dt><dt>3. <a href="#idp5414032">
- I see can't open multicast server in the log messages
- </a></dt><dt>4. <a href="#idp5416720">
- Can I use wackamole, heartattack or any other HA manager?
- </a></dt><dt>5. <a href="#idp5419408">
- Does conntrackd support TCP flow-recovery with window tracking enabled?
- </a></dt><dt>6. <a href="#idp5421808">
- Does conntrackd support the H.323 and SIP connection tracking helpers?
- </a></dt><dt>7. <a href="#idp5423920">
- Is there any way to set up a more verbose mode in the log message for debugging?
- </a></dt></dl><table border="0" width="100%" summary="Q and A Set"><col align="left" width="1%" /><col /><tbody><tr class="question" title="1."><td align="left" valign="top"><a id="idp5407376"></a><a id="idp5407632"></a><p><strong>1.</strong></p></td><td align="left" valign="top"><p>
- I see <span class="emphasis"><em>packets lost</em></span> in <span class="emphasis"><em>conntrackd -s</em></span>
- </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
- You can rise the value of <span class="emphasis"><em>McastRcvSocketBuffer</em></span> and <span class="emphasis"><em>McastRcvSocketBuffer</em></span>, if the problem is due to buffer overruns in the multicast sender or the receiver, the problem should disapear.
- </p></td></tr><tr class="question" title="2."><td align="left" valign="top"><a id="idp5410960"></a><a id="idp5411216"></a><p><strong>2.</strong></p></td><td align="left" valign="top"><p>
- The log messages report that the <span class="emphasis"><em>maximum netlink socket buffer has been reached</em></span>.
- </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
- You can increase the values of <span class="emphasis"><em>SocketBufferSize</em></span> and <span class="emphasis"><em>SocketBufferSizeMaxGrown</em></span>.
- </p></td></tr><tr class="question" title="3."><td align="left" valign="top"><a id="idp5414032"></a><a id="idp5414288"></a><p><strong>3.</strong></p></td><td align="left" valign="top"><p>
- I see <span class="emphasis"><em>can't open multicast server</em></span> in the log messages
- </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
- Make sure that the <span class="emphasis"><em>IPv4_interface</em></span> clause has the IP of the dedicated link.
- </p></td></tr><tr class="question" title="4."><td align="left" valign="top"><a id="idp5416720"></a><a id="idp5416976"></a><p><strong>4.</strong></p></td><td align="left" valign="top"><p>
- Can I use <a class="ulink" href="http://www.backhand.org/wackamole/" target="_top">wackamole</a>, heartattack or any other HA manager?
- </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
- Absolutely, you can. But before reporting issues, make sure that your HA manager is not the source of the problems.
- </p></td></tr><tr class="question" title="5."><td align="left" valign="top"><a id="idp5419408"></a><a id="idp5419664"></a><p><strong>5.</strong></p></td><td align="left" valign="top"><p>
- Does conntrackd support TCP flow-recovery with window tracking enabled?
- </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
- Yes, but you require a Linux kernel >= 2.6.36 and the conntrack-tools >= 0.9.15. To enable it, check the TCPWindowTracking clause in the example configuration files.
- </p></td></tr><tr class="question" title="6."><td align="left" valign="top"><a id="idp5421808"></a><a id="idp5422064"></a><p><strong>6.</strong></p></td><td align="left" valign="top"><p>
- Does conntrackd support the H.323 and SIP connection tracking helpers?
- </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
- Yes, conntrackd includes expectation support since version 1.2.0.
- </p></td></tr><tr class="question" title="7."><td align="left" valign="top"><a id="idp5423920"></a><a id="idp5424176"></a><p><strong>7.</strong></p></td><td align="left" valign="top"><p>
- Is there any way to set up a more verbose mode in the log message for debugging?
- </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p>
- No, but conntrackd provides lots of information that you can look up in
- runtime via -s option.</p><p>You can check network statistics to find anomalies:</p><pre class="programlisting">
-# conntrackd -s network
- network statistics:
- recv:
- Malformed messages: 0
- Wrong protocol version: 0
- Malformed header: 0
- Malformed payload: 0
- Bad message type: 0
- Truncated message: 0
- Bad message size: 0
- send:
- Malformed messages: 0
-
-sequence tracking statistics:
- recv:
- Packets lost: 42726
- Packets before: 0
-
-UDP traffic (active device=eth3):
- 564232 Bytes sent 1979844 Bytes recv
- 2844 Pckts sent 8029 Pckts recv
- 0 Error send 0 Error recv
- </pre><p>You can check cache statistics:</p><pre class="programlisting">
-# conntrackd -s cache
-cache:internal active objects: 0
- active/total entries: 0/ 0
- creation OK/failed: 11068/ 0
- no memory available: 0
- no space left in cache: 0
- update OK/failed: 4128/ 0
- entry not found: 0
- deletion created/failed: 11068/ 0
- entry not found: 0
-
-cache:external active objects: 0
- active/total entries: 0/ 0
- creation OK/failed: 10521/ 0
- no memory available: 0
- no space left in cache: 0
- update OK/failed: 8832/ 0
- entry not found: 0
- deletion created/failed: 10521/ 0
- entry not found: 0
- </pre><p>You can check runtime miscelaneous statistics:</p><pre class="programlisting">
-# conntrackd -s runtime
-daemon uptime: 14 min
-
-netlink stats:
- events received: 24736
- events filtered: 0
- events unknown type: 0
- catch event failed: 0
- dump unknown type: 0
- netlink overrun: 0
- flush kernel table: 1
- resync with kernel table: 0
- current buffer size (in bytes): 8000000
-
-runtime stats:
- child process failed: 0
- child process segfault: 0
- child process termsig: 0
- select failed: 0
- wait failed: 0
- local read failed: 0
- local unknown request: 0
- </pre><p>You can check dedicated link statistics:</p><pre class="programlisting">
-# conntrackd -s link
-UDP traffic device=eth3 status=RUNNING role=ACTIVE:
- 566848 Bytes sent 1982612 Bytes recv
- 3018 Pckts sent 8203 Pckts recv
- 0 Error send 0 Error recv
- </pre><p>You can check network queue statistics:</p><pre class="programlisting">
-# conntrackd -s queue
-allocated queue nodes: 1
-
-queue txqueue:
-current elements: 0
-maximum elements: 2147483647
-not enough space errors: 0
-
-queue errorq:
-current elements: 0
-maximum elements: 128
-not enough space errors: 0
-
-queue rsqueue:
-current elements: 1
-maximum elements: 131072
-not enough space errors: 0
- </pre></td></tr></tbody></table></div></div></div></div></body></html>
|
|
[-]
[+]
|
Deleted |
conntrack-tools-1.4.0.tar.bz2/doc/sync/alarm/conntrackd.conf.orig
^
|
| @@ -1,404 +0,0 @@
-#
-# Synchronizer settings
-#
-Sync {
- Mode ALARM {
- #
- # If a conntrack entry is not modified in <= 15 seconds, then
- # a message is broadcasted. This mechanism is used to
- # resynchronize nodes that just joined the multicast group
- #
- RefreshTime 15
-
- #
- # If we don't receive a notification about the state of
- # an entry in the external cache after N seconds, then
- # remove it.
- #
- CacheTimeout 180
-
- #
- # This parameter allows you to set an initial fixed timeout
- # for the committed entries when this node goes from backup
- # to primary. This mechanism provides a way to purge entries
- # that were not recovered appropriately after the specified
- # fixed timeout. If you set a low value, TCP entries in
- # Established states with no traffic may hang. For example,
- # an SSH connection without KeepAlive enabled. If not set,
- # the daemon uses an approximate timeout value calculation
- # mechanism. By default, this option is not set.
- #
- # CommitTimeout 180
-
- #
- # If the firewall replica goes from primary to backup,
- # the conntrackd -t command is invoked in the script.
- # This command schedules a flush of the table in N seconds.
- # This is useful to purge the connection tracking table of
- # zombie entries and avoid clashes with old entries if you
- # trigger several consecutive hand-overs. Default is 60 seconds
- #
- # PurgeTimeout 60
- }
-
- #
- # Multicast IP and interface where messages are
- # broadcasted (dedicated link). IMPORTANT: Make sure
- # that iptables accepts traffic for destination
- # 225.0.0.50, eg:
- #
- # iptables -I INPUT -d 225.0.0.50 -j ACCEPT
- # iptables -I OUTPUT -d 225.0.0.50 -j ACCEPT
- #
- Multicast {
- #
- # Multicast address: The address that you use as destination
- # in the synchronization messages. You do not have to add
- # this IP to any of your existing interfaces. If any doubt,
- # do not modify this value.
- #
- IPv4_address 225.0.0.50
-
- #
- # The multicast group that identifies the cluster. If any
- # doubt, do not modify this value.
- #
- Group 3780
-
- #
- # IP address of the interface that you are going to use to
- # send the synchronization messages. Remember that you must
- # use a dedicated link for the synchronization messages.
- #
- IPv4_interface 192.168.100.100
-
- #
- # The name of the interface that you are going to use to
- # send the synchronization messages.
- #
- Interface eth2
-
- # The multicast sender uses a buffer to enqueue the packets
- # that are going to be transmitted. The default size of this
- # socket buffer is available at /proc/sys/net/core/wmem_default.
- # This value determines the chances to have an overrun in the
- # sender queue. The overrun results packet loss, thus, losing
- # state information that would have to be retransmitted. If you
- # notice some packet loss, you may want to increase the size
- # of the sender buffer. The default size is usually around
- # ~100 KBytes which is fairly small for busy firewalls.
- #
- SndSocketBuffer 1249280
-
- # The multicast receiver uses a buffer to enqueue the packets
- # that the socket is pending to handle. The default size of this
- # socket buffer is available at /proc/sys/net/core/rmem_default.
- # This value determines the chances to have an overrun in the
- # receiver queue. The overrun results packet loss, thus, losing
- # state information that would have to be retransmitted. If you
- # notice some packet loss, you may want to increase the size of
- # the receiver buffer. The default size is usually around
- # ~100 KBytes which is fairly small for busy firewalls.
- #
- RcvSocketBuffer 1249280
-
- #
- # Enable/Disable message checksumming. This is a good
- # property to achieve fault-tolerance. In case of doubt, do
- # not modify this value.
- #
- Checksum on
- }
- #
- # You can specify more than one dedicated link. Thus, if one dedicated
- # link fails, conntrackd can fail-over to another. Note that adding
- # more than one dedicated link does not mean that state-updates will
- # be sent to all of them. There is only one active dedicated link at
- # a given moment. The `Default' keyword indicates that this interface
- # will be selected as the initial dedicated link. You can have
- # up to 4 redundant dedicated links. Note: Use different multicast
- # groups for every redundant link.
- #
- # Multicast Default {
- # IPv4_address 225.0.0.51
- # Group 3781
- # IPv4_interface 192.168.100.101
- # Interface eth3
- # # SndSocketBuffer 1249280
- # # RcvSocketBuffer 1249280
- # Checksum on
- # }
-
- #
- # You can use Unicast UDP instead of Multicast to propagate events.
- # Note that you cannot use unicast UDP and Multicast at the same
- # time, you can only select one.
- #
- # UDP {
- #
- # UDP address that this firewall uses to listen to events.
- #
- # IPv4_address 192.168.2.100
- #
- # or you may want to use an IPv6 address:
- #
- # IPv6_address fe80::215:58ff:fe28:5a27
-
- #
- # Destination UDP address that receives events, ie. the other
- # firewall's dedicated link address.
- #
- # IPv4_Destination_Address 192.168.2.101
- #
- # or you may want to use an IPv6 address:
- #
- # IPv6_Destination_Address fe80::2d0:59ff:fe2a:775c
-
- #
- # UDP port used
- #
- # Port 3780
-
- #
- # The name of the interface that you are going to use to
- # send the synchronization messages.
- #
- # Interface eth2
-
- #
- # The sender socket buffer size
- #
- # SndSocketBuffer 1249280
-
- #
- # The receiver socket buffer size
- #
- # RcvSocketBuffer 1249280
-
- #
- # Enable/Disable message checksumming.
- #
- # Checksum on
- # }
-
- #
- # Other unsorted options that are related to the synchronization.
- #
- # Options {
- #
- # TCP state-entries have window tracking disabled by default,
- # you can enable it with this option. As said, default is off.
- # This feature requires a Linux kernel >= 2.6.36.
- #
- # TCPWindowTracking Off
-
- # Set this option on if you want to enable the synchronization
- # of expectations. You have to specify the list of helpers that
- # you want to enable. Default is off.
- #
- # ExpectationSync {
- # ftp
- # ras
- # q.931
- # h.245
- # sip
- # }
- #
- # You can use this alternatively:
- #
- # ExpectationSync On
- #
- # If you want to synchronize expectations of all helpers.
- # }
-}
-
-#
-# General settings
-#
-General {
- #
- # Set the nice value of the daemon, this value goes from -20
- # (most favorable scheduling) to 19 (least favorable). Using a
- # very low value reduces the chances to lose state-change events.
- # Default is 0 but this example file sets it to most favourable
- # scheduling as this is generally a good idea. See man nice(1) for
- # more information.
- #
- Nice -20
-
- #
- # Select a different scheduler for the daemon, you can select between
- # RR and FIFO and the process priority (minimum is 0, maximum is 99).
- # See man sched_setscheduler(2) for more information. Using a RT
- # scheduler reduces the chances to overrun the Netlink buffer.
- #
- # Scheduler {
- # Type FIFO
- # Priority 99
- # }
-
- #
- # Number of buckets in the cache hashtable. The bigger it is,
- # the closer it gets to O(1) at the cost of consuming more memory.
- # Read some documents about tuning hashtables for further reference.
- #
- HashSize 32768
-
- #
- # Maximum number of conntracks, it should be double of:
- # $ cat /proc/sys/net/netfilter/nf_conntrack_max
- # since the daemon may keep some dead entries cached for possible
- # retransmission during state synchronization.
- #
- HashLimit 131072
-
- #
- # Logfile: on (/var/log/conntrackd.log), off, or a filename
- # Default: off
- #
- LogFile on
-
- #
- # Syslog: on, off or a facility name (daemon (default) or local0..7)
- # Default: off
- #
- #Syslog on
-
- #
- # Lockfile
- #
- LockFile /var/lock/conntrack.lock
-
- #
- # Unix socket configuration
- #
- UNIX {
- Path /var/run/conntrackd.ctl
- Backlog 20
- }
-
- #
- # Netlink event socket buffer size. If you do not specify this clause,
- # the default buffer size value in /proc/net/core/rmem_default is
- # used. This default value is usually around 100 Kbytes which is
- # fairly small for busy firewalls. This leads to event message dropping
- # and high CPU consumption. This example configuration file sets the
- # size to 2 MBytes to avoid this sort of problems.
- #
- NetlinkBufferSize 2097152
-
- #
- # The daemon doubles the size of the netlink event socket buffer size
- # if it detects netlink event message dropping. This clause sets the
- # maximum buffer size growth that can be reached. This example file
- # sets the size to 8 MBytes.
- #
- NetlinkBufferSizeMaxGrowth 8388608
-
- #
- # If the daemon detects that Netlink is dropping state-change events,
- # it automatically schedules a resynchronization against the Kernel
- # after 30 seconds (default value). Resynchronizations are expensive
- # in terms of CPU consumption since the daemon has to get the full
- # kernel state-table and purge state-entries that do not exist anymore.
- # Be careful of setting a very small value here. You have the following
- # choices: On (enabled, use default 30 seconds value), Off (disabled)
- # or Value (in seconds, to set a specific amount of time). If not
- # specified, the daemon assumes that this option is enabled.
- #
- # NetlinkOverrunResync On
-
- # If you want reliable event reporting over Netlink, set on this
- # option. If you set on this clause, it is a good idea to set off
- # NetlinkOverrunResync. This option is off by default and you need
- # a Linux kernel >= 2.6.31.
- #
- # NetlinkEventsReliable Off
-
- #
- # By default, the daemon receives state updates following an
- # event-driven model. You can modify this behaviour by switching to
- # polling mode with the PollSecs clause. This clause tells conntrackd
- # to dump the states in the kernel every N seconds. With regards to
- # synchronization mode, the polling mode can only guarantee that
- # long-lifetime states are recovered. The main advantage of this method
- # is the reduction in the state replication at the cost of reducing the
- # chances of recovering connections.
- #
- # PollSecs 15
-
- #
- # The daemon prioritizes the handling of state-change events coming
- # from the core. With this clause, you can set the maximum number of
- # state-change events (those coming from kernel-space) that the daemon
- # will handle after which it will handle other events coming from the
- # network or userspace. A low value improves interactivity (in terms of
- # real-time behaviour) at the cost of extra CPU consumption.
- # Default (if not set) is 100.
- #
- # EventIterationLimit 100
-
- #
- # Event filtering: This clause allows you to filter certain traffic,
- # There are currently three filter-sets: Protocol, Address and
- # State. The filter is attached to an action that can be: Accept or
- # Ignore. Thus, you can define the event filtering policy of the
- # filter-sets in positive or negative logic depending on your needs.
- # You can select if conntrackd filters the event messages from
- # user-space or kernel-space. The kernel-space event filtering
- # saves some CPU cycles by avoiding the copy of the event message
- # from kernel-space to user-space. The kernel-space event filtering
- # is prefered, however, you require a Linux kernel >= 2.6.29 to
- # filter from kernel-space. If you want to select kernel-space
- # event filtering, use the keyword 'Kernelspace' instead of
- # 'Userspace'.
- #
- Filter From Userspace {
- #
- # Accept only certain protocols: You may want to replicate
- # the state of flows depending on their layer 4 protocol.
- #
- Protocol Accept {
- TCP
- SCTP
- DCCP
- # UDP
- # ICMP # This requires a Linux kernel >= 2.6.31
- # IPv6-ICMP # This requires a Linux kernel >= 2.6.31
- }
-
- #
- # Ignore traffic for a certain set of IP's: Usually all the
- # IP assigned to the firewall since local traffic must be
- # ignored, only forwarded connections are worth to replicate.
- # Note that these values depends on the local IPs that are
- # assigned to the firewall.
- #
- Address Ignore {
- IPv4_address 127.0.0.1 # loopback
- IPv4_address 192.168.0.100 # virtual IP 1
- IPv4_address 192.168.1.100 # virtual IP 2
- IPv4_address 192.168.0.1
- IPv4_address 192.168.1.1
- IPv4_address 192.168.100.100 # dedicated link ip
- #
- # You can also specify networks in format IP/cidr.
- # IPv4_address 192.168.0.0/24
- #
- # You can also specify an IPv6 address
- # IPv6_address ::1
- }
-
- #
- # Uncomment this line below if you want to filter by flow state.
- # This option introduces a trade-off in the replication: it
- # reduces CPU consumption at the cost of having lazy backup
- # firewall replicas. The existing TCP states are: SYN_SENT,
- # SYN_RECV, ESTABLISHED, FIN_WAIT, CLOSE_WAIT, LAST_ACK,
- # TIME_WAIT, CLOSED, LISTEN.
- #
- # State Accept {
- # ESTABLISHED CLOSED TIME_WAIT CLOSE_WAIT for TCP
- # }
- }
-}
|
|
[-]
[+]
|
Deleted |
conntrack-tools-1.4.0.tar.bz2/doc/sync/notrack/conntrackd.conf.orig
^
|
| @@ -1,466 +0,0 @@
-#
-# Synchronizer settings
-#
-Sync {
- Mode NOTRACK {
- #
- # This parameter allows you to set an initial fixed timeout
- # for the committed entries when this node goes from backup
- # to primary. This mechanism provides a way to purge entries
- # that were not recovered appropriately after the specified
- # fixed timeout. If you set a low value, TCP entries in
- # Established states with no traffic may hang. For example,
- # an SSH connection without KeepAlive enabled. If not set,
- # the daemon uses an approximate timeout value calculation
- # mechanism. By default, this option is not set.
- #
- # CommitTimeout 180
-
- #
- # If the firewall replica goes from primary to backup,
- # the conntrackd -t command is invoked in the script.
- # This command schedules a flush of the table in N seconds.
- # This is useful to purge the connection tracking table of
- # zombie entries and avoid clashes with old entries if you
- # trigger several consecutive hand-overs. Default is 60 seconds.
- #
- # PurgeTimeout 60
-
- #
- # This clause allows you to disable the internal cache. Thus,
- # the synchronization messages are directly send through
- # the dedicated link. This option is set of off by default.
- #
- # DisableInternalCache Off
-
- #
- # This clause allows you to disable the external cache. Thus,
- # the state entries are directly injected into the kernel
- # conntrack table. As a result, you save memory in user-space
- # but you consume slots in the kernel conntrack table for
- # backup state entries. Moreover, disabling the external cache
- # means more CPU consumption. You need a Linux kernel
- # >= 2.6.29 to use this feature. By default, this clause is
- # set off. If you are installing conntrackd for first time,
- # please read the user manual and I encourage you to consider
- # using the fail-over scripts instead of enabling this option!
- #
- # DisableExternalCache Off
- }
-
- #
- # Multicast IP and interface where messages are
- # broadcasted (dedicated link). IMPORTANT: Make sure
- # that iptables accepts traffic for destination
- # 225.0.0.50, eg:
- #
- # iptables -I INPUT -d 225.0.0.50 -j ACCEPT
- # iptables -I OUTPUT -d 225.0.0.50 -j ACCEPT
- #
- Multicast {
- #
- # Multicast address: The address that you use as destination
- # in the synchronization messages. You do not have to add
- # this IP to any of your existing interfaces. If any doubt,
- # do not modify this value.
- #
- IPv4_address 225.0.0.50
-
- #
- # The multicast group that identifies the cluster. If any
- # doubt, do not modify this value.
- #
- Group 3780
-
- #
- # IP address of the interface that you are going to use to
- # send the synchronization messages. Remember that you must
- # use a dedicated link for the synchronization messages.
- #
- IPv4_interface 192.168.100.100
-
- #
- # The name of the interface that you are going to use to
- # send the synchronization messages.
- #
- Interface eth2
-
- # The multicast sender uses a buffer to enqueue the packets
- # that are going to be transmitted. The default size of this
- # socket buffer is available at /proc/sys/net/core/wmem_default.
- # This value determines the chances to have an overrun in the
- # sender queue. The overrun results packet loss, thus, losing
- # state information that would have to be retransmitted. If you
- # notice some packet loss, you may want to increase the size
- # of the sender buffer. The default size is usually around
- # ~100 KBytes which is fairly small for busy firewalls.
- # Note: This protocol is best effort, it is really recommended
- # to increase the buffer size.
- #
- SndSocketBuffer 1249280
-
- # The multicast receiver uses a buffer to enqueue the packets
- # that the socket is pending to handle. The default size of this
- # socket buffer is available at /proc/sys/net/core/rmem_default.
- # This value determines the chances to have an overrun in the
- # receiver queue. The overrun results packet loss, thus, losing
- # state information that would have to be retransmitted. If you
- # notice some packet loss, you may want to increase the size of
- # of the sender buffer. The default size is usually around
- # ~100 KBytes which is fairly small for busy firewalls.
- # Note: This protocol is best effort, it is really recommended
- # to increase the buffer size.
- #
- RcvSocketBuffer 1249280
-
- #
- # Enable/Disable message checksumming. This is a good
- # property to achieve fault-tolerance. In case of doubt, do
- # not modify this value.
- #
- Checksum on
- }
- #
- # You can specify more than one dedicated link. Thus, if one dedicated
- # link fails, conntrackd can fail-over to another. Note that adding
- # more than one dedicated link does not mean that state-updates will
- # be sent to all of them. There is only one active dedicated link at
- # a given moment. The `Default' keyword indicates that this interface
- # will be selected as the initial dedicated link. You can have
- # up to 4 redundant dedicated links. Note: Use different multicast
- # groups for every redundant link.
- #
- # Multicast Default {
- # IPv4_address 225.0.0.51
- # Group 3781
- # IPv4_interface 192.168.100.101
- # Interface eth3
- # # SndSocketBuffer 1249280
- # # RcvSocketBuffer 1249280
- # Checksum on
- # }
-
- #
- # You can use Unicast UDP instead of Multicast to propagate events.
- # Note that you cannot use unicast UDP and Multicast at the same
- # time, you can only select one.
- #
- # UDP {
- #
- # UDP address that this firewall uses to listen to events.
- #
- # IPv4_address 192.168.2.100
- #
- # or you may want to use an IPv6 address:
- #
- # IPv6_address fe80::215:58ff:fe28:5a27
-
- #
- # Destination UDP address that receives events, ie. the other
- # firewall's dedicated link address.
- #
- # IPv4_Destination_Address 192.168.2.101
- #
- # or you may want to use an IPv6 address:
- #
- # IPv6_Destination_Address fe80::2d0:59ff:fe2a:775c
-
- #
- # UDP port used
- #
- # Port 3780
-
- #
- # The name of the interface that you are going to use to
- # send the synchronization messages.
- #
- # Interface eth2
-
- #
- # The sender socket buffer size
- #
- # SndSocketBuffer 1249280
-
- #
- # The receiver socket buffer size
- #
- # RcvSocketBuffer 1249280
-
- #
- # Enable/Disable message checksumming.
- #
- # Checksum on
- # }
-
- #
- # You can also use Unicast TCP to propagate events. Thus, the NOTRACK
- # mode becomes reliable.
- #
- # TCP {
- #
- # TCP address that this firewall uses to listen to events.
- #
- # IPv4_address 192.168.2.100
- #
- # or you may want to use an IPv6 address:
- #
- # IPv6_address fe80::215:58ff:fe28:5a27
-
- #
- # Destination TCP address that receives events, ie. the other
- # firewall's dedicated link address.
- #
- # IPv4_Destination_Address 192.168.2.101
- #
- # or you may want to use an IPv6 address:
- #
- # IPv6_Destination_Address fe80::2d0:59ff:fe2a:775c
-
- #
- # TCP port used
- #
- # Port 3780
-
- #
- # The name of the interface that you are going to use to
- # send the synchronization messages.
- #
- # Interface eth2
-
- #
- # The sender socket buffer size
- #
- # SndSocketBuffer 1249280
-
- #
- # The receiver socket buffer size
- #
- # RcvSocketBuffer 1249280
-
- #
- # Enable/Disable message checksumming.
- #
- # Checksum on
- # }
-
- #
- # Other unsorted options that are related to the synchronization.
- #
- # Options {
- #
- # TCP state-entries have window tracking disabled by default,
- # you can enable it with this option. As said, default is off.
- # This feature requires a Linux kernel >= 2.6.36.
- #
- # TCPWindowTracking Off
-
- # Set this option on if you want to enable the synchronization
- # of expectations. You have to specify the list of helpers that
- # you want to enable. Default is off.
- #
- # ExpectationSync {
- # ftp
- # ras
- # q.931
- # h.245
- # sip
- # }
- #
- # You can use this alternatively:
- #
- # ExpectationSync On
- #
- # If you want to synchronize expectations of all helpers.
- # }
-}
-
-#
-# General settings
-#
-General {
- #
- # Set the nice value of the daemon, this value goes from -20
- # (most favorable scheduling) to 19 (least favorable). Using a
- # very low value reduces the chances to lose state-change events.
- # Default is 0 but this example file sets it to most favourable
- # scheduling as this is generally a good idea. See man nice(1) for
- # more information.
- #
- Nice -20
-
- #
- # Select a different scheduler for the daemon, you can select between
- # RR and FIFO and the process priority (minimum is 0, maximum is 99).
- # See man sched_setscheduler(2) for more information. Using a RT
- # scheduler reduces the chances to overrun the Netlink buffer.
- #
- # Scheduler {
- # Type FIFO
- # Priority 99
- # }
-
- #
- # Number of buckets in the cache hashtable. The bigger it is,
- # the closer it gets to O(1) at the cost of consuming more memory.
- # Read some documents about tuning hashtables for further reference.
- #
- HashSize 32768
-
- #
- # Maximum number of conntracks, it should be double of:
- # $ cat /proc/sys/net/netfilter/nf_conntrack_max
- # since the daemon may keep some dead entries cached for possible
- # retransmission during state synchronization.
- #
- HashLimit 131072
-
- #
- # Logfile: on (/var/log/conntrackd.log), off, or a filename
- # Default: off
- #
- LogFile on
-
- #
- # Syslog: on, off or a facility name (daemon (default) or local0..7)
- # Default: off
- #
- #Syslog on
-
- #
- # Lockfile
- #
- LockFile /var/lock/conntrack.lock
-
- #
- # Unix socket configuration
- #
- UNIX {
- Path /var/run/conntrackd.ctl
- Backlog 20
- }
-
- #
- # Netlink event socket buffer size. If you do not specify this clause,
- # the default buffer size value in /proc/net/core/rmem_default is
- # used. This default value is usually around 100 Kbytes which is
- # fairly small for busy firewalls. This leads to event message dropping
- # and high CPU consumption. This example configuration file sets the
- # size to 2 MBytes to avoid this sort of problems.
- #
- NetlinkBufferSize 2097152
-
- #
- # The daemon doubles the size of the netlink event socket buffer size
- # if it detects netlink event message dropping. This clause sets the
- # maximum buffer size growth that can be reached. This example file
- # sets the size to 8 MBytes.
- #
- NetlinkBufferSizeMaxGrowth 8388608
-
- #
- # If the daemon detects that Netlink is dropping state-change events,
- # it automatically schedules a resynchronization against the Kernel
- # after 30 seconds (default value). Resynchronizations are expensive
- # in terms of CPU consumption since the daemon has to get the full
- # kernel state-table and purge state-entries that do not exist anymore.
- # Be careful of setting a very small value here. You have the following
- # choices: On (enabled, use default 30 seconds value), Off (disabled)
- # or Value (in seconds, to set a specific amount of time). If not
- # specified, the daemon assumes that this option is enabled.
- #
- # NetlinkOverrunResync On
-
- # If you want reliable event reporting over Netlink, set on this
- # option. If you set on this clause, it is a good idea to set off
- # NetlinkOverrunResync. This option is off by default and you need
- # a Linux kernel >= 2.6.31.
- #
- # NetlinkEventsReliable Off
-
- #
- # By default, the daemon receives state updates following an
- # event-driven model. You can modify this behaviour by switching to
- # polling mode with the PollSecs clause. This clause tells conntrackd
- # to dump the states in the kernel every N seconds. With regards to
- # synchronization mode, the polling mode can only guarantee that
- # long-lifetime states are recovered. The main advantage of this method
- # is the reduction in the state replication at the cost of reducing the
- # chances of recovering connections.
- #
- # PollSecs 15
-
- #
- # The daemon prioritizes the handling of state-change events coming
- # from the core. With this clause, you can set the maximum number of
- # state-change events (those coming from kernel-space) that the daemon
- # will handle after which it will handle other events coming from the
- # network or userspace. A low value improves interactivity (in terms of
- # real-time behaviour) at the cost of extra CPU consumption.
- # Default (if not set) is 100.
- #
- # EventIterationLimit 100
-
- #
- # Event filtering: This clause allows you to filter certain traffic,
- # There are currently three filter-sets: Protocol, Address and
- # State. The filter is attached to an action that can be: Accept or
- # Ignore. Thus, you can define the event filtering policy of the
- # filter-sets in positive or negative logic depending on your needs.
- # You can select if conntrackd filters the event messages from
- # user-space or kernel-space. The kernel-space event filtering
- # saves some CPU cycles by avoiding the copy of the event message
- # from kernel-space to user-space. The kernel-space event filtering
- # is prefered, however, you require a Linux kernel >= 2.6.29 to
- # filter from kernel-space. If you want to select kernel-space
- # event filtering, use the keyword 'Kernelspace' instead of
- # 'Userspace'.
- #
- Filter From Userspace {
- #
- # Accept only certain protocols: You may want to replicate
- # the state of flows depending on their layer 4 protocol.
- #
- Protocol Accept {
- TCP
- SCTP
- DCCP
- # UDP
- # ICMP # This requires a Linux kernel >= 2.6.31
- # IPv6-ICMP # This requires a Linux kernel >= 2.6.31
- }
-
- #
- # Ignore traffic for a certain set of IP's: Usually all the
- # IP assigned to the firewall since local traffic must be
- # ignored, only forwarded connections are worth to replicate.
- # Note that these values depends on the local IPs that are
- # assigned to the firewall.
- #
- Address Ignore {
- IPv4_address 127.0.0.1 # loopback
- IPv4_address 192.168.0.100 # virtual IP 1
- IPv4_address 192.168.1.100 # virtual IP 2
- IPv4_address 192.168.0.1
- IPv4_address 192.168.1.1
- IPv4_address 192.168.100.100 # dedicated link ip
- #
- # You can also specify networks in format IP/cidr.
- # IPv4_address 192.168.0.0/24
- #
- # You can also specify an IPv6 address
- # IPv6_address ::1
- }
-
- #
- # Uncomment this line below if you want to filter by flow state.
- # This option introduces a trade-off in the replication: it
- # reduces CPU consumption at the cost of having lazy backup
- # firewall replicas. The existing TCP states are: SYN_SENT,
- # SYN_RECV, ESTABLISHED, FIN_WAIT, CLOSE_WAIT, LAST_ACK,
- # TIME_WAIT, CLOSED, LISTEN.
- #
- # State Accept {
- # ESTABLISHED CLOSED TIME_WAIT CLOSE_WAIT for TCP
- # }
- }
-}
|
|
[-]
[+]
|
Changed |
conntrack-tools-1.4.1.tar.bz2/configure
^
|
| @@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for conntrack-tools 1.4.0.
+# Generated by GNU Autoconf 2.69 for conntrack-tools 1.4.1.
#
# Report bugs to <pablo@netfilter.org>.
#
@@ -590,8 +590,8 @@
# Identity of this package.
PACKAGE_NAME='conntrack-tools'
PACKAGE_TARNAME='conntrack-tools'
-PACKAGE_VERSION='1.4.0'
-PACKAGE_STRING='conntrack-tools 1.4.0'
+PACKAGE_VERSION='1.4.1'
+PACKAGE_STRING='conntrack-tools 1.4.1'
PACKAGE_BUGREPORT='pablo@netfilter.org'
PACKAGE_URL=''
@@ -1347,7 +1347,7 @@
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat <<_ACEOF
-\`configure' configures conntrack-tools 1.4.0 to adapt to many kinds of systems.
+\`configure' configures conntrack-tools 1.4.1 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -1417,7 +1417,7 @@
if test -n "$ac_init_help"; then
case $ac_init_help in
- short | recursive ) echo "Configuration of conntrack-tools 1.4.0:";;
+ short | recursive ) echo "Configuration of conntrack-tools 1.4.1:";;
esac
cat <<\_ACEOF
@@ -1557,7 +1557,7 @@
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
-conntrack-tools configure 1.4.0
+conntrack-tools configure 1.4.1
generated by GNU Autoconf 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1926,7 +1926,7 @@
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
-It was created by conntrack-tools $as_me 1.4.0, which was
+It was created by conntrack-tools $as_me 1.4.1, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ $0 $@
@@ -2814,7 +2814,7 @@
# Define the identity of the package.
PACKAGE='conntrack-tools'
- VERSION='1.4.0'
+ VERSION='1.4.1'
cat >>confdefs.h <<_ACEOF
@@ -13787,7 +13787,7 @@
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
-This file was extended by conntrack-tools $as_me 1.4.0, which was
+This file was extended by conntrack-tools $as_me 1.4.1, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES = $CONFIG_FILES
@@ -13844,7 +13844,7 @@
cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
ac_cs_version="\\
-conntrack-tools config.status 1.4.0
+conntrack-tools config.status 1.4.1
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
|
|
[-]
[+]
|
Changed |
conntrack-tools-1.4.1.tar.bz2/configure.ac
^
|
| @@ -1,4 +1,4 @@
-AC_INIT(conntrack-tools, 1.4.0, pablo@netfilter.org)
+AC_INIT(conntrack-tools, 1.4.1, pablo@netfilter.org)
AC_CONFIG_AUX_DIR([build-aux])
AC_CANONICAL_HOST
|
|
[-]
[+]
|
Changed |
conntrack-tools-1.4.1.tar.bz2/src/conntrack.c
^
|
| @@ -822,27 +822,45 @@
*cmd |= newcmd;
}
-static unsigned int
-check_type(int argc, char *argv[])
+static char *get_table(int argc, char *argv[])
{
char *table = NULL;
- /* Nasty bug or feature in getopt_long ?
+ /* Nasty bug or feature in getopt_long ?
* It seems that it behaves badly with optional arguments.
* Fortunately, I just stole the fix from iptables ;) */
if (optarg)
return 0;
- else if (optind < argc && argv[optind][0] != '-'
- && argv[optind][0] != '!')
+ else if (optind < argc && argv[optind][0] != '-' &&
+ argv[optind][0] != '!')
table = argv[optind++];
-
- if (!table)
- return 0;
-
+
+ return table;
+}
+
+enum {
+ CT_TABLE_CONNTRACK,
+ CT_TABLE_EXPECT,
+ CT_TABLE_DYING,
+ CT_TABLE_UNCONFIRMED,
+};
+
+static unsigned int check_type(int argc, char *argv[])
+{
+ const char *table = get_table(argc, argv);
+
+ /* default to conntrack subsystem if nothing has been specified. */
+ if (table == NULL)
+ return CT_TABLE_CONNTRACK;
+
if (strncmp("expect", table, strlen(table)) == 0)
- return 1;
+ return CT_TABLE_EXPECT;
else if (strncmp("conntrack", table, strlen(table)) == 0)
- return 0;
+ return CT_TABLE_CONNTRACK;
+ else if (strncmp("dying", table, strlen(table)) == 0)
+ return CT_TABLE_DYING;
+ else if (strncmp("unconfirmed", table, strlen(table)) == 0)
+ return CT_TABLE_UNCONFIRMED;
else
exit_error(PARAMETER_PROBLEM, "unknown type `%s'", table);
@@ -1686,6 +1704,27 @@
return MNL_CB_OK;
}
+static int mnl_nfct_dump_cb(const struct nlmsghdr *nlh, void *data)
+{
+ struct nf_conntrack *ct;
+ char buf[4096];
+
+ ct = nfct_new();
+ if (ct == NULL)
+ return MNL_CB_OK;
+
+ nfct_nlmsg_parse(nlh, ct);
+
+ nfct_snprintf(buf, sizeof(buf), ct, NFCT_T_UNKNOWN, NFCT_O_DEFAULT, 0);
+ printf("%s\n", buf);
+
+ nfct_destroy(ct);
+
+ counter++;
+
+ return MNL_CB_OK;
+}
+
static struct ctproto_handler *h;
int main(int argc, char *argv[])
@@ -1720,6 +1759,16 @@
switch(c) {
/* commands */
case 'L':
+ type = check_type(argc, argv);
+ /* Special case: dumping dying and unconfirmed list
+ * are handled like normal conntrack dumps.
+ */
+ if (type == CT_TABLE_DYING ||
+ type == CT_TABLE_UNCONFIRMED)
+ add_command(&command, cmd2type[c][0]);
+ else
+ add_command(&command, cmd2type[c][type]);
+ break;
case 'I':
case 'D':
case 'G':
@@ -1730,14 +1779,25 @@
case 'C':
case 'S':
type = check_type(argc, argv);
+ if (type == CT_TABLE_DYING ||
+ type == CT_TABLE_UNCONFIRMED) {
+ exit_error(PARAMETER_PROBLEM,
+ "Can't do that command with "
+ "tables `dying' and `unconfirmed'");
+ }
add_command(&command, cmd2type[c][type]);
break;
case 'U':
type = check_type(argc, argv);
- if (type == 0)
+ if (type == CT_TABLE_DYING ||
+ type == CT_TABLE_UNCONFIRMED) {
+ exit_error(PARAMETER_PROBLEM,
+ "Can't do that command with "
+ "tables `dying' and `unconfirmed'");
+ } else if (type == CT_TABLE_CONNTRACK)
add_command(&command, CT_UPDATE);
else
- exit_error(PARAMETER_PROBLEM,
+ exit_error(PARAMETER_PROBLEM,
"Can't update expectations");
break;
/* options */
@@ -1937,6 +1997,28 @@
struct nfct_filter_dump *filter_dump;
case CT_LIST:
+ if (type == CT_TABLE_DYING) {
+ if (nfct_mnl_socket_open() < 0)
+ exit_error(OTHER_PROBLEM, "Can't open handler");
+
+ res = nfct_mnl_dump(NFNL_SUBSYS_CTNETLINK,
+ IPCTNL_MSG_CT_GET_DYING,
+ mnl_nfct_dump_cb);
+
+ nfct_mnl_socket_close();
+ break;
+ } else if (type == CT_TABLE_UNCONFIRMED) {
+ if (nfct_mnl_socket_open() < 0)
+ exit_error(OTHER_PROBLEM, "Can't open handler");
+
+ res = nfct_mnl_dump(NFNL_SUBSYS_CTNETLINK,
+ IPCTNL_MSG_CT_GET_UNCONFIRMED,
+ mnl_nfct_dump_cb);
+
+ nfct_mnl_socket_close();
+ break;
+ }
+
cth = nfct_open(CONNTRACK, 0);
if (!cth)
exit_error(OTHER_PROBLEM, "Can't open handler");
|
|
[-]
[+]
|
Changed |
conntrack-tools-1.4.1.tar.bz2/src/process.c
^
|
| @@ -27,25 +27,19 @@
struct child_process *c, *this;
int pid;
- /* block SIGCHLD to avoid the access of the list concurrently */
- sigprocmask(SIG_BLOCK, &STATE(block), NULL);
-
/* We only want one process of this type at the same time. This is
* useful if you want to prevent two child processes from accessing
* a shared descriptor at the same time. */
if (flags & CTD_PROC_F_EXCL) {
list_for_each_entry(this, &process_list, head) {
if (this->type == type) {
- sigprocmask(SIG_UNBLOCK, &STATE(block), NULL);
return -1;
}
}
}
c = calloc(sizeof(struct child_process), 1);
- if (c == NULL) {
- sigprocmask(SIG_UNBLOCK, &STATE(block), NULL);
+ if (c == NULL)
return -1;
- }
c->type = type;
c->cb = cb;
@@ -55,8 +49,6 @@
if (c->pid > 0)
list_add(&c->head, &process_list);
- sigprocmask(SIG_UNBLOCK, &STATE(block), NULL);
-
return pid;
}
@@ -89,7 +81,6 @@
char buf[4096];
int size = 0;
- sigprocmask(SIG_BLOCK, &STATE(block), NULL);
list_for_each_entry(this, &process_list, head) {
size += snprintf(buf+size, sizeof(buf),
"PID=%u type=%s\n",
@@ -97,7 +88,6 @@
this->type < CTD_PROC_MAX ?
process_type_to_name[this->type] : "unknown");
}
- sigprocmask(SIG_UNBLOCK, &STATE(block), NULL);
send(fd, buf, size, 0);
}
|
|
[-]
[+]
|
Changed |
conntrack-tools-1.4.1.tar.bz2/src/run.c
^
|
| @@ -40,10 +40,15 @@
#include <time.h>
#include <fcntl.h>
-void killer(int foo)
+void killer(int signal)
{
- /* no signals while handling signals */
- sigprocmask(SIG_BLOCK, &STATE(block), NULL);
+ /* Signals are re-entrant, disable signal handling to avoid problems
+ * in case we receive SIGINT and SIGTERM in a row. This function is
+ * also called via -k from the unix socket context, we already disabled
+ * signals in that path, so don't do it.
+ */
+ if (signal)
+ sigprocmask(SIG_BLOCK, &STATE(block), NULL);
local_server_destroy(&STATE(local));
@@ -58,8 +63,6 @@
dlog(LOG_NOTICE, "---- shutdown received ----");
close_log();
- sigprocmask(SIG_UNBLOCK, &STATE(block), NULL);
-
exit(0);
}
|
