mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 16:15:49 -06:00
[GH-ISSUE #3497] xtcp的双向打洞尝试 #2795
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#2795
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chendx-github on GitHub (Jun 26, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3497
Describe the feature request
如果有A，B两个客户端通过S服务器打洞，如果A -> B方向打洞不能成功，希望可以 从 B -> A方向尝试打洞 然后进行数据连接，而不是A -> B方向打洞失败之后就认为失败了。
Describe alternatives you've considered
No response
Affected area
@fatedier commented on GitHub (Jun 26, 2023):
你可以直接提供 xtcp 失败的日志和环境来分析原因。
@chendx-github commented on GitHub (Jul 10, 2023):
当前版本的打洞成功率太低了，我自己使用工具打洞是能打通的，但是frp的xtcp不行下面是log 总是报超时 实际上就是没通
我看log端口和地址都是获取的正常的，quic 和 kdp 我都试过了 同样的问题
2023/07/10 13:56:18 [I] [xtcp.go:70] [be9b15ae07cf35f3] [xtcp_3389_l] nathole prepare success, nat type: EasyNAT, behavior: BehaviorNoChange, addresses: [*.36:5250 :5250], assistedAddresses: [192.168.0.107:59900 192.168.138.1:59900]
2023/07/10 13:56:18 [I] [xtcp.go:91] [be9b15ae07cf35f3] [xtcp_3389_l] get natHoleRespMsg, sid [16889685777758f62ffe5c184c], protocol [kcp], candidate address [:49181], assisted address [10.20.178.3:49181 192.168.23.1:49181 10.20.178.1:49181], detectBehavior: {Role:receiver Mode:0 TTL:7 SendDelayMs:0 ReadTimeoutMs:5000 CandidatePorts:[] SendRandomPorts:0 ListenRandomPorts:0}
2023/07/10 13:56:23 [W] [xtcp.go:99] [be9b15ae07cf35f3] [xtcp_3389_l] make hole error: wait detect message error: read udp4 0.0.0.0:59900: i/o timeout
@fatedier commented on GitHub (Jul 10, 2023):
你可以配置
keep_tunnel_open = true过一段时间再观察状态。或者多连接几次测试看看，排查这种问题需要各端详细的日志，你提供的部分日志不能完全看出问题。
@chendx-github commented on GitHub (Jul 10, 2023):
我已经测试好几天了
@chendx-github commented on GitHub (Jul 10, 2023):
你需要那些log 我可以尝试提供
@fatedier commented on GitHub (Jul 10, 2023):
每个人环境都不一样，如果实在不行，那就只能在代码中添加日志尝试定位了
@chendx-github commented on GitHub (Jul 10, 2023):
我不知道该在那些地方添加日志
@fatedier commented on GitHub (Jul 10, 2023):
那你就按照这个方法配置之后，过一天，然后搜集所有的日志。
@chendx-github commented on GitHub (Jul 10, 2023):
我测试了很长时间，全部都是我发的那个log的重复
@fatedier commented on GitHub (Jul 10, 2023):
如果可以的话，就按照我说的配置和采集和贴出所有的日志，不行的话，那我也没办法了
@chendx-github commented on GitHub (Jul 10, 2023):
我有一个猜想，我的网络环境存在防火墙，会不会是 stun的服务返回的数据暴露了打洞的意图然后被防火墙给拦截了，在以前版本中应该是自己定义的 nat服务器，所以没有特征，就可以打洞成功.而现在由于使用了stun服务器数据是没有被加密的所以就获取到了双方的打洞ip和端口
@fatedier commented on GitHub (Jul 10, 2023):
有很多种可能性，这个问题通常比较复杂，你这种 EasyNAT 属于易于打通的环境，在开发阶段基本上是不存在问题的。但是这个也要看两端的情况。
你的猜测也是有可能的，或者还有其他的原因，提供长时间的完整的日志有可能能有帮助，但也不一定。因为复杂的情况一般还需要通过抓底层的数据包来结合判断。
@fatedier commented on GitHub (Jul 10, 2023):
也可以换个国内的 stun server 试试，比如
stun.qq.com:3478@chendx-github commented on GitHub (Jul 10, 2023):
我刚刚试了 还是一样的问题，可以提供一下打洞的流程吗， 我自己使用串口工具是可以打通的，我看看是不是打洞流程的问题，go语言的代码我不熟悉，看着比较费劲
@chendx-github commented on GitHub (Jul 10, 2023):
现在 B 往A 方向打通了，但是A往B方向打洞不通， 这个就是我说的那个双向打洞的问题，也叫反向打洞，意思是 A 不能到达B，但是B可以到达A这个时候可以用 B 往A打洞的方式来使线路联通，将流程调转一下。这样说能明白部
@fatedier commented on GitHub (Jul 10, 2023):
那你就按照这个流程操作一下再测试看看
@chendx-github commented on GitHub (Jul 10, 2023):
我刚刚说的那个问题是FRP从诞生以来就存在的，我现在使用套一层 frp 来实现的反向链接这个是原理图
@chendx-github commented on GitHub (Jul 12, 2023):
最后A 连接 B的xtcp也通了，虽然通了但是我觉得这个问题依然存在 可能只是我一直尝试打洞 某些情况下达到了A联通B的条件所以通了的。后续再观察一下
@kktt007 commented on GitHub (Nov 19, 2023):
好奇这个和使用默认的有什么区别吗，我经常失败，偶尔成功，是因为服务器的原因吗
今天尝试搭建，感觉不错，后续可以弃用 lanproxy 了，感谢作者
@XuruiPro commented on GitHub (Dec 30, 2024):
感觉frp打洞成功率没有nps大，写的nat type: EasyNAT就是不成功