On Wed, Feb 22, 2012 at 03:32:33PM +0000, Pedro Côrte-Real wrote: > 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).
I will see if it is possible to add something like this to the protocol in a backwards-compatible way. > > 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? The STUN protocol, as defined in RFC5389, is meant to be used in a stand-alone server, and is more complex than is necessary for tinc. The basic idea of STUN is used though; a third node that is in communication with two other nodes forwards the UDP address and port that the first one uses to the second, so the second can connect back to that exact address/port combination. This requires that the NAT device of the first node allows incoming packets from the second node on that address/port combination, also knows as "cone NAT". For more details, see http://en.wikipedia.org/wiki/Network_address_translation. Luckily, most cheap ADSL routers implement cone NAT. > Bringing it all together: > 1- If Address fields are specified try those This could indeed be added. At the moment, the Address field is only used when making the initials connections defined by ConnectTo statements. > 2- Try a direct connection to the IP address of the peer, reported > through the CentralNode (pontentially a private IP behind NAT) This needs support in the protocol. > 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 That is already in tinc. > If I understood you correctly currently tinc does 1 and 5 obviously > and a homegrown version of 4 but not 2 and 3. Tinc does 3. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[email protected]>
signature.asc
Description: Digital signature
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
