Understanding tinc edge connections and re-routing

[Guus Sliepen]

On Sun, Jan 13, 2013 at 10:05:03PM +0200, Ville Mattila wrote:

> As far as I have understood, after tinc has established a connection with
> another host, these hosts will exhange information about other known hosts
> in the network, no matter if the hosts are  defined in /hosts/*
> configuration files. Each succesfully connected host tries to establish a
> direct connection with every other host in the mesh and thus creates
> more edges to the mesh. Is that correct? How long it generally takes after
> the initial connection that the new host has created connections with all
> other hosts? Which configuration directives have effect in this operation?

There are actually two kinds of connections tinc makes. The first kind is the
"meta connection", which is what you specify with ConnectTo. These connections
are used to exchange information about other known hosts, and can also be used
as a fallback to tunnel VPN packets if all else fails.

The second type is the UDP connection. When you try to send a packet to
another node, tinc will try to establish direct communication with that node via.
If that is not possible, tinc will try to send the packets via an intermediate
node or in the worst case, completely fall back to the backbone of meta
connections.

The UDP connections are made on demand.

> In case two hosts are not directly connected with each other, the traffic
> goes first through the intermediate hosts until tinc has found the shortest
> route. Still correct? In my example, ping packet from H4 to H5 goes first
> to S1, then S2 and finally reaches H5. As soon as S1 communicates
> information about S2 to H4, H4 can connect S2 directly and packets from H4
> to H5 do not go over S1 anymore. Further, if H4 can connect H5 directly
> (firewalls etc allow it), traffic may start to flow between H4 and H5
> without any intermediate hosts. Am I still on track?

Yes. Although to be absolutely correct, with the default configuration options,
H4 will never send packets directly to S2, instead if it cannot reach H5
directly (yet), it will always forward packets via the next hop, S1, who can
then send them directly to H5 if possible.

> Let's suppose that one of the intermediate hosts, like S2, fails. H5 was
> connected initially only to S2, but if I understand correct, there should
> be also a connection to S1 if the mesh is mature? In this case, traffic
> from/to H5 should get rerouted via S1 as far as H5 finds edge to S2 down.
> Correct? How long it approximately takes (after a failure) to find a
> new route for the traffic? What configuration directives are in effect here?

No, in this case there is no more meta connection between H5 and the rest of
the VPN, and it is isolated. This is a limitation of tinc. This is somewhat
deliberate; the main reason for this limitation is that a node is granted
access to the VPN when one ore more other nodes have exchanged their public
keys with that first node.  Access can be revoked by removing that node's host
config file from those other nodes. If tinc would automatically try to maintain
connetions between all other nodes, it would be very hard to revoke access to a
specific node.

In tinc 1.1 there is a way for tinc to automatically create more meta
connections besides those specified with ConnectTo statements.And in the future
there will be a better way of access control. 

> I tried to make an experiment but for some reason, my mesh network requires
> that both S1 and S2 are running. If I shut one of them down, the network
> gets partitioned and I can't ping other hosts anymore. That's why I am
> asking the questions above whether I even understand the theory behind tinc
> correctly.

I suggest you have both "ConnectTo = S1" and "ConnectTo = S2" in the other
nodes' tinc.conf files. Or, try out tinc 1.1 and use the AutoConnect option.

http://tinc-vpn.org/documentation-1.1/tinc_4.html#index-AutoConnect

> Thanks for any comments, confirmations, corrections, further questions,
> links to study material... anything. :)

See also the section "Plans for 2.0" in http://tinc-vpn.org/goals/. I should
update that document, most of the plans for 1.1 have already been
implemented...

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20130113/512e1d91/attachment.pgp>