Guus Sliepen [Sun, 5 Jun 2016 12:47:21 +0000 (14:47 +0200)]
Preserve IPv6 scope_id in edges.
When creating an edge after authenticating a peer, we copy the
address used for the TCP connection, but change the port to that used
for UDP. But the way we did it discarded the scope_id for IPv6
addresses. This prevented UDP communication from working correctly when
connecting to a peer on the same LAN using an IPv6 link-local address.
Thanks to Rafał Leśniak for pointing out this issue.
thorkill [Thu, 19 May 2016 13:48:15 +0000 (15:48 +0200)]
Prevent tincd from sending packets to unexpecting nodes
Make tincd recognize when it was asleep and close connections to it's
peers. This happens when e.g. RoadWarrior has been suspended for
"longer" time period. After resume, it will start to communicate
with it's peers using the contextes it had before suspend.
On the other side, the nodes closed the connections since PingTimeout
and/or TCP connection went down.
Sending data to such unaware (sptps mostly) nodes will cause
havoc in the logs. Misleading the developers to wrong assumptions
that something is wrong with sptps.
Guus Sliepen [Sun, 1 May 2016 10:07:44 +0000 (12:07 +0200)]
Revert "Remove tinc.service, it is not necessary."
This reverts commit 0b6f84f96eeed20a0d771fedb72c0e19941adb7e. Although
systemd does automatically provide a "tinc.slice" when there is only a
tinc@.service template, it doesn't quite work the same way as
tinc.service.
Thanks to Alexander Ried for pointing out that if you have
tinc@.service template, systemd will provide a default slice containing
all instances of that template. So "systemctl start tinc" will still do
what we want it to do.
It doesn't do anything except give a confusing error message that we are
closing the connection to ourself. Replace it with connection_del().
This also fixes a double free.
Handle special characters in sptps_test only if the --special option is given.
sptps_test treats lines starting with #, ^ and $ specially, in order to
test the SPTPS protocol. However, this should only be done if explicitly
requested, otherwise it can unexpectedly fail.
When passing a NetName via an invitation, we don't allow any characters
that are unsafe (either because they could cause shells to expand things,
or because they are not allowed on some filesystems).
Also, warn when tinc is started with unsafe netnames.
This adds the ability for an invitation to provision an invitee with a
tinc-up script. This is quite strictly controlled; only address configuration
and routes are supported by adding "Ifconfig" and "Route" statements to
the invitation file. The "tinc join" command will generate a tinc-up script
from those statements, and will ask before enabling the tinc-up script.
Fix generation of version_git.h for some versions of BSD make.
In order to support VPATH builds, we have to use ${srcdir}/version.c as
the target for the rule that depends on the generation of version_git.h.
When not doing a VPATH build, ${srcdir} expands to ".", so the target
will be "./version.c". However, on some BSDs, make does not understand
that "./version.c" is the same as "version.c", and therefore it doesn't
trigger generating version_git.h when trying to build version.o. (It
works fine if you do a VPATH build, and OpenBSD's make does the right
thing in all cases.)
The trick is to have version.c depend on ${srcdir}/version.c. Of course,
Linux's make knows this is nonsense and will complain about a circular
dependency, so add this rule only on BSD platforms.
Guus Sliepen [Sun, 1 Nov 2015 20:07:56 +0000 (21:07 +0100)]
Update "now" after connect() when making outgoing connections.
It could be that address resolution takes a long time, don't let that
count against a connection. This is especially important when using a
nameserver from the VPN.
Guus Sliepen [Sun, 3 May 2015 18:06:12 +0000 (20:06 +0200)]
Never call putenv() with data on the stack.
Even though we are using putenv() here to remove items from the
environment, there is no guarantee that putenv() doesn't add the
argument to the environment anyway. In that case, we have to make sure
that it doesn't go away. We also don't want a memory leak, so keep a
list of things we unputenv()ed around, so we can reuse things.
Thanks to Poul-Henning Kamp for pointing out this problem.
Guus Sliepen [Sat, 27 Feb 2016 13:46:01 +0000 (14:46 +0100)]
Add warnings for bad combinations of Device and Interface.
On Linux, the name of the tun/tap interface can be set freely. However,
on most other operating systems, tinc cannot change the name of the
interface. In those situations, it is possible to specify a Device and
an Interface that conflict with each other. On BSD, this can cause
$INTERFACE to be set incorrectly, on Windows, this results in a
potentially unreliable way in which a TAP-Win32 interface is selected.
Fix source IP address for ICMP unreachable packets generated by tinc.
Try to send ICMP unreachable replies from an address assigned to the
local machine, instead of the destination address of the original
packet.
The address is found by looking up the route towards the sender of
the packet that generated the error; in usual configurations, this
is the tinc interface.
This also fixes the traceroute display in mtr when using the
DecrementTTL option.
Guus Sliepen [Tue, 24 Nov 2015 15:48:44 +0000 (16:48 +0100)]
Don't leave dead outgoing_t's in the outgoing_list.
If an outgoing connection cannot be made because no address is known for
it, it should be removed from the outgoing_list, otherwise it will
prevent it from being re-added later when we do know addresses for it.
Etienne Dechamps [Sun, 22 Nov 2015 17:14:14 +0000 (17:14 +0000)]
Don't unset validkey when receiving SPTPS handshakes over ANS_KEY.
This fixes a hairy race condition that was introduced in 1e89a63f1638e43dee79afbb18d5f733b27d830b, which changed
the underlying transport of handshake packets from REQ_KEY to ANS_KEY.
Unfortunately, what I missed in that commit is, on the receiving side,
there is a slight difference between req_key_h() and ans_key_h():
indeed, the latter resets validkey to false.
The reason why this is not a problem during typical operation is
because the normal SPTPS key regeneration procedure looks like this:
KEX ->
<- KEX
SIG ->
<- SIG
All these messages are sent over ANS_KEY, therefore the receiving side
will unset validkey. However, that's typically not a problem in practice
because upon reception of the last message (SIG), SPTPS will call
sptps_receive_record(), which will set validkey to true again, and
everything works out fine in the end.
However, that was the *typical* scenario. Now let's assume that the
SPTPS channel is in active use at the same time key regeneration
happens. Specifically, let's assume a normal VPN data packet sneaks in
during the key regeneration procedure:
KEX ->
<- KEX
<- (SPTPS packet, over TCP or UDP)
<- KEX (wtf?)
SIG -> (refused with Invalid packet seqno: XXX != 0)
At this point, both nodes are extremely confused and the SPTPS channel
becomes unusable with various errors being thrown on both sides. The
channel will stay down until automatic SPTPS channel restart kicks in
after 10 seconds.
(Note: the above is just an example - the race can occur on either side
whenever a packet is sent during the period of time between KEX and SIG
messages are received by the node sending the packet.)
I've seen this race occur in the wild - it is very likely to occur if
key regeneration occurs on a heavily loaded channel. It can be
reproduced fairly easily by setting KeyExpire to a short value (a few
seconds) and then running something like ping -f foobar -i 0.01.
The reason why this occurs is because tinc's TX code path triggers the
following:
- send_packet()
- try_tx()
- try_tx_sptps()
- validkey is false because we just received an ANS_KEY message
- waitingforkey is false because it's not used for key regeneration
- send_req_key()
- SPTPS channel restart (sptps_stop(), sptps_start()).
Obviously, it all goes downhill from there and the two nodes get very
confused quickly (for example the seqno gets reset, hence the error
messages).
This commit fixes the issue by keeping validkey set when SPTPS data is
received over ANS_KEY messages.
Etienne Dechamps [Sun, 15 Nov 2015 17:42:14 +0000 (17:42 +0000)]
Try to ensure we build correctly against various libminiupnpc versions.
Unfortunately, libminiupnpc has a somewhat... "peculiar" approach to
backwards compatibility for their API, where they reserve the right to
make breaking changes when they feel like it, forcing users to resort
to #ifdefs to ensure they use the correct API. Sigh.
Previously, tinc would only build against API versions <= 13, because I
was doing my initial development using miniupnpc-1.9.20140610 which is
the version that ships with Debian. The changes in this commit are
required for tinc to build against more recent versions, from
1.9.20150730 to the latest one at the time of this commit, 1.9.20151026.