No description
b1421b9190
In this commit, nodes use MTU_INFO messages to provide MTU information. The issue this code is meant to address is the non-trivial problem of finding the proper MTU when UDP SPTPS relays are involved. Currently, tinc has no idea what the MTU looks like beyond the first relay, and will arbitrarily use the first relay's MTU as the limit. This will fail miserably if the MTU decreases after the first relay, forcing relays to fall back to TCP. More generally, one should keep in mind that relay paths can be arbitrarily complex, resulting in packets taking "epic journeys" through the graph, switching back and forth between UDP (with variable MTUs) and TCP multiple times along the path. A solution that was considered consists in sending standard MTU probes through the relays. This is inefficient (if there are 3 nodes on one side of relay and 3 nodes on the other side, we end up with 3*3=9 MTU discoveries taking place at the same time, while technically only 3+3=6 are needed) and would involve eyebrow-raising behaviors such as probes being sent over TCP. This commit implements an alternative solution, which consists in the packet receiver sending MTU_INFO messages to the packet sender. The message contains an MTU value which is set to maximum when the message is originally sent. The message gets altered as it travels through the metagraph, such that when the message arrives to the destination, the MTU value contained in the message can be used to send packets while making sure no relays will be forced to fall back to TCP to deliver them. The operating principles behind such a protocol message are similar to how the UDP_INFO message works, but there is a key difference that prevents us from simply reusing the same message: the UDP_INFO message only cares about relay-to-relay links (i.e. it is sent between static relays and the information it contains only makes sense between two adjacent static relays), while the MTU_INFO cares about the end-to-end MTU, including the entire relay path. Therefore, UDP_INFO messages stop when they encounter static relays, while MTU_INFO messages don't stop until they get to the original packet sender. Note that, technically, the MTU that is obtained through this mechanism can be slightly pessimistic, because it can be lowered by an intermediate node that is not being used as a relay. Since nodes have no way of knowing whether they'll be used as dynamic relays or not (and have no say in the matter), this is not a trivial problem. That said, this is highly unlikely to result in noticeable issues in realistic scenarios. |
||
|---|---|---|
| bash_completion.d | ||
| doc | ||
| gui | ||
| m4 | ||
| src | ||
| test | ||
| .gitignore | ||
| AUTHORS | ||
| configure.ac | ||
| COPYING | ||
| COPYING.README | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| README.android | ||
| README.git | ||
| THANKS | ||
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.