Commit graph

2467 commits

Author SHA1 Message Date
Guus Sliepen
6b92ac505d Add a variable offset to vpn_packet_t, drop sptps_packet_t.
The offset value indicates where the actual payload starts, so we can
process both legacy and SPTPS UDP packets without having to do casting
tricks and/or moving memory around.
2014-12-25 00:36:27 +01:00
Guus Sliepen
107d9c7da5 Use void pointers for opaque data blobs in the SPTPS code. 2014-12-24 22:15:40 +01:00
Guus Sliepen
3df86ef17b Fix memory leaks found by Valgrind. 2014-12-24 17:31:33 +01:00
Guus Sliepen
d00d8dbb9b Don't use myself->name in device_disable(), it's already freed. 2014-12-24 17:06:05 +01:00
Guus Sliepen
313de46e70 Don't pass uninitialized bytes to ioctl(). 2014-12-24 16:59:08 +01:00
Guus Sliepen
a99ded7d98 Avoid using OpenSSL's random number functions. 2014-12-24 16:54:12 +01:00
Guus Sliepen
199573f1e8 Fix reception of SPTPS UDP packets.
Some bugs were introduced in 46fa12e666.
2014-12-14 13:05:30 +01:00
Guus Sliepen
558b19c243 Fix segfault when receiving UDP packets with an unknown source address. 2014-12-14 12:42:03 +01:00
Guus Sliepen
5104001bae Changes that should have been in commit 46fa12e666. 2014-12-08 08:43:15 +01:00
Guus Sliepen
46fa12e666 Make UDP packet handling more efficient.
Limit the amount of address/ID lookups to the minimum in all cases:

1) Legacy packets, need an address lookup.
2) Indirect SPTPS packets, need an address lookup + two ID lookups.
3) Direct SPTPS packets, need an ID or an address lookup.

So we start with an address lookup. If the source is an 1.1 node, we know it's an SPTPS packet,
and then the check for direct packets is a simple check if dstid is zero. If not, do the srcid and dstid
lookup. If the source is an 1.0 node, we don't have to do anything else.

If the address is unknown, we first check whether it's from a 1.1 node by assuming it has a valid srcid
and verifying the packet. If not, use the old try_harder().
2014-12-08 01:03:05 +01:00
Guus Sliepen
263d990382 Avoid memmove() for legacy UDP packets. 2014-12-08 00:44:38 +01:00
Guus Sliepen
c2319e90b1 Cache node IDs in a hash table for faster lookups. 2014-12-07 22:11:37 +01:00
Guus Sliepen
9d48d5b7d4 Add an explicit hash_delete() function. 2014-12-07 22:10:16 +01:00
Guus Sliepen
6062df4a0f Better log messages when we already know the peer's key during an upgrade.
If the peer presents a different one from the one we already know, log
an error. Otherwise, log an informational message, and terminate in the
same way as we would if we didn't already have that key.
2014-12-07 21:42:20 +01:00
Sven-Haegar Koch
148a4c9161 Try handling the case when the first side knows the ecdsa key of
the second, but the second not the key of the first.
(And both have the experimental protocol enabled)
2014-12-07 18:05:14 +01:00
Guus Sliepen
b90c42a33b Log an error message with the node's name when receiving bad SPTPS packets.
The SPTPS code doesn't know about nodes, so when it logs an error about
a bad packet, it doesn't log which node it came from. So add a log
message with the node's name and hostname in receive_udppacket().
2014-12-07 17:25:30 +01:00
Guus Sliepen
660a2c7d1b Check validity of Ed25519 key during an upgrade. 2014-12-07 17:20:18 +01:00
Sven-Haegar Koch
5716c8877f Do not disconnect when no ecdsa key is known yet.
This is the normal case when we support the experimental protocol,
but the other side is a tinc 1.0 which does not.
2014-12-07 16:53:23 +01:00
Guus Sliepen
dd6b0e65b9 Fix compiler warnings. 2014-12-03 14:51:45 +01:00
Etienne Dechamps
790b107f66 Query the Linux device for its MAC address.
On Linux, tinc doesn't know the MAC address of the TAP device until the
first read. This means that if no packets are sent through the
interface, tinc won't be able to figure out which MAC address to tag
incoming packets with. As a result, it is impossible to receive any
packet until at least one packet has been sent.

