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

[Feature Request] Adds UPNP support to xtcp nathole #4112

Open
2 of 11 tasks
slayercat opened this issue Mar 28, 2024 · 0 comments
Open
2 of 11 tasks

[Feature Request] Adds UPNP support to xtcp nathole #4112

slayercat opened this issue Mar 28, 2024 · 0 comments
Labels

Comments

@slayercat
Copy link

slayercat commented Mar 28, 2024

Describe the feature request

also see:

#1823
#3703

With the development of technologies such as P2P, initiating UPnP requests and asking routers to cooperate is a common technique in scenarios requiring public network mapping. Investigation and testing in this context, as outlined in #1823, demonstrate that even within ISP-level NAT networks, some providers offer support for related technologies.

In IPv6 environments, even though each endpoint can acquire an IPv6 address, most routers currently block all inbound requests from the internet for security reasons. Therefore, it's still necessary to configure the opening of corresponding ports. The use of UPnP in these scenarios retains significant value.

Moreover, some tools also offer similar functionalities, like ZeroTier (https://www.zerotier.com/).

===

随着p2p等技术的发展,主动发起upnp请求并要求路由器进行配合在需要公网映射的情况下是一个常见技术。#1823 对此做了一些上下文的调查及测试,可以看到即使在运营商级的NAT网络中,部分运营商也提供了相关技术的支持。

在ipv6环境中,即便是每个端点都能获取到ipv6地址,但目前大部分路由器为了安全均禁止互联网侧的全部入站请求,因此依然需要配置开放对应端口,目前使用的upnp在相关场景下也具有一定的价值意义。

同时,部分工具也同时提供了类似功能,如zerotier 等 https://www.zerotier.com/

Describe alternatives you've considered

The current implementation is a straightforward extension of the STUN implementation for xTCP.

see: #4110 for PR

After acquiring a public IP address, a callback is invoked. If permitted by the configuration, the UPnP feature is used to direct the router to transfer the externally exposed port to an open UDP port, thereby "creating" an EasyNAT in this environment. The subsequent process fully reuses the STUN procedure.

I haven't closely examined the current implementation, but my assumption is that either the visitor or the proxy needs to be reachable by the other party for a direct connection to be established without the need for server relay. Therefore, I have implemented related configuration code on both the visitor and the proxy sides.

If there's any misunderstanding on my part, please kindly correct me.

As @fatedier mentioned, this issue has been created to gather relevant information and solicit valuable feedback.

Thank you all for your contributions.

==

当前实现的设计,是对xtcp的stun实现的简单扩展。

在获取到公网ip地址后调用回调,在配置许可的情况下,调用upnp功能,使得路由器直接将已对外暴露的端口转移到已开放的udp端口上,从而在这个环境下“制造”一个EasyNAT,接下来的流程完全复用stun的过程。

我没有仔细研究目前的实现,但我做的假设是visitor或proxy只需要有一边是对方可达的,则另一边就可以直接连接到对端,而不需要服务器中转。因此,我在visitor和proxy上均做了相关配置代码。

如果有任何我理解不当的地方,请帮助指正。

@fatedier 提到的, 创建本Issue来收集相关信息及获取宝贵意见。

感谢大家

Affected area

  • Docs
  • Installation
  • Performance and Scalability
  • Security
  • User Experience
  • Test and Release
  • Developer Infrastructure
  • Client Plugin
  • Server Plugin
  • Extensions
  • Others
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants