Enable the circuit relay protocol (the EnableRelay option).
Pick some set of nodes that you want to use as relays.
Advertise these addresses using the AddrsFactory option.
Eventually, we'd like to automate the second two pieces but that means we'd need an automated way to find and pick good relays.
Canned NAT traversal explanation: We have three nat-traversal solutions at the moment.
UPnP/NATPortMap
When NAT traversal is enabled (in go-libp2p, pass the NATPortMap() option to the libp2p constructor), libp2p will use UPnP and NATPortMap to ask the NAT's router to open and forward a port for libp2p. If your router supports either UPnP or NATPortMap, this is by far the best option.
STUN/hole-punching
LibP2P has it's own version of the "STUN" protocol using peer-routing, external address discovery, and reuseport. LibP2P:
Uses the same source port for both dialing and listening (reuseport).
Receives observed address information from all connected peers (external address discovery).
Publishes these addresses to the network (peer routing).
On some NATs, the first feature allows us to accept new inbound connections on the source port used by the router (the "mapped" source port).
The second feature allows us to discover this mapped source port and our external address.
The third feature allows us to tell the network about this external address.
TURN-like protocol
Finally, we have a TURN like protocol called p2p-circuit. This protocol allows libp2p nodes to "proxy" through other p2p nodes. Unfortunately, neither go-libp2p nor js-libp2p announce p2p-circuit addresses at the moment (by default). This means that it doesn't just automagically bypass NATs (yet).
The next steps here are to:
Have all nodes behind NATs connect to "hub" nodes that volunteer to act as p2p-circuit relays.
Announce to the network that we're accepting relay connections from these nodes.
Corporate Firewalls
While technically a different issue, this still falls under the category of working around meddlesome middle boxes.
Currently, we don't have any good ways to work around corporate firewalls. However, we have an issue (ipfs/go-ipfs#5251) to enable the websocket listener by default on go-ipfs which will help significantly because this transport supports HTTP proxies out of the box. Note: This won't be fully solved until p2p-circuit becomes fully automatic as proxy support only allows us to dial, not listen.
credit to @Stebalien for a nice description.
NAT Traversal w/ TURN-like protocol
The almost-always works answer is:
Eventually, we'd like to automate the second two pieces but that means we'd need an automated way to find and pick good relays.
Canned NAT traversal explanation: We have three nat-traversal solutions at the moment.
UPnP/NATPortMap
When NAT traversal is enabled (in go-libp2p, pass the NATPortMap() option to the libp2p constructor), libp2p will use UPnP and NATPortMap to ask the NAT's router to open and forward a port for libp2p. If your router supports either UPnP or NATPortMap, this is by far the best option.
STUN/hole-punching
LibP2P has it's own version of the "STUN" protocol using peer-routing, external address discovery, and reuseport. LibP2P:
TURN-like protocol
Finally, we have a TURN like protocol called p2p-circuit. This protocol allows libp2p nodes to "proxy" through other p2p nodes. Unfortunately, neither go-libp2p nor js-libp2p announce p2p-circuit addresses at the moment (by default). This means that it doesn't just automagically bypass NATs (yet).
The next steps here are to:
While technically a different issue, this still falls under the category of working around meddlesome middle boxes.
Currently, we don't have any good ways to work around corporate firewalls. However, we have an issue (ipfs/go-ipfs#5251) to enable the websocket listener by default on go-ipfs which will help significantly because this transport supports HTTP proxies out of the box. Note: This won't be fully solved until p2p-circuit becomes fully automatic as proxy support only allows us to dial, not listen.