node.jssocketscurlhole-punching

UDP punch hole for a web-server?

For my academic project, I am trying to achieve this. A web server node JS application listening on port 3000. So If you curl http://localhost:3000 you will get Hello World!. ( A simple web page.

Now I am running above webserver in my local machine. And my modem is behind NAT. Suppose If I port forward in the modem to myip:3000 then it is open to the world. But here is the biggest thing I am stuck - I don't want to use the modem for port forwarding, instead, I will use third party server for UDP Punch Hole.

Now my requirement is anyone from net should able to access my webserver at curl http://third-party-server-ip:3000.

What I am trying is to write another client - which opens a connection to the third party server. Say it did a hole punching at port 41234. That port is open. The third-party host can send something to that port.

Now anyone in the internet initiate this command curl http://third-party-ip:3000 to the third party host. So the third party returns the myip:udpPunchHolePort i.e., myip:41234.

anyone will again curl to myip:41234 it will be received by the node js UDP punch app, so it will redirect to localhost:3000. Finally, the anyone will receive the response from localhost:3000.

My two questions -

  1. Is there any better way than the one I proposed here?
  2. Is there any well-known node-js lib for this kind of stuff, I see, I can use UDP punch hole. Or I am thinking to write a Lib to do this in general - does this sounds like re-inventing the wheel?

Note - In this academic project, we are trying to learn how to make any local application open to the world without port forwarding in the modem.

We read on skype protocol analysis, that is also our inspiration.

Flow of request

Solution

  • No, that won't work.

    1. HTTP runs over TCP, not UDP. Punching a UDP hole doesn't do you any good -- any TCP connection to the backend HTTP server will still fail.

    2. HTTP redirects are not magic. If a user cannot access a specific host:port, redirecting them to a URL on that host:port will just make their browser time out when it requests that URL.

    3. You cannot send a response from a different host:port from what the browser requested, because there is no TCP connection established with that endpoint.