No description
Find a file
Etienne Dechamps 1a7a9078c0 Proactively restart the SPTPS tunnel if we get receive errors.
There are a number of ways a SPTPS tunnel can get into a corrupt state.
For example, during key regeneration, the KEX and SIG messages from
other nodes might arrive out of order, which confuses the hell out of
the SPTPS code. Another possible scenario is not noticing another node
crashed and restarted because there was no point in time where the node
was seen completely disconnected from *all* nodes; this could result in
using the wrong (old) key. There are probably other scenarios which have
not even been considered yet. Distributed systems are hard.

When SPTPS got confused by a packet, it used to crash the entire
process; fortunately that was fixed by commit
2e7f68ad2b. However, the error handling
(or lack thereof) leaves a lot to be desired. Currently, when SPTPS
encounters an error when receiving a packet, it just shrugs it off and
continues as if nothing happened. The problem is, sometimes getting
receive errors mean the tunnel is completely stuck and will not recover
on its own. In that case, the node will become unreachable - possibly
indefinitely.

The goal of this commit is to improve SPTPS error handling by taking
proactive action when an incoming packet triggers a failure, which is
often an indicator that the tunnel is stuck in some way. When that
happens, we simply restart SPTPS entirely, which should make the tunnel
recover quickly.

To prevent "storms" where two buggy nodes flood each other with invalid
packets and therefore spend all their time negotiating new tunnels, we
limit the frequency at which tunnel restarts happen to ten seconds.

It is likely this commit will solve the "Invalid KEX record length
during key regeneration" issue that has been seen in the wild. It is
difficult to be sure though because we do not have a full understanding
of all the possible conditions that can trigger this problem.
2015-05-17 19:21:50 +01:00
bash_completion.d Throttle the rate of MTU_INFO messages. 2015-03-14 13:39:05 +00:00
doc Add support for out-of-tree ("VPATH") builds. 2015-05-09 16:41:48 +01:00
gui tinc-gui: Don't assign broadcast subnets to any node, fix parsing of Edges, fix diplay of Subnet.weight. 2014-10-14 22:18:56 +02:00
m4 Remove explicit distribution rules for m4 scripts. 2015-05-09 16:17:39 +01:00
src Proactively restart the SPTPS tunnel if we get receive errors. 2015-05-17 19:21:50 +01:00
test Fixed variables.test testsuite after 'Make "tinc add" idempotent.' change. 2015-02-10 07:54:52 +01:00
.gitignore Don't ignore Makefile.am. 2012-09-24 14:56:00 +02:00
AUTHORS Remove Google from the list of copyright owners. 2014-08-30 10:57:57 +01:00
configure.ac Add support for out-of-tree ("VPATH") builds. 2015-05-09 16:41:48 +01:00
COPYING Update copyright notices. 2014-02-07 20:38:48 +01:00
COPYING.README Releasing 1.0.12. 2010-02-03 22:49:48 +01:00
Makefile.am Add support for out-of-tree ("VPATH") builds. 2015-05-09 16:41:48 +01:00
NEWS Releasing 1.1pre11. 2014-12-27 09:22:31 +01:00
README Releasing 1.1pre11. 2014-12-27 09:22:31 +01:00
README.android Android cross-compilation instructions. 2012-09-24 13:55:38 +02:00
README.git Document clearly that tinc depends on curses and readline libraries. 2014-01-20 20:16:58 +01:00
THANKS Update THANKS file. 2014-12-26 14:59:15 +01:00

This is the README file for tinc version 1.1pre11. Installation
instructions may be found in the INSTALL file.

tinc is Copyright (C) 1998-2014 by:

Ivo Timmermans,
Guus Sliepen <guus@tinc-vpn.org>,
and others.

For a complete list of authors see the AUTHORS file.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version. See the file COPYING for more details.


This is a pre-release
---------------------

Please note that this is NOT a stable release. Until version 1.1.0 is released,
please use one of the 1.0.x versions if you need a stable version of tinc.

Although tinc 1.1 will be protocol compatible with tinc 1.0.x, the
functionality of the tinc program may still change, and the control socket
protocol is not fixed yet.


Security statement
------------------

This version uses an experimental and unfinished cryptographic protocol. Use it
at your own risk.


Compatibility
-------------

Version 1.1pre11 is compatible with 1.0pre8, 1.0 and later, but not with older
versions of tinc.

When the ExperimentalProtocol option is used, tinc is still compatible with
1.0.X and 1.1pre11 itself, but not with any other 1.1preX version.


Requirements
------------

In order to compile tinc, you will need a GNU C compiler environment. Please
ensure you have the latest stable versions of all the required libraries:

- OpenSSL (http://www.openssl.org/) version 1.0.0 or later, with support for
  elliptic curve cryptography (ECC) and Galois counter mode (GCM) enabled.

The following libraries are used by default, but can be disabled if necessary:

- zlib (http://www.gzip.org/zlib/)
- lzo (http://www.oberhumer.com/opensource/lzo/)
- ncurses (http://invisible-island.net/ncurses/)
- readline (ftp://ftp.gnu.org/pub/gnu/readline/)


Features
--------

Tinc is a peer-to-peer VPN daemon that supports VPNs with an arbitrary number
of nodes. Instead of configuring tunnels, you give tinc the location and
public key of a few nodes in the VPN. After making the initial connections to
those nodes, tinc will learn about all other nodes on the VPN, and will make
connections automatically. When direct connections are not possible, data will
be forwarded by intermediate nodes.

By default, nodes authenticate each other using 2048 bit RSA (or 521 bit
ECDSA*) keys. Traffic is encrypted using Blowfish in CBC mode (or AES-256 in
GCM mode*), authenticated using HMAC-SHA1 (or GCM*), and is protected against
replay attacks.

*) When using the ExperimentalProtocol option.

Tinc fully supports IPv6.

Tinc can operate in several routing modes. In the default mode, "router", every
node is associated with one or more IPv4 and/or IPv6 Subnets. The other two
modes, "switch" and "hub", let the tinc daemons work together to form a virtual
Ethernet network switch or hub.

Normally, when started tinc will detach and run in the background. In a native
Windows environment this means tinc will intall itself as a service, which will
restart after reboots.  To prevent tinc from detaching or running as a service,
use the -D option.

The status of the VPN can be queried using the "tinc" command, which connects
to a running tinc daemon via a control connection. The same tool also makes it
easy to start and stop tinc, and to change its configuration.