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