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

Port opening supports below full-cone NAT #844

Open
jerry-wolf opened this issue Feb 26, 2017 · 10 comments
Open

Port opening supports below full-cone NAT #844

jerry-wolf opened this issue Feb 26, 2017 · 10 comments

Comments

@jerry-wolf
Copy link
Contributor

jerry-wolf commented Feb 26, 2017

Due to the lack of IPv4 address, more and more ISP have been deployed carrier-grade NAT. So less connectability for these users.
Tor network can improve the connectability for these users, but it has many issues for the users who needn't anonymity:

  • Poor performance.
  • Bring more pressure for Tor relay bridge.
  • Tor is blocked in some country or ISP.

IPv6 is the ultimate solution, but it still have a long way to go. (15% supportive in the whole world, and only 1% supportive in China)

Full-cone NAT is most used in carrier-grade NAT and easy to penetrate.
We need do these thing for support port opening supports below full-cone NAT

  • Send port checker a request for external IP and external port.
  • Separated port number with internal port number and external port, listen the internal port and report tracker the external port.
  • Keep port mapping exist using heartbeat packet.

Separated port number is also useful in the environment:

  • I don't have the manage permissions of router, but I can ask my administrator to open ramdom one.
  • Free reverse proxy services such as ngrok.
@HelloZeroNet
Copy link
Owner

Why is it necessary to send different port to the tracker and bind an another on the local machine? If you want to use different port, then you can use that on local machine.

@jerry-wolf
Copy link
Contributor Author

jerry-wolf commented Feb 26, 2017

Port mapping is up to NAT gateway. The gateway create a random port mapping that has different port number, sometimes we can't control it (Like carrier-grade NAT).
See: https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation
Full-cone NAT: If client below NAT send a request to a host which opened a port, the full-cone NAT gateway will assign a port mapping about internal_IP:internal_port(the port which the client send a request) <-> external port(randomly assigned). We can't set a port mapping without administrator permission.
For home router, the methods of translation is usually (address)-restricted-cone NAT. It has more restriction, but we can set a port mapping manually or automation (via UPnP). So I think penetrate carrier-grade NAT and home router and open a port is still feasible.

@HelloZeroNet
Copy link
Owner

And how do we know the randomly assigned port number?

@jerry-wolf
Copy link
Contributor Author

jerry-wolf commented Feb 27, 2017

For some gateway, we can open a port by Port Control Protocol, but it's not all gateway be supported.
A client connect to a port checker, then the port checker can get the external IP and external port of the client with data, address = socket.recvfrom(bufsize[, flags]), then the port checker echo back to the client.
Perhaps we can depend STUN.
It's centralized, but I think that add a plugins to make every peers which can open a port is feasible.
But I'm not sure whether it's TCP-compatible.

@HelloZeroNet
Copy link
Owner

HelloZeroNet commented Feb 27, 2017

The port checker can't get your external port as it not used in the connecting process (and you can have many of them), only your external ip.

It could be possible to add nat-pmp function for port opening, but I think upnp is more supported. I just tried https://pypi.python.org/pypi/NAT-PMP/1.0.1 and it's not working with my router.

@jerry-wolf
Copy link
Contributor Author

I'm afraid that you did not understand what I meant. Not all NAT gateway allow standard user create a explicit port forward rule, but we can create a implicitly port forward rule using full-cone NAT gateway's feature.

  • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort are sent through eAddr:ePort.
  • Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.

@hellomygitworld
Copy link

I agree with @l5h5t7

@HelloZeroNet
Copy link
Owner

I don't have access enviroment like this, so it would be hard to develop for it.

@sergei-bondarenko
Copy link
Contributor

It need's a lot of work. Maybe better spend this time developing IPv6 support? #148

@mkg20001
Copy link
Contributor

It need's a lot of work. Maybe better spend this time developing IPv6 support? #148

Yes and no. Both things are required because I don't think that IPv6 support will be high enough everywhere to solve the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants