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
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" <mail op frithjof-hammer.de> To: <tinc op tinc-vpn.org> 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 > tinc op tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Frithjof Hammer a ?crit :> My Questions: > * Is this (nodes can talk to eachother without having the crypto keys) the > correct behavior? >Yep, each node contact the other to distribute the network information.> * What can I do get my desired behavior (only nodes sharing the keys of > eachother can talk) ? >You can build 2 different network. So there is no problem to share the keys. Then on B you have 2 tincd daemon on 2 different port and 2 different configuration. Then you start your 2 tincd with the network name like tincd -n vpn1 and tincd -n vpn2. The other way is to configure your firewall to only allow traffic that you want.> * 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? >I don't know this.> * Is there a posibility to resolve the routing path through a tinc mesh? >Tinc only give you a virtual interface.... Is your job to resolve routing or filtering issue.> > 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. >Then work with static routing or configure your firewall if you don't wan't to have multiple vpn daemon...> Any hints? > > Thanks > Frithjof > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >
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