Routing and keying Questions

[sich]

Frithjof Hammer a écrit :
>> Yep, each node contact the other to distribute the network information.
>>     
> Can this be switched off? What exactly does the parameter "TunnelServer = 
> <yes|no> (no) [experimental]" do? The description sounds more or less like 
> it.
>   
Try this option.... Apparently this is for you.... This is experimental 
and I never try it, but apparently tinc would not communicate with node 
he doesn't know in the hosts directory.
>   
>> Tinc only give you a virtual interface.... Is your job to resolve
>> routing or filtering issue.
>>     
>
> What I meant was the routing done by the tinc daemon. It states on the tinc 
> website: 
>
> "VPN traffic is always (if possible) sent directly to the destination, without 
> going through intermediate hops."
>
> In other words: If it is not possible to send traffic directly, it will be 
> routed by the tincd. Correct?
>   
Yep, but you always need to take care about your routing table.
> This brings me to my next question: If there is no intermediate hop and both 
> nodes haven't the key from the other node, how can the traffic be encrypted? 
>   
If there is no intermediate the two node can't connect together... .If 
node A know node B, node B know node A and C, and node C know node B. 
Then A can communicate with B. But only if A and C are connected to B.

You can us the host option :

IndirectData = <yes|no> (no)

This option specifies whether other tinc daemons besides the one you 
specified with ConnectTo can make a direct connection to you. This is 
especially useful if you are behind a firewall and it is impossible to 
make a connection from the outside to your tinc daemon. Otherwise, it is 
best to leave this option out or set it to no.


With this node A can't connect directly with node C
>   
>> Use iptables for access restrictions.
>>     
> I don't like the Idea. The blocked far end could simple use a IP Address from 
> the range of the allowed nodes.
>   
Yep, but you need to have the good routing topology to do that.... If 
someone use ip range from node A on the node C, I doesn't think that 
will work....
>   
>>> * Is this (nodes can talk to eachother without having the crypto keys) the
>>> correct behavior?
>>>       
>> Yes, that's one of the advantages of using tinc.
>>     
>
> Then why use different keys for each node and not a shared key for everyone? 
>   
With this you can add or remove other node, or just stop the access 
right for one specific node without regenerating all the key....
> Greetings
> Frithjof
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>