Unauthorized ADD_SUBNET, but known subnet

Ivan Vilata i Balaguer ivan at selidor.net
Mon May 27 11:05:43 CEST 2013


Guus Sliepen (2013-05-23 10:40:06 +0200) wrote:

> On Wed, May 22, 2013 at 04:23:39PM +0200, Ivan Vilata i Balaguer wrote:
>
>> I'm using a tinc 1.0.19 (from Debian Squeeze) setup with some nodes
>> connecting to a "server" node which has "StrictSubnets = yes".
>> Whenever a new node is added to the mesh, a process generates and
>> drops its host file in the server's host directory before the node is
>> booted and tries to connect. […]
>> 
>> Any ideas on why the server needs the HUP?
>
> The server needs the HUP so it will reread the host config files and
> update its list of approved Subnets. However, the validity of a Subnet
> that a node announces is only checked when that node announces its
> Subnet. So the best way is to make sure the server gets the new host
> config file and a HUP signal before the new node comes online.

Thanks for the explanation, Guus.  What I didn't mention (and is indeed
the reason for my surprise) is that in another setup using nearly the
same software environment, we checked that tinc doesn't need the HUP to
accept new nodes!  The main difference is that the first one is an LXC
container and the second one a physical host.  Go figure.  Anyway I
guess it's better to play safe and send the HUP.

>> Moreover, although it doesn't accept the subnet itself, the server
>> forwards the ADD_SUBNET to other nodes (in the tests they are on the
>> same network link and only know the server to which they ConnectTo)
>> so other nodes can ping the newly added node but the server cannot.
>> The problem is that I need to contact services running in the server
>> from the node. :-/
>> 
>> There's also the question whether forwarding such an untrusted
>> network makes sense (can it be disabled?), but that's another
>> topic...
>
> There are various options that control forwarding of information. You
> might want to use the TunnelServer option in your case.

In our setup we want some core nodes to have the host files of all nodes
in the tinc network and connect among themselves, and other "peripheral"
nodes to only have the file of the core node they ConnectTo, but still
be able to exchange data directly with other nodes if the underlying
network allows it.  Thus we do want to forward all the information in
core nodes, but only if it matches what the known host file states.  In
other words, whenever the node would print "Ignoring unauthorized
ADD_SUBNET from X" it would not forward the info for node X, so core
nodes would act like some kind of authenticators.  But well, with the
warning we're at least able to spot rogue nodes. ;)

Thanks for your help!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/



More information about the tinc mailing list