针对Web服务器的UDP打洞技术？

Question

针对Web服务器的UDP打洞技术？

9

为了我的学术项目，我正在尝试实现以下内容。一个监听在3000端口的web服务器Node JS应用程序。因此，如果您curl http://localhost:3000，您将获得Hello World！（一个简单的网页）。

现在我在本地机器上运行上述Web服务器。我的调制解调器位于NAT后面。假设我在调制解调器中进行端口转发到myip:3000，那么它就会对外开放。但这里我遇到了最大的问题-我不想使用调制解调器进行端口转发，而是要使用第三方服务器进行UDP打洞。

现在我的要求是任何来自网络的人都可以访问我的Web服务器curl http://third-party-server-ip:3000。

我正在尝试编写另一个客户端-它打开到第三方服务器的连接。假设它在端口41234上进行了打洞。该端口已经打开。第三方主机可以向该端口发送一些内容。

现在，任何人都可以在互联网上启动此命令curl http://third-party-ip:3000到第三方主机。因此，第三方返回myip：udpPunchHolePort即myip:41234。

任何人再次curl到myip：41234，它将被node js UDP punch应用程序接收，因此它将重定向到localhost:3000。最后，anyone将从localhost:3000接收响应。

我的两个问题是-

1.是否有比我提出的更好的方法？

2.是否有任何著名的node-js库可用于此类操作，我可以使用UDP punch hole。或者我正在考虑编写一个通用的Lib来执行此操作-这听起来像重新发明轮子吗？

注-

在这个学术项目中，我们正在尝试学习如何使任何本地应用程序在调制解调器中无需端口转发即可开放给世界。

我们在Skype协议分析中阅读到了内容，这也是我们的灵感来源。

- ajayramesh

3

不清楚你在这里为什么要使用UDP。你试图将第三方主机用作代理，以代替“防火墙后面”的主机。有许多架构方法可以做到这一点。我能想到的最简单的方法是，“防火墙后面”的服务器向第三方代理打开一个连接。因为此连接是出站连接，所以它将被允许，而且因为连接是持久的，双方都可以通过连接发送数据。因此，您的第三方代理可以随时向“防火墙后面”的服务器发送任何数据。 - jfriend00

2

所有使用socket.io或webSockets的浏览器页面都能获得同样的好处。防火墙后面的客户端连接到服务器，从而允许服务器随时向它们发送数据，即使它们位于防火墙后面。大多数聊天客户端都使用类似的技术。 - jfriend00

1

你好@Sam，你确实在重新发明轮子。你只需要在中间加入nginx代理服务器即可。我们在当前项目中正在这样做。每次发送请求时，它都会经过nginx代理服务器，然后由nginx将请求发送到你的应用程序http://localhost:3000。这里有nginx的详细手册https://www.nginx.com/resources/admin-guide/reverse-proxy/。 - Inder R Singh

1

@InderRSingh NGINX运行在第三方机器上，无法穿越NAT到本地机器。 @Sam 我觉得这个问题可以通过SSH反向隧道轻松解决。假设第三方的sshd启用了“GatewayPorts yes”设置，则ssh -R 80:localhost:3000 user@thirdpartyip。 - Magnus

1

@Sam SSH隧道不会有所帮助。它要求防火墙运行SSH服务器，而这实际上几乎永远不可用。那些（极其罕见的、通常是自制的）带有SSH服务器的防火墙几乎总是同时支持端口转发和/或UPnP。 - user149341

显示剩余7条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user149341 · Accepted Answer

不行，这样做行不通。

HTTP是运行在TCP上的，而不是UDP。打洞一个UDP洞并没有什么用，因为对于后端的HTTP服务器的任何TCP连接都将失败。
HTTP重定向并不是魔法。如果一个用户无法访问特定的主机:端口号，将其重定向到该主机:端口号上的URL只会使他们的浏览器在请求该URL时超时。
您无法从与浏览器请求不同的主机:端口发送响应，因为没有与该端点建立TCP连接。