tinc/src/protocol.c

206 lines
6 KiB
C
Raw Normal View History

2000-03-26 00:33:07 +00:00
/*
2002-02-10 21:57:54 +00:00
protocol.c -- handle the meta-protocol, basic functions
Copyright (C) 1999-2005 Ivo Timmermans,
2013-08-13 18:38:57 +00:00
2000-2013 Guus Sliepen <guus@tinc-vpn.org>
2000-03-26 00:33:07 +00:00
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.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
2000-03-26 00:33:07 +00:00
*/
#include "system.h"
2000-03-26 00:33:07 +00:00
#include "conf.h"
2000-11-20 19:12:17 +00:00
#include "connection.h"
#include "logger.h"
#include "meta.h"
#include "protocol.h"
#include "utils.h"
#include "xalloc.h"
2000-05-29 21:01:26 +00:00
bool tunnelserver = false;
bool strictsubnets = false;
2013-05-10 19:11:45 +00:00
bool experimental = true;
/* Jumptable for the request handlers */
static bool (*request_handlers[])(connection_t *, const char *) = {
id_h, metakey_h, challenge_h, chal_reply_h, ack_h,
status_h, error_h, termreq_h,
ping_h, pong_h,
add_subnet_h, del_subnet_h,
add_edge_h, del_edge_h,
key_changed_h, req_key_h, ans_key_h, tcppacket_h, control_h,
Add UDP_INFO protocol message. In this commit, nodes use UDP_INFO messages to provide UDP address information. The basic principle is that the node that receives packets sends UDP_INFO messages to the node that's sending the packets. The message originally contains no address information, and is (hopefully) updated with relevant address information as it gets relayed through the metagraph - specifically, each intermediate node will update the message with its best guess as to what the address is while forwarding it. When a node receives an UDP_INFO message, and it doesn't have a confirmed UDP tunnel with the originator node, it will update its records with the new address for that node, so that it always has the best possible guess as to how to reach that node. This applies to the destination node of course, but also to any intermediate nodes, because there's no reason they should pass on the free intel, and because it results in nice behavior in the presence of relay chains (multiple nodes in a path all trying to reach the same destination). If, on the other hand, the node does have a confirmed UDP tunnel, it will ignore the address information contained in the message. In all cases, if the node that receives the message is not the destination node specified in the message, it will forward the message but not before overriding the address information with the one from its own records. If the node has a confirmed UDP tunnel, that means the message is updated with the address of the confirmed tunnel; if not, the message simply reflects the records of the intermediate node, which just happen to be the contents of the UDP_INFO message it just got, so it's simply forwarded with no modification. This is similar to the way ANS_KEY messages are currently overloaded to provide UDP address information, with two differences: - UDP_INFO messages are sent way more often than ANS_KEY messages, thereby keeping the address information fresh. Previously, if the UDP situation were to change after the ANS_KEY message was sent, the sender would virtually never get the updated information. - Once a node puts address information in an ANS_KEY message, it is never changed again as the message travels through the metagraph; in contrast, UDP_INFO messages behave the opposite way, as they get rewritten every time they travel through a node with a confirmed UDP tunnel. The latter behavior seems more appropriate because UDP tunnel information becomes more relevant as it moves closer to the destination node. The ANS_KEY behavior is not satisfactory in some cases such as multi-layered graphs where the first hop is located before a NAT. Ultimately, the rationale behind this whole process is to improve UDP hole punching capabilities when port translation is in effect, and more generally, to make tinc more reliable in (very) hostile network conditions (such as multi-layered NAT).
2015-01-03 17:46:33 +00:00
NULL, NULL, NULL, /* Not "real" requests (yet) */
udp_info_h,
};
/* Request names */
static char (*request_name[]) = {
"ID", "METAKEY", "CHALLENGE", "CHAL_REPLY", "ACK",
"STATUS", "ERROR", "TERMREQ",
"PING", "PONG",
"ADD_SUBNET", "DEL_SUBNET",
"ADD_EDGE", "DEL_EDGE", "KEY_CHANGED", "REQ_KEY", "ANS_KEY", "PACKET", "CONTROL",
Add UDP_INFO protocol message. In this commit, nodes use UDP_INFO messages to provide UDP address information. The basic principle is that the node that receives packets sends UDP_INFO messages to the node that's sending the packets. The message originally contains no address information, and is (hopefully) updated with relevant address information as it gets relayed through the metagraph - specifically, each intermediate node will update the message with its best guess as to what the address is while forwarding it. When a node receives an UDP_INFO message, and it doesn't have a confirmed UDP tunnel with the originator node, it will update its records with the new address for that node, so that it always has the best possible guess as to how to reach that node. This applies to the destination node of course, but also to any intermediate nodes, because there's no reason they should pass on the free intel, and because it results in nice behavior in the presence of relay chains (multiple nodes in a path all trying to reach the same destination). If, on the other hand, the node does have a confirmed UDP tunnel, it will ignore the address information contained in the message. In all cases, if the node that receives the message is not the destination node specified in the message, it will forward the message but not before overriding the address information with the one from its own records. If the node has a confirmed UDP tunnel, that means the message is updated with the address of the confirmed tunnel; if not, the message simply reflects the records of the intermediate node, which just happen to be the contents of the UDP_INFO message it just got, so it's simply forwarded with no modification. This is similar to the way ANS_KEY messages are currently overloaded to provide UDP address information, with two differences: - UDP_INFO messages are sent way more often than ANS_KEY messages, thereby keeping the address information fresh. Previously, if the UDP situation were to change after the ANS_KEY message was sent, the sender would virtually never get the updated information. - Once a node puts address information in an ANS_KEY message, it is never changed again as the message travels through the metagraph; in contrast, UDP_INFO messages behave the opposite way, as they get rewritten every time they travel through a node with a confirmed UDP tunnel. The latter behavior seems more appropriate because UDP tunnel information becomes more relevant as it moves closer to the destination node. The ANS_KEY behavior is not satisfactory in some cases such as multi-layered graphs where the first hop is located before a NAT. Ultimately, the rationale behind this whole process is to improve UDP hole punching capabilities when port translation is in effect, and more generally, to make tinc more reliable in (very) hostile network conditions (such as multi-layered NAT).
2015-01-03 17:46:33 +00:00
"REQ_PUBKEY", "ANS_PUBKEY", "REQ_SPTPS", "UDP_INFO",
};
2007-05-18 10:05:26 +00:00
static splay_tree_t *past_request_tree;
2000-12-05 08:59:30 +00:00
/* Generic request routines - takes care of logging and error
detection as well */
2007-05-18 10:00:00 +00:00
bool send_request(connection_t *c, const char *format, ...) {
2002-09-09 21:25:28 +00:00
va_list args;
char request[MAXBUFSIZE];
int len;
2002-09-09 21:25:28 +00:00
2009-09-08 16:18:36 +00:00
/* Use vsnprintf instead of vxasprintf: faster, no memory
2002-09-09 21:25:28 +00:00
fragmentation, cleanup is automatic, and there is a limit on the
input buffer anyway */
va_start(args, format);
len = vsnprintf(request, MAXBUFSIZE, format, args);
2002-09-09 21:25:28 +00:00
va_end(args);
if(len < 0 || len > MAXBUFSIZE - 1) {
logger(DEBUG_ALWAYS, LOG_ERR, "Output buffer overflow while sending request to %s (%s)",
2002-09-09 21:25:28 +00:00
c->name, c->hostname);
2003-07-22 20:55:21 +00:00
return false;
2002-09-09 21:25:28 +00:00
}
logger(DEBUG_META, LOG_DEBUG, "Sending %s to %s (%s): %s", request_name[atoi(request)], c->name, c->hostname, request);
2002-09-09 21:25:28 +00:00
request[len++] = '\n';
2002-09-09 21:25:28 +00:00
if(c == everyone) {
broadcast_meta(NULL, request, len);
2003-07-22 20:55:21 +00:00
return true;
} else
return send_meta(c, request, len);
}
void forward_request(connection_t *from, const char *request) {
logger(DEBUG_META, LOG_DEBUG, "Forwarding %s from %s (%s): %s", request_name[atoi(request)], from->name, from->hostname, request);
2002-09-09 21:25:28 +00:00
// Create a temporary newline-terminated copy of the request
int len = strlen(request);
char tmp[len + 1];
memcpy(tmp, request, len);
tmp[len] = '\n';
broadcast_meta(from, tmp, sizeof tmp);
}
bool receive_request(connection_t *c, const char *request) {
if(c->outgoing && proxytype == PROXY_HTTP && c->allow_request == ID) {
if(!request[0] || request[0] == '\r')
return true;
if(!strncasecmp(request, "HTTP/1.1 ", 9)) {
if(!strncmp(request + 9, "200", 3)) {
logger(DEBUG_CONNECTIONS, LOG_DEBUG, "Proxy request granted");
return true;
} else {
logger(DEBUG_ALWAYS, LOG_DEBUG, "Proxy request rejected: %s", request + 9);
return false;
}
}
}
int reqno = atoi(request);
2002-09-09 21:25:28 +00:00
if(reqno || *request == '0') {
if((reqno < 0) || (reqno >= LAST) || !request_handlers[reqno]) {
logger(DEBUG_META, LOG_DEBUG, "Unknown request from %s (%s): %s", c->name, c->hostname, request);
2003-07-22 20:55:21 +00:00
return false;
2002-09-09 21:25:28 +00:00
} else {
logger(DEBUG_META, LOG_DEBUG, "Got %s from %s (%s): %s", request_name[reqno], c->name, c->hostname, request);
2002-09-09 21:25:28 +00:00
}
if((c->allow_request != ALL) && (c->allow_request != reqno)) {
logger(DEBUG_ALWAYS, LOG_ERR, "Unauthorized request from %s (%s)", c->name, c->hostname);
2003-07-22 20:55:21 +00:00
return false;
2002-09-09 21:25:28 +00:00
}
if(!request_handlers[reqno](c, request)) {
2002-09-09 21:25:28 +00:00
/* Something went wrong. Probably scriptkiddies. Terminate. */
2003-07-22 20:55:21 +00:00
logger(DEBUG_ALWAYS, LOG_ERR, "Error while processing %s from %s (%s)", request_name[reqno], c->name, c->hostname);
2003-07-22 20:55:21 +00:00
return false;
2002-09-09 21:25:28 +00:00
}
} else {
logger(DEBUG_ALWAYS, LOG_ERR, "Bogus data received from %s (%s)", c->name, c->hostname);
2003-07-22 20:55:21 +00:00
return false;
}
2000-10-29 00:02:20 +00:00
2003-07-22 20:55:21 +00:00
return true;
}
2007-05-18 10:00:00 +00:00
static int past_request_compare(const past_request_t *a, const past_request_t *b) {
2002-09-09 21:25:28 +00:00
return strcmp(a->request, b->request);
}
2007-05-18 10:00:00 +00:00
static void free_past_request(past_request_t *r) {
2002-09-09 21:25:28 +00:00
if(r->request)
free((char *)r->request);
2002-09-09 21:25:28 +00:00
free(r);
}
static timeout_t past_request_timeout;
static void age_past_requests(void *data) {
int left = 0, deleted = 0;
for splay_each(past_request_t, p, past_request_tree) {
if(p->firstseen + pinginterval <= now.tv_sec)
splay_delete_node(past_request_tree, node), deleted++;
else
left++;
}
if(left || deleted)
logger(DEBUG_SCARY_THINGS, LOG_DEBUG, "Aging past requests: deleted %d, left %d", deleted, left);
if(left)
timeout_set(&past_request_timeout, &(struct timeval){10, rand() % 100000});
}
bool seen_request(const char *request) {
past_request_t *new, p = {NULL};
2002-09-09 21:25:28 +00:00
p.request = request;
2007-05-18 10:05:26 +00:00
if(splay_search(past_request_tree, &p)) {
logger(DEBUG_SCARY_THINGS, LOG_DEBUG, "Already seen request");
2003-07-22 20:55:21 +00:00
return true;
2002-09-09 21:25:28 +00:00
} else {
new = xmalloc(sizeof *new);
2002-09-09 21:25:28 +00:00
new->request = xstrdup(request);
new->firstseen = now.tv_sec;
2007-05-18 10:05:26 +00:00
splay_insert(past_request_tree, new);
timeout_add(&past_request_timeout, age_past_requests, NULL, &(struct timeval){10, rand() % 100000});
2003-07-22 20:55:21 +00:00
return false;
2002-09-09 21:25:28 +00:00
}
}
2007-05-18 10:00:00 +00:00
void init_requests(void) {
2007-05-18 10:05:26 +00:00
past_request_tree = splay_alloc_tree((splay_compare_t) past_request_compare, (splay_action_t) free_past_request);
2007-05-17 23:14:42 +00:00
}
2007-05-18 10:00:00 +00:00
void exit_requests(void) {
2007-05-18 10:05:26 +00:00
splay_delete_tree(past_request_tree);
2007-05-17 23:14:42 +00:00
timeout_del(&past_request_timeout);
}