When IPv6 is disabled Linux does not spontanously send any packets
when the interface comes up. At first users wonder why the node is not
responding to ICMP pings, and then as soon as at least one packet is
sent through the interface, pings mysteriously start working, resulting
in user confusion.

This change fixes that problem by making sure tinc is aware of the
device's MAC address even before the first packet is sent.
2014-12-03 14:49:09 +01:00
groxxda
c269a17ca4 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
Etienne Dechamps
9a366544c2 Make sure to discover MTU with relays.
Currently, when tinc sends UDP SPTPS datagrams through a relay, it
doesn't automatically start discovering PMTU with the relay. This means
that unless something else triggers PMTU discovery, tinc will keep using
TCP when sending packets through the relay.

This patches fixes the issue by explicitly establishing UDP tunnels with
relays.
2014-10-04 15:11:46 +01:00
Etienne Dechamps
63daebcd1e Don't send MTU probes to nodes we can't reach directly.
Currently, we send MTU probes to each node we receive a key for, even if
we know we will never send UDP packets to that node because of
indirection. This commit disables MTU probing between nodes that have
direct communication disabled, otherwise MTU probes end up getting sent
through relays.

With the legacy protocol this was never a problem because we would never
request the key of a node with indirection enabled; with SPTPS this was
not a problem until we introduced relaying because send_sptps_data()
would simply ignore indirections, but this is not the case anymore.

Note that the fix is implemented in a quick and dirty way, by disabling
the call to send_mtu_probe() in ans_key_h(); this is not a clean fix
because there's no code to resume sending MTU probes in case the
indirection disappears because of a graph change.
2014-10-04 15:11:46 +01:00
Etienne Dechamps
111040d7d1 Add UDP datagram relay support to SPTPS.
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.
2014-10-04 14:37:15 +01:00
Etienne Dechamps
8dd1c8a020 Prepend source node ID information to UDP datagrams.
This commit changes the layout of UDP datagrams to include the 6-byte ID
(i.e. node name hash) of the node that crafted the packet at the very
beginning of the datagram (i.e. before the seqno). Note that this only
applies to SPTPS.

This is implemented at the lowest layer, i.e. in
handle_incoming_vpn_data() and send_sptps_data() functions. Source ID is
added and removed there, in such a way that the upper layers are unaware
of its presence.

This is the first stepping stone towards supporting UDP relaying in
SPTPS, by providing information about the original sender in the packet
itself. Nevertheless, even without relaying this commit already provides
a few benefits such as being able to reliably determine the source node
of a packet in the presence of an unknown source IP address, without
having to painfully go through all node keys. This makes tinc's behavior
much more scalable in this regard.

This change does not break anything with regard to the protocol: It
preserves compatibility with 1.0 and even with older pre-1.1 releases
thanks to a minor protocol version change (17.4). Source ID information
won't be included in packets sent to nodes with minor version < 4.

One drawback, however, is that this change increases SPTPS datagram
overhead by 6 bytes (the size of the source ID itself).
2014-10-04 11:21:44 +01:00
Etienne Dechamps
092d620dbb Change vpn_packet_t::seqno from uint32_t to uint8_t[4].
This is to make sure on-wire vpn_packet_t fields are always 1-byte
aligned, otherwise padding could get in the way.
2014-10-04 11:21:38 +01:00
Etienne Dechamps
55a78da4e0 Introduce node IDs.
This introduces a new type of identifier for nodes, which complements
node names: node IDs. Node IDs are defined as the first 6 bytes of the
SHA-256 hash of the node name. They will be used in future code in lieu
of node names as unique node identifiers in contexts where space is at
a premium (such as VPN packets).

