On Wed, Feb 22, 2012 at 2:28 PM, Guus Sliepen <[email protected]> wrote: > On Wed, Feb 22, 2012 at 01:40:20PM +0000, Pedro Côrte-Real wrote: > The current protocol does allow a client to send its own address to others. > However, perhaps it could detect that it is trying to connect to a node that, > as seen form CentralNode, has the same address as itself.
The simple algorithm I imagine is to just have the peers swap IP addresses through central node and see if they can just open a connection directly using those. This is simpler and more effective than figuring out if you're on the same subnet as that might not be the case and yet everything could still be routable (e.g., node A is on 10.0.0.1/24 and node B on 192.168.1.1/24 but they're actually two subnets of the same private installation). This would work for situations without NAT at all as well. If you have three peers all with public IP addresses and configure them this way, the two leaves will figure out they can just talk with one another without any Address fields in their configuration. This would be useful for hosts that have dynamic ip addresses, making it hard to specify a proper Address. > At the end of 2010 year two ways to deal with this were proposed, one by > Daniel > Schall and one by me, but nothing happened. In the last months there > apparently > has been an increased interest in a way for tinc to detect local peers, so I > will try to get this merged before the next release. > >> If they're behind the same NAT it would work and if not >> it would just continue to go back and forth to CentralNode. In that >> situation it would ideally use something like STUN so it could do away >> with the central node even when both hosts are behind two different >> NATs. > > If they are not behind the same NAT, tinc does use a STUN-like technique to > allow the Leafs to talk to each other directly (if the NAT devices allow > that). I just read that this was added to 1.0.12. It seems the version that ships with the current Ubuntu LTS is 1.0.11 so I didn't have that update. Could you clarify what you mean by STUN-like and "if the NAT devices allow"? Why not just use STUN itself? Bringing it all together: 1- If Address fields are specified try those 2- Try a direct connection to the IP address of the peer, reported through the CentralNode (pontentially a private IP behind NAT) 3- Try a direct connection to the IP address of the peer as seen by CentralNode (as you suggested in case the router at the border forwards packets back) 4- Use STUN to allow connecting between two NATs 5- If all else fails and while the other stuff is happening just route everything through CentralNode If I understood you correctly currently tinc does 1 and 5 obviously and a homegrown version of 4 but not 2 and 3. For me 2 is the low-hanging fruit and I'll have to try a newer version to see if the homegrown STUN works for me. Thanks for the reply, Pedro _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
