Routing and keying Questions

Maksuf maksuf at gmail.com
Sun Jul 6 21:58:31 CEST 2008


Hi!

> My Questions:
> * Is this (nodes can talk to eachother without having the crypto keys) the
> correct behavior?

They can talk to each other, yes, but (in my experience) I am almost certain 
they cannot connect to each other directly.

> * What can I do get my desired behavior (only nodes sharing the keys of
> eachother can talk) ?

As Ivo and sich suggested, you could try firewall rules or two separate 
daemons.

> * sending a killall -USR2 tincd gets me a lot of nice debug stuff. Is there
> a documentation what is meant by the option value and the weight value? 

Node weights are the approximate latency of the node. Higher weight = slower 
node. They're currently used for calculating the minimum spanning tree of the 
network, for tinc metadata broadcast.

Options is a hex representation of the current options of the 
node/connection/edge, etc. 

From src:
#define OPTION_INDIRECT   0x0001
#define OPTION_TCPONLY    0x0002
#define OPTION_PMTU_DISCOVERY 0x0004

> * Is there a posibility to resolve the routing path through a tinc mesh?
>

I'm not entirely sure what you mean.

>
> I don't want to setup two vpns because my scenario is more complex: It
> involves seven nodes and I want to define for each and everyone of them to
> which other nodes they may talk to.
>
> Any hints?

Look into TunnelServer, it might be what you want. You'd probably want to set 
it on B.

Oh yes, one thing that might help you out, send a USR1 signal to tinc, to 
output all direct connections.

>
> Thanks
> Frithjof

-- 
 Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part.
Url : http://www.tinc-vpn.org/pipermail/tinc/attachments/20080706/ae8b9eff/attachment.pgp 


More information about the tinc mailing list