The semantics of node IDs is that they are supposed to be unique in a
tinc graph; i.e. two different nodes that are part of the same graph
should not have the same ID, otherwise things could break. This
solution provides this guarantee based on realistic probabilities:
indeed, according to the birthday problem, with a 48-bit hash, the
probability of at least one collision is 1e-13 with 10 nodes, 1e-11
with 100 nodes, 1e-9 with 1000 nodes and 1e-7 with 10000 nodes. Things
only start getting hairy with more than 1 million nodes, as the
probability gets over 0.2%.
2014-10-04 11:13:59 +01:00
Etienne Dechamps
ac77e3c1eb Invalidate UDP information on address changes.
Currently, when tinc receives an UDP packet from an unexpected address
(i.e. an address different from the node's current address), it just
updates its internal UDP address record and carries on like nothing
happened.

This poses two problems:

 - It assumes that the PMTU for the new address is the same as the
   old address, which is risky. Packets might get dropped if the PMTU
   turns out to be smaller (or if UDP communication on the new address
   turns out to be impossible).

 - Because the source address in the UDP packet itself is not
   authenticated (i.e. it can be forged by an attacker), this
   introduces a potential vulnerability by which an attacker with
   control over one link can trick a tinc node into dumping its network
   traffic to an arbitrary IP address.

This commit fixes the issue by invalidating UDP/PMTU state for a node
when its UDP address changes. This will trigger a temporary fallback
to indirect communication until we get confirmation via PMTU discovery
that the node is indeed sitting at the other end of the new UDP address.
2014-10-04 11:12:36 +01:00
Etienne Dechamps
f57d53c3ad Fix protocol version check for type 2 MTU probe replies.
Currently tinc only uses type 2 MTU probe replies if the recipient uses
protocol version 17.3. It should of course support any higher minor
protocol version as well.
2014-09-27 18:00:10 +01:00
Franz Pletz
f6b008d731 tinc-gui: Use /usr/bin/env to resolve path to python 2014-09-22 22:43:15 +02:00
Etienne Dechamps
daf65919d1 Preemptively mirror REQ_PUBKEY messages from nodes with unknown keys.
In this commit, if a node receives a REQ_PUBKEY message from a node it
doesn't have the key for, it will send a REQ_PUBKEY message in return
*before* sending its own key.

The rationale is to prevent delays when establishing communication
between two nodes that see each other for the first time. These delays
are caused by the first SPTPS packet being dropped on the floor, as
shown in the following typical exchange:

	node1: No Ed25519 key known for node2
	REQ_PUBKEY ->
	<- ANS_PUBKEY
	node1: Learned Ed25519 public key from node2
	REQ_SPTPS_START ->
	node2: No Ed25519 key known for zyklos
	<- REQ_PUBKEY
	ANS_PUBKEY ->
	node2: Learned Ed25519 public key from node1
	-- 10-second delay --
	node1: No key from node2 after 10 seconds, restarting SPTPS
	REQ_SPTPS_START ->
	<- SPTPS ->
	node1: SPTPS key exchange with node2 succesful
	node2: SPTPS key exchange with node1 succesful

With this patch, the following happens instead:

	node1: No Ed25519 key known for node2
	REQ_PUBKEY ->
	node2: Preemptively requesting Ed25519 key for node1
	<- REQ_PUBKEY
	<- ANS_PUBKEY
	ANS_PUBKEY ->
	node2: Learned Ed25519 public key from node1
	node1: Learned Ed25519 public key from node2
	REQ_SPTPS_START ->
	<- SPTPS ->
	node1: SPTPS key exchange with node2 succesful
	node2: SPTPS key exchange with node1 succesful
2014-09-22 10:10:57 +02:00
Etienne Dechamps
c897f8c99e Fix default device path selection on BSD.
Currently, if DeviceType = tap but Mode = router, the default
device path is /dev/tun0, which is wrong. This commit fixes that.
2014-09-21 13:00:23 +02:00
Etienne Dechamps
a649aa51bf Ignore the Interface option if device rename is impossible.
There are platforms on which it is impossible to rename the TUN/TAP
device. An example is Mac OS X (tuntapx). On these platforms,
specifying the Interface option will not rename the interface, but
the specified name will still be passed to tinc-up scripts and the
like, resulting in potential confusion for the user.
2014-09-21 11:30:00 +01:00
Etienne Dechamps
053925efeb Fix default TAP device on Darwin.
On Darwin (tuntapx), the first TAP device is /dev/tap0, not /dev/tun0.
2014-09-21 11:14:19 +01:00
Etienne Dechamps
1ac9a3fbd1 Fix wrong identifier in SO_NOSIGPIPE call.
f134bd0c9c broke the Mac OS X build by
introducing a reference to an identifier, c, that doesn't exist.
2014-09-07 15:31:15 +02:00
Etienne Dechamps
7ac5263765 Don't enable the device if the reachable count is zero.
A logic bug was introduced in bd451cfe15
in which running graph() several times with zero reachable nodes had
the effect of calling device_enable() (instead of keeping the device
disabled).

This results in weird behavior when DeviceStandby is enabled, especially
on Windows where calling device_enable() several times in a row corrupts
I/O structures for the device, rendering it unusable.
2014-09-06 10:43:15 +01:00
Etienne Dechamps
9ad656b512 Fix undefined HOST_NAME_MAX on Windows.
The Windows build was broken by commit
826ad11e41 which introduced a dependency
on the HOST_NAME_MAX macro, which is not defined on Windows. According
to MSDN for gethostname(), the maximum length of the returned string
is 256 bytes (including the terminating null byte), so let's use that
as a fallback.
2014-08-31 13:59:30 +01:00
Etienne Dechamps
0f09260b13 Remove Google from the list of copyright owners.
Google released copyright to me for my own contributions.
2014-08-30 10:57:57 +01:00
William A. Kennington III
38d7e730e6 tincctl: Use replace_name to properly replace and validate input hostnames 2014-08-25 09:19:56 +02:00
William A. Kennington III
511b51ffe6 utils: Refactor check_id out of protocol for global access 2014-08-25 09:19:54 +02:00
William A. Kennington III
826ad11e41 utils: Refactor get_name's functionality into util for global access 2014-08-25 09:19:51 +02:00
Etienne Dechamps
78bf82cf33 Clarify copyright ownership for code authored by Etienne Dechamps. 2014-08-17 20:22:44 +01:00
Sven-Haegar Koch
73d8393bd6 commandline.test: Adding test that fetching non-existing config setting really fails. 2014-08-07 23:02:12 +02:00
Sven-Haegar Koch
9fe5ab7ccb Fix exit code of "tinc get".
Successfully getting an existing variable ("tinc get name") should
not result in an error exitcode (1) from the tinc command.

This changes the result of test/commandline.test from FAIL to PASS.
2014-08-07 23:01:48 +02:00
Etienne Dechamps
5ae1ec8d80 Handle TAP-Win32 immediate reads correctly.
The handling of TAP-Win32 virtual network device reads that complete
immediately (ReadFile() returns TRUE) is incorrect - instead of
starting a new read, tinc will continue listening for the overlapped
read completion event which will never fire. As a result, tinc stops
receiving packets on the interface.
2014-07-19 18:38:24 +01:00
Etienne Dechamps
1d10afd3d3 Only read from TAP-Win32 if the device is enabled.
With newer TAP-Win32 versions (such as the experimental
tap-windows6 9.21.0), tinc is unable to read from the virtual network
device:

    Error while reading from (null) {23810A13-BCA9-44CE-94C6-9AEDFBF85736}: No such file or directory

This is because these new drivers apparently don't accept reads when
the device is not in the connected state (media status).

This commit fixes the issue by making sure we start reading no sooner
than when the device is enabled, and that we stop reading when the
device is disabled. This also makes the behavior somewhat cleaner,
because it doesn't make much sense to read from a disabled device
anyway.
2014-07-19 16:05:23 +01:00
Etienne Dechamps
cc9203ee75 Add a non-interactive mode to tinc commands.
Some tinc commands, such as "tinc generate-keys", use the terminal to
ask the user for information. This can be bypassed by making sure
there is no terminal, which is trivial on *nix but might require
jumping through some hoops on Windows depending on how the command is
invoked.

This commit adds a --batch option that ensures tinc will never ask the
user for input, even if it is attached to a terminal.
2014-07-13 15:54:34 +01:00
Guus Sliepen
afb175873e Revert "Use git description as the tinc version."
This reverts commit e024b7a2c5. Automatic version
number generation needs a little bit more work to get it working correctly in
all cases.
2014-07-12 22:51:37 +02:00
Guus Sliepen
19e42b76f5 Merge branch 'keysegfault' of https://github.com/dechamps/tinc into 1.1 2014-07-12 22:25:55 +02:00
Guus Sliepen
f704304823 Merge branch 'tincstart' of https://github.com/dechamps/tinc into 1.1 2014-07-12 22:22:31 +02:00