Hello, > My Questions: > * 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. > * What can I do get my desired behavior (only nodes sharing the keys of > eachother can talk) ? IP based firewalling, or point-to-point tunnels (which indeed means that you need one tunnel to connect 2 machines, but this can be simple IPIP or GRE tunnels, which do not involve userspace applications) > * 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? Sorry, I don't know. > * Is there a posibility to resolve the routing path through a tinc mesh? Same answer. Ivo ----- Original Message ----- From: "Frithjof Hammer" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, July 06, 2008 3:02 PM Subject: Routing and keying Questions > Hello! > > I use tincd to interconnect 3 LANs: A, B and C. So long, it works fine: > everybody reaches everybody. But I want a different behavior: A and B > should > be allowed to talk, as should B and C. I tried to simply delete the > host-files on the nodes that should not be allowed to talk to eachother: > > A has a hostfile from B > B has a hostfile from A and C > C has a hostfile from B > > But this is no use: I can still ping from A to C. My first thought was, > that > they use B as in intermediate hop. But as the ping-latency suggests, they > still talk to eachother directly: > > Ping from A to C via tinc: > 64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=77.5 ms > 64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=84.6 ms > 64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=77.1 ms > > Ping from A to C via WAN: > 64 bytes from x.t-ipconnect.de (217.80.x.x): icmp_seq=1 ttl=58 time=72.9 > ms > 64 bytes from x.t-ipconnect.de (217.80.x.x): icmp_seq=2 ttl=58 time=72.9 > ms > 64 bytes from x.t-ipconnect.de (217.80.x.x): icmp_seq=3 ttl=58 time=71.5 > ms > > As the roundtrip-times via tinc are only ~ 5-10ms higher than the rtt via > wan, > it B can't be in the middle. > > My Questions: > * Is this (nodes can talk to eachother without having the crypto keys) the > correct behavior? > * What can I do get my desired behavior (only nodes sharing the keys of > eachother can talk) ? > * 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? > * Is there a posibility to resolve the routing path through a tinc mesh? > > > 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? > > Thanks > Frithjof > _______________________________________________ > tinc mailing list > [email protected] > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
