"Mode Switch" and "Tunnelserver Yes" cause unnecessary traffic to clients (proposed patch)

[Guus Sliepen]

On Mon, Apr 12, 2010 at 01:18:40PM +0200, ZioPRoTo (Saverio Proto) wrote:

> OK, to do not complicate things I did not explain the all story.
> I'm implementing the algorithm explained in this paper:
> http://aquila.netgroup.uniroma2.it/~saverio/ICT2010Detti.pdf

Aha, that's a very interesting paper!

> The key idea is that if you have 50+ nodes it takes too much memory to
> have ~50 VPN links. So you make links only to few nodes, and you route
> inside the VPN. Read the paper for details if you want.

The paper assumes that if I have a full mesh VPN with N nodes, each node will
always have N-1 connections active, and is running some kind of routing
protocol over that. It would indeed be very costly then, although I did some
tests in the past and N=50 would not be a problem at all for today's hardware
(including embedded systems).

The fact is that if you have a full mesh, you do not need to run a routing
algorithm anymore, since you know you have a direct connection anyway. In that
case, you only need to know a list of subnets and which public IP address to
send packets to. This can scale to 10000+ nodes without problems. But, with
today's Internet not all nodes will be reachable directly, so you would need to
have some routing algorithm to find a suitable path.

With tinc you can set up only a small number of permanent connections (with the
ConnectTo statement), so that you will have a relatively sparse distance
matrix. Since the link state information will contain the public address of
each node, when node A tries to contact a node B with which it does not have a
direct connection, it will first try to send UDP packets directly. If this
fails, tinc will fall back to the graph of known working connections.

Indeed, limitting the total number of connections in the whole VPN will
increase scalability. And it would be nice to have tinc automatically ConnectTo
other nodes in the best possible way instead of having to do that manually.

> To do so I wrote a python script, that creates a configuration file
> for tinc after running the algorithm runs tinc.
> 
> The implementation will be Free Software, and it would be cool also to
> distribute it with tinc, so people can use the result of this research
> activity. Now it is very early stage with don't have any release yet.

That would be great!

> > I think it would be better if you set IndirectData = yes in the server's
> > tinc.conf, that would force all traffic to go via the server.  TunnelServer is
> > not really compatible with switch mode (unless you configure MAC Subnets
> > statically).
> 
> I'm reading here:
> http://www.tinc-vpn.org/documentation/tinc_4.html#Configuration
> 
> I don't understand this IndirectData option :( Maybe is a language problem.

The name of that option is a bit unfortunate.

> "IndirectData = yes" means that tincd will not try to make other VPN
> connections than the ones specified with ConnectTo statements ?

Yes. This was implemented mainly because old versions of tinc did not check
itself whether it could make direct connections via UDP. For nodes behind
firewalls or NAT devices, this would tell tinc to forward packets only via the
nodes it had ConnectTo statements to.

> If node N sets "IndirectData = Yes" and does not have any ConnectTo
> statement (this is the server config) other nodes will be able to
> connect to the node with this configuration ?

IndirectData only limits how VPN packets are routed, it does not limit incoming
TCP connections. So other nodes can still ConnectTo a node that has
IndirectData set, and afterwards they can exchange VPN packets via this
connection.

> The IndirectData yes/no must be consistent on every node ?

No. The IndirectData property is something that can be set per connection, and
if one node has set it on a connection but the other has not, then after the
connection is activated they will both treat it like it has been set.

> > Anyway, why do you want to prevent clients from communicating directly to each
> > other? That would be more efficient.
> 
> Well, I hope now my goal is clear :)

Yes :)

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