Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NAT Traversal #104

Closed
daviddias opened this issue Jul 9, 2017 · 18 comments
Closed

NAT Traversal #104

daviddias opened this issue Jul 9, 2017 · 18 comments
Assignees
Labels
exp/wizard Extensive knowledge (implications, ramifications) required help wanted Seeking public contribution on this issue status/ready Ready to be worked

Comments

@daviddias
Copy link
Member

daviddias commented Jul 9, 2017

Currently, the only mechanism to pierce through NATs in js-libp2p is the WebRTC transport. NAT Traversal is a feature that is hard to get 100% complete as there will be always more NAT implementations that will not work with the strategies we have in place. Ultimately the last resort is Relay (Circuit or Packet Switched).

There is plenty of work available for NAT Traversal, WebRTC is kind of a canon to solve this problem, but not every peer will have WebRTC neither we can trust WebRTC 100% of the times.

Here is a list of good resources to get started:

The next milestone for Relay is to support UPnP for TCP ports, the same way go-ipfs does.

@daviddias daviddias added exp/wizard Extensive knowledge (implications, ramifications) required exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue labels Jul 9, 2017
@daviddias daviddias mentioned this issue Jul 9, 2017
@daviddias daviddias added the status/deferred Conscious decision to pause or backlog label Jul 9, 2017
@daviddias
Copy link
Member Author

One more resource: - https://nice.freedesktop.org/wiki/

@dryajov dryajov self-assigned this Oct 26, 2017
@daviddias daviddias added status/ready Ready to be worked and removed status/deferred Conscious decision to pause or backlog labels Feb 5, 2018
@daviddias daviddias removed the exp/expert Having worked on the specific codebase is important label Feb 5, 2018
@agahEbrahimi
Copy link

So there aren't any NAT Traversal techniques in js-libp2p? Not even Nat Port mapping?

@dryajov
Copy link
Member

dryajov commented Apr 16, 2018

Work on this is planned already, and will begin very soon.

@makew0rld
Copy link

Can't ipfs's NAT traversal just be reimplemented here? Why is it being worked on separately?

@dryajov
Copy link
Member

dryajov commented May 29, 2018

Quick update and outline of what is currently being worked on:

  • I've put together an initial implementation of a nat mapper that will allow creating port mappings using different available techniques (upnp, pmp, pcp, hole punching, etc...). Currently, pmp and upnp are being supported, with pcp and hole punching planed once the rest settles in.
  • A dialme protocol has been proposed here - RFC: dialMe protocol specs#64
    • this will allow us to request dial backs on mapped public ports from clients dialed over a relay, thus allowing to upgrade circuited connections to direct ones if that is possible

@dryajov
Copy link
Member

dryajov commented May 31, 2018

I've added an issue describing the NAT flow here - #200

@mateodelnorte
Copy link

Hi all. What's the current state of affairs here? Any way for additional individuals to help out?

@jacobheun
Copy link
Contributor

We are planning on picking this back up this quarter, it's just lower on the priority list at the moment. The next steps for moving this forward are to finalize the specs, libp2p/specs#64, and work on getting the initial work of the nat manager finished, libp2p/js-libp2p-nat-mngr#1.

The spec will be the big blocker to get resolved, so that nat manager can get moving again. There are a lot of considerations that need to get figured out, so any additional help/support there would be great!

@agentofuser
Copy link

Hi! Is this on the table for Q2? It would be really nice to have for ipfs-deploy.

@jacobheun
Copy link
Contributor

Hi! Is this on the table for Q2? It would be really nice to have for ipfs-deploy.

Yes. This is on my list for the quarter and I am hoping to tackle this as well as #202 to help node addressing.

@suutaku
Copy link

suutaku commented Jul 9, 2019

Somebody said NAT traversal using libp2p-webrtc-star works. I have tried wrtc + libp2p-webrtc-star, but it's not working.

const wr= new WRTC(
      { id: _options.peerInfo.id,
        wrtc: wrtc
      })

can somebody give an example or some docs?

@jacobheun
Copy link
Contributor

@suutaku what does your network setup look like in terms of libp2p nodes? Are you connecting both nodes to the same signaling server? The chat example at https://github.com/libp2p/js-libp2p-examples/tree/master/chat provides a setup that includes a node client, a node bootstrap node (with signaling server), and a browser client. I have not had the chance to test that across networks yet though.

I am out next week but will be continuing work on the AutoNAT protocol in js when I am back.

@suutaku
Copy link

suutaku commented Jul 11, 2019

Welcome to back! we need you @jacobheun
I tested both chat and libp2p-in-the-browser example in my network and also set relay enabled(I don't know if it is work).
I have tow routers. node A connected router A, node B connected router B.
node A address 192.168.0.100
node B address 192.168.199.132
A,B can not discoveried each other. but if I change node B to connect router A. everything is OK.

@jacobheun
Copy link
Contributor

@suutaku are they both connected to a signaling server? You'll need to add listening addresses to both nodes for the signaling server, until we get a decentralized signaling protocol in place.

This is adding a local address,
https://github.com/libp2p/js-libp2p-examples/blob/d17d5d2f97a592a2441b8dddb305c96b839cf660/chat/browser/08-End/libp2p.js#L16, but you will need to use a common signaling server both your nodes can hit. We currently host one for testing, https://github.com/libp2p/js-libp2p-webrtc-star#hosted-rendezvous-server, but I am not sure if that has been blocked yet in China or not. If you have a common local gateway you can try running the signaling server also mentioned in that readme.

@suutaku
Copy link

suutaku commented Jul 22, 2019

@jacobheun thank you! I tried as you said. it's worked but not well. I mean I start a signaling server
and get /dns/peer.xxxx.com:/8088/ws/p2p-webrtc-star/.
local peers added _options.peerInfo.multiaddrs.add("/dns4/peer.xxxx.com/tcp/8088/ws/p2p-webrtc-star/p2p/${_options.peerInfo.id.toB58String()}");

only sometime it worked. most time they can not find each other.

@suutaku
Copy link

suutaku commented Jul 22, 2019

by check log info. I found:

1. peer discovery was OK.

peer can be discovered.

2. dial was failed.

error info:
No available transports to dial peer
my transport :

const wrct = require('wrtc')
const webrtcStar = new WebrtcStar({ wrtc: wrct })
transport: [
          TCP,
          new WebSockets(),
          webrtcStart
          
        ],

and listening on:

info.multiaddrs.add("/ip4/0.0.0.0/tcp/0");
info.multiaddrs.add("/ip4/0.0.0.0/tcp/0/ws");
info.multiaddrs.add(`/dns4/peer.xxxxx.com/tcp/8088/ws/p2p-webrtc-star/p2p/${info.id.toB58String()}`);

Update

@jacobheun have did some test and research. I found NAT traversal is a big problem in China. by my case. internet works like:

public network --> NAT1 --> NAT2 --> NAT3 --> my router --> my device

maybe is difficult to punch a hole?
so if it's difficult, how about circuit relay?
I noticed js-libp2p have relay configure option

 relay: { 
          enabled: true, 
          hop: { 
            enabled: true,
             active: true 
          } 
        },

and also not working........

Update agin

by launch a relay node with public ip, problem solved.

@jacobheun
Copy link
Contributor

@suutaku hole punching definitely is not 100%. WebRTC has our only method of doing this in JS right now. There are other NAT traversal techniques we're working on adding, but circuit relay is the best interim solution, assuming you have a dialable relay that both nodes are connected to. I am going to post some notes today on #385, which is likely going to require some more improvements to how circuits and webrtc signaling are done to help with this.

For the relay config I'm adding some comments below to try and help clarify. Note, your relay node must be dialable, and both your other nodes must be connected to it at the moment. I'm looking to improve this with the work for #385.

relay: { 
  enabled: true,  // This line means your node is dialable over a Relay, but doesn't make it a relay itself
  hop: { 
    enabled: true,  // `true` means your node is a relay. So if two nodes are connected to it, it should relay their dials to one another
    active: true  // `true` means your node will attempt to actively dial the requested peer. This is likely not going to work in your situation, since your nodes aren't dialable.
  } 
}

@p-shahi
Copy link
Member

p-shahi commented May 30, 2023

closing in favor of #1461
AutoNat has landed #1005
hole punching in the browser is possible via private-to-private/browser-to-browser https://github.com/libp2p/js-libp2p-webrtc

@p-shahi p-shahi closed this as completed May 30, 2023
achingbrain pushed a commit that referenced this issue Jun 27, 2023
Bumps [aegir](https://github.com/ipfs/aegir) from 21.10.2 to 22.0.0.
- [Release notes](https://github.com/ipfs/aegir/releases)
- [Changelog](https://github.com/ipfs/aegir/blob/master/CHANGELOG.md)
- [Commits](ipfs/aegir@v21.10.2...v22.0.0)

Signed-off-by: dependabot-preview[bot] <[email protected]>

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/wizard Extensive knowledge (implications, ramifications) required help wanted Seeking public contribution on this issue status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

9 participants