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 > [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
