6 ms·
The NAT traversal logic here is really basic and won't hold up well in practice. A good chunk of NAT devices will pick external port based on [src ip/port, dst
by apankrat 5y ago
The NAT traversal logic here is really basic and won't hold up well in practice.
A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself.
STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use towards you if you were to try and connect now.
That is, you need to know the overloading pattern and then also time stuff correctly.
For that reason you will need a rendezvous server and it's also the best to let the server drive the whole process (as opposed to what STUN-based setups do, which is to let clients do it).
PS. In my past life I made a P2P VPN called Hamachi, which used all this stuff very extensively.
- jacobmischka 5y agoThanks for your work on Hamachi! I used it a few months ago to play a "LAN" game over the internet with friends, still works great (even on Linux)!
- bflesch 5y agoI loved hamachi! May I ask what you are up to nowadays?
- dncornholio 5y agoHamachi letted me play Command and Conquer online with my friends! We used Hamachi all the time to be able to play games online through LAN. Thank you so much for improving my childhoods quality of life :)
- minetest2048 5y agoDamn Hamachi brings back good memories of playing Borderlands 2 with my friends
- Shish2k 5y agoAnyone know if there are any open-source libraries which wrap this all into a usable `get_{tcp,udp}_connection(peer_id)` API, preferably with fallback to a relay server? I feel like there really should be, but nearly all the tools I’ve seen with this functionality are closed source, and the few open-source things all do their own custom logic rather than a shared library :/
- rytill 5y agoJust curious, what would you use this for and from what language?
- MayeulC 5y agoipfs? With ipfs p2p. It has swarm-mediated firewall traversal, and can fall back on relays within the swarm. Unfortunately, there hasn't been much progress on that funtionality, as the ipfs team seems to focus more on "crypto" lately. But it mostly works: http://docs.ipfs.io.ipns.localhost:8080/reference/cli/#ipfs-p2p http://docs.ipfs.io.ipns.localhost:8080/reference/cli/#ipfs-... and I guess this gives more context on relays: https://github.com/ipfs/go-ipfs/issues/7433#issuecomment-640888631 https://github.com/ipfs/go-ipfs/issues/7433#issuecomment-640... Otherwise, there is a useful library of firewall traversal libraries in any webrtc implementation.
- thejosh 5y agoHamachi was an absolute masterpiece in its first versions.
- harvie 5y agoThese are very cool p2p projects with nice NAT traversals. https://syncthing.net/ https://syncthing.net/ https://github.com/hyperswarm/hyperswarm https://github.com/hyperswarm/hyperswarm (whole family hypercore, hyperdrive, hyperswarm, ...)
- BitPirate 5y agoSyncthing uses the same logic that OP criticized. There is no rendezvous server from a NAT traversal perspective and also no port prediction. All peers simply lookup their external port via STUN and publish this information.
- gregors 5y agoI loved Hamachi! What do you suggest as a learning resource for things like this? The STUN RFC's? The Stevens' networking book?
- apankrat 5y agoIt's not a terribly complicated subject, but you do need a fair understanding of IP and UDP. TCP too, because it is possible to establish direct TCP connection through two NATs using the symmetrical open clause of the TCP handshake. Looks like magic when you see it work for the first time. Stevens' book is a must read, yes, but it has nothing even on NAT (iirc), leave alone on working around it. Look at how NAT works, what types of it exist, etc. Then look at "hole punching". For bonus points skim through p2p-hackers mailing list archives from 2003 and thereabouts. Very little has changed in this area since mid-00's, people just rediscover and re-implement the same thing over and over again. Few get it 100% right (IMO) due to sticking to prediction being done client-side. That's inferior to the server doing it, because it gets you more precise timing and better prediction rate.
- eliaspro 5y agoThis longer article from the Tailscale project also does a really nice job of explaining the complexities of doing this properly: https://tailscale.com/blog/how-nat-traversal-works/ https://tailscale.com/blog/how-nat-traversal-works/
- bloqs 5y agoHamachi saved many a teenage gaming session from connectivity issues. Thank you!
- trenchgun 5y agoI remember Hamachi as one of the nicest pieces of software I have ever used.
- crookshanked 5y agoWow, thanks for making Hamachi. Brings back memories of playing things like Starcraft and a few other games with a non local friend.