No description
111040d7d1
This commit changes the layout of UDP datagrams to include a 6-byte destination node ID at the very beginning of the datagram (i.e. before the source node ID and the seqno). Note that this only applies to SPTPS. Thanks to this new field, it is now possible to send SPTPS datagrams to nodes that are not the final recipient of the packets, thereby using these nodes as relay nodes. Previously SPTPS was unable to relay packets using UDP, and required a fallback to TCP if the final recipient could not be contacted directly using UDP. In that sense it fixes a regression that SPTPS introduced with regard to the legacy protocol. This change also updates tinc's low-level routing logic (i.e. send_sptps_data()) to automatically use this relaying facility if at all possible. Specifically, it will relay packets if we don't have a confirmed UDP link to the final recipient (but we have one with the next hop node), or if IndirectData is specified. This is similar to how the legacy protocol forwards packets. When sending packets directly without any relaying, the sender node uses a special value for the destination node ID: instead of setting the field to the ID of the recipient node, it writes a zero ID instead. This allows the recipient node to distinguish between a relayed packet and a direct packet, which is important when determining the UDP address of the sending node. On the relay side, relay nodes will happily relay packets that have a destination ID which is non-zero *and* is different from their own, provided that the source IP address of the packet is known. This is to prevent abuse by random strangers, since a node can't authenticate the packets that are being relayed through it. This change keeps the protocol number from the previous datagram format change (source IDs), 17.4. Compatibility is still preserved with 1.0 and with pre-1.1 releases. Note, however, that nodes running this code won't understand datagrams sent from nodes that only use source IDs and vice-versa (not that we really care). There is one caveat: in the current state, there is no way for the original sender to know what the PMTU is beyond the first hop, and contrary to the legacy protocol, relay nodes can't apply MSS clamping because they can't decrypt the relayed packets. This leads to inefficient scenarios where a reduced PMTU over some link that's part of the relay path will result in relays falling back to TCP to send packets to their final destinations. Another caveat is that once a packet gets sent over TCP, it will use TCP over the entire path, even if it is technically possible to use UDP beyond the TCP-only link(s). Arguably, these two caveats can be fixed by improving the metaconnection protocol, but that's out of scope for this change. TODOs are added instead. In any case, this is no worse than before. In addition, this change increases SPTPS datagram overhead by another 6 bytes for the destination ID, on top of the existing 6-byte overhead from the source ID. |
||
|---|---|---|
| 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.1pre10. 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.1pre10 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.1pre10 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.