mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 16:15:49 -06:00
[GH-ISSUE #218] udp proxy在空闲一段时间之后，无法正常工作。 #149
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#149
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 @goer99 on GitHub (Jan 9, 2017).
Original GitHub issue: https://github.com/fatedier/frp/issues/218
过程描述：
建议：
log记录中增加proxy（frps，frpc）对第三方（proxy使用方）的消息处理记录，例如收/发情况，转发情况等。
@goer99 commented on GitHub (Jan 9, 2017):
回看frps的log，在维持heartbeat期间，有数次如下记录：
2017/01/08 19:29:58 [control.go:163] [D] ProxyName [abc], get heartbeat
2017/01/08 19:30:05 [server.go:368] [W] ProxyName [abc], work connection for udp closed
2017/01/08 19:30:08 [control.go:163] [D] ProxyName [abc], get heartbeat
2017/01/08 19:30:12 [server.go:395] [D] ProxyName [abc], write to work connection for udp error: write tcp x.x.x.x:6000->y.y.y.y:33836: write: broken pipe
2017/01/08 19:30:18 [control.go:163] [D] ProxyName [abc], get heartbeat
@fatedier commented on GitHub (Jan 11, 2017):
参考 #206，感觉这样的应用并不适用。
@goer99 commented on GitHub (Jan 12, 2017):
我的应用场景和 #206 完全不同。我的使用场景是frp + vpn
#206 的 n2n 其实是一个udp打洞工具，实现两个内网主机的点对点通讯。n2n需要每个使用者都安装n2n的节点。
而frp是一个多协议反向proxy。frp不需要每个使用者都安装frp。
n2n的supernode也必须是公网ip。这点和frp一样，都需要一个具有公网ip的公共节点，联络各个内网节点，以及转发数据包。所有的内网穿透产品，都是这么一个架构。
与frp不同，n2n并非proxy，而是利用虚拟网卡建立点对点通讯，可惜的是n2n不是一个vpn，没有实现network 2 network，只实现了node 2 node。其实n2n中建立一下各个节点的路由表就能实现network 2 network，不知道为什么作者没有实现这个功能。
因此，需要构建两个内网network 2 network的使用场景，目前来看frp + vpn是一个比较好的解决方案。
@fatedier commented on GitHub (Jan 12, 2017):
我的意思是如果 openVPN 使用 UDP 的方式，可能也需要感知到连接的 ip 和端口，而中间加了 frp 这个代理之后，这些信息会丢失，导致不能正常工作。
完全是猜测，因为不确定 openVPN 的具体工作原理。
@goer99 commented on GitHub (Jan 12, 2017):
frpc和frps刚刚连接上时，openVPN工作完全正常。只是当frpc和fprs之间idle一段时间，没有数据交换之后，再使用openVPN就无法连上了。
@fatedier commented on GitHub (Jan 12, 2017):
因为 udp 是没有连接的，所以 frp 并不知道你发送的 udp 包之后，要多长时间才不需要继续读取数据。所以目前转发 udp 包时设置了一个超时，超过 2 分钟之后，仍然没有读取到对方发送的数据就会退出。这样对方就无法再主动给你发送数据。
不知道是不是这个地方有影响，通常要维护 udp 的 ”连接“，需要主动发送心跳，因为 NAT 设备上的 UDP 转发表应该也会定期清除的。
你可以把 openVPN 的部署方式发我，我有时间可以测试下。
@goer99 commented on GitHub (Jan 13, 2017):
估计就是这个2分钟超时机制的设定引起的问题，无udp数据传输2分钟之后，判定为超时，udp proxy关闭。下次第三方想再次使用udp proxy时，就无法连接成功。
几点建议：
能否将这个udp proxy超时退出的参数放到conf文件里呢？这样可以进一步测试验证。
这个udp proxy的超时退出机制，应该根据无心跳的时间判定超时。由于udp不是面向连接的，若维持udp proxy的生存需要udp心跳的话，那么可以将frps和frpc之间的心跳改为udp协议，认证仍旧使用tcp协议，这样就可以完美解决这个问题了。
frpc与frps之间的认证和心跳都是用的tcp协议，所以tcp proxy没有这个问题。只要有心跳存在，tcp proxy就会一直生存，而不会判定超时退出。即便出现网络问题连接不上，也会重连之后激活tcp proxy。
@fatedier commented on GitHub (Jan 13, 2017):
你这里有个问题理解错了，超时不是针对 udp proxy，而是单个 udp 请求。
比如 dns 查询，发送查询请求，客户端收到数据包之后就结束了，tcp 的话这里会主动发起关闭连接的操作。但是对于 udp 来说，你不 read 就行了，是没有连接的。这个操作交给 frp 中转的话，frp 不能感知到什么时候结束，所以必须要有超时机制来释放这部分资源。
@goer99 commented on GitHub (Jan 13, 2017):
对于udp proxy，看来需要有一个frps对frpc的唤醒机制。
当frpc 睡眠时（无udp连接，仅有心跳），若frps 收到第三方发起的udp数据请求，frps应立即唤醒frpc，frpc向frps重建udp通道，frps转发frpc与第三方的udp数据。
如果frp 在udp proxy上无法维持这种随时接收和响应第三方udp请求的状态（即唤醒机制），那么这个udp proxy的实用意义就没有了。
@fatedier commented on GitHub (Jan 13, 2017):
你可以整理一下思路，目前你的理解和实际的问题并不一致，openVPN 的问题也不需要光猜测，还是复现定位问题比较方便。
@goer99 commented on GitHub (Jan 13, 2017):
你可以安装一下openVPN看看是否有这个问题。
openVPN的官网：https://openvpn.net/ 需要翻一下墙。
openVPN的安装可以参考：
CenTos OpenVpn 一键安装包
http://www.myzhenai.com/thread-17453-1-1.html
如果脚本里面的资源包下载地址不可用，可能需要更换所需资源包的下载地址。
以上是openVPN的服务器端安装。
OpenVPN客户端配置
对于Windows客户端
到 http://www.vpswe.com/goto/3h62 下载gui版的OpenVPN，按照提示安装完成后，进入到安装目录，如D:\Program Files\OpenVPN。将Linux服务端使用easy-rsa产生的客户端证书、私钥和ca证书下载到本地。即需要下载到本地的文件如下：
/etc/openvpn/easy-rsa/2.0/keys/ca.crt #ca证书
/etc/openvpn/easy-rsa/2.0/keys/client.crt #客户端证书
/etc/openvpn/easy-rsa/2.0/keys/client.key #客户端私钥
将这些文件下载到D:\Program Files\OpenVPN\config下。
编辑客户端OpenVPN配置文件client.ovpn，内容如下：
client
dev tun
proto udp
remote SERVER_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo
verb 3
redirect-gateway def1
route-method exe
route-delay 2
将SERVER_IP写成OpenVPN服务器的ip，然后打开OpenVPN的GUI，点击连接，完成OpenVPN拨入
对于Mac 客户端
到 http://sourceforge.net/projects/tunnelblick/ 下载OpenVPN 客户端软件 Tunnelblick
@2726266496 commented on GitHub (Jan 16, 2017):
我也发现这个问题了，OpenVPN使用udp方式刚开始没有问题，过一段时间连接会超时，目前解决方法是使用OpenVPN的tcp模式，frp也使用tcp方式。使用了两三天了，没出现什么问题。
PS：原issue#206已关闭，在此感谢作者回复
@goer99 commented on GitHub (Jan 16, 2017):
没错。tcp proxy没有这个问题，只有udp proxy有这个问题。
frp作为tcp proxy非常不错，期待udp也能一样出色。
@luhanglei commented on GitHub (Mar 2, 2017):
我也遇到了同样的问题，每次请求就是需要在公网发送一条UDP到我的内网里的某台设备，然后在很短的时间内，内网的设备回复回去。frpc刚运行的时候很稳定的可以使用。但隔了一晚上没有任何操作之后，TCP仍然正常，UDP就连接不上了。要重启frpc才可以。
@fatedier commented on GitHub (May 21, 2017):
@goer99 可以尝试下 v0.10.0 版本，这个 issue 暂时关闭，如果新版本还有问题，麻烦另开 issue 反馈。