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

单机同时运行FRPC和FRPS - new proxy [udp1] error: port already used #1606

Closed
Fisherworks opened this issue Jan 9, 2020 · 12 comments
Closed
Labels
bug

Comments

@Fisherworks
Copy link

@Fisherworks Fisherworks commented Jan 9, 2020

Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly.
(为了节约时间,提高处理问题的效率,不按照格式填写的 issue 将会直接关闭。)
(请不要在 issue 评论中出现无意义的 加1我也是 等内容,将会被直接删除。)
(由于个人精力有限,和系统环境,网络环境等相关的求助问题请转至其他论坛或社交平台。)

Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST

What version of frp are you using (./frpc -v or ./frps -v)?
0.31.1 linux amd64 AND 0.30.x linux arm

What operating system and processor architecture are you using (go env)?
amd64 version on Centos 7.7
and arm version on Raspbian Jessie

Configures you used:
---frps.ini---
[root@vm frp_linux_amd64]# cat frps.ini
[common]
bind_addr = 0.0.0.0
bind_port = 7200
log_file =/var/log/frp/frps.log

log_max_days = 5
allow_ports = 9093, 10194

---frpc.ini---
[root@vm frp_linux_amd64]# cat frpc.ini
[common]
server_addr = 127.0.0.1
server_port = 7200
log_file =/var/log/frp/frpc.log
log_max_days = 5

[udp1]
type = udp
local_ip = any.domain.exists
local_port = 1194
remote_port = 10194

[tcp1]
type = tcp
local_ip = any.domain.exists
local_port = 9093
remote_port = 9093

---frps.service---
[root@vm ~]# cat /etc/systemd/system/frps.service
After=network.target
Before=frpc.service

[Service]
Type=simple
User=aqui
Restart=on-failure
RestartSec=5s
ExecStart=/home/aqui/frp_linux_amd64/frps -c /home/aqui/frp_linux_amd64/frps.ini

[Install]
WantedBy=multi-user.target

---frpc.service---
[root@vm ~]# cat /etc/systemd/system/frpc.service
[Unit]
Description=Frp Client Service
After=network.target frps.service

[Service]
Type=simple
User=aqui
Restart=on-failure
RestartSec=5s
ExecStart=/home/aqui/frp_linux_amd64/frpc -c /home/aqui/frp_linux_amd64/frpc.ini

[Install]
WantedBy=multi-user.target

Steps to reproduce the issue:

  1. setup configs as above, use an existing domain instead
  2. let systemctl to start both FPRS and FRPC service, both work fine
  3. enable the both services in systemd
  4. reboot
  5. the both FRPC and FRPS starts as expected, but the UDP proxy has error log outputting continuously and the port doesn't work neither. Log looks like this -
    ---frpc.log---
    2020/01/09 14:09:18 [I] [service.go:250] [72df80c86c80ba35] login to server success, get run id [72df80c86c80ba35], server udp port [0]
    2020/01/09 14:09:18 [I] [proxy_manager.go:144] [72df80c86c80ba35] proxy added: [tcp1 udp1]
    2020/01/09 14:09:18 [I] [control.go:164] [72df80c86c80ba35] [tcp1] start proxy success
    2020/01/09 14:09:48 [W] [control.go:162] [72df80c86c80ba35] [udp1] start error: lookup any.domain.exists on 114.114.114.114:53: read udp 192.168.2.171:39489->114.114.114.114:53: i/o timeout
    2020/01/09 14:09:48 [I] [proxy.go:438] [72df80c86c80ba35] [udp1] incoming a new work connection for udp proxy, 127.0.0.1:7200
    2020/01/09 14:10:18 [W] [control.go:162] [72df80c86c80ba35] [udp1] start error: port already used
    2020/01/09 14:10:48 [W] [control.go:162] [72df80c86c80ba35] [udp1] start error: port already used
    2020/01/09 14:11:18 [W] [control.go:162] [72df80c86c80ba35] [udp1] start error: port already used
    ===here we restart frpc.service===(or restart frps.service also works)
    ===then the both proxy works well===
    2020/01/09 14:11:39 [I] [service.go:250] [095cbb013b2b5288] login to server success, get run id [095cbb013b2b5288], server udp port [0]
    2020/01/09 14:11:39 [I] [proxy_manager.go:144] [095cbb013b2b5288] proxy added: [udp1 tcp1]
    2020/01/09 14:11:39 [I] [control.go:164] [095cbb013b2b5288] [udp1] start proxy success
    2020/01/09 14:11:39 [I] [control.go:164] [095cbb013b2b5288] [tcp1] start proxy success
    2020/01/09 14:11:40 [I] [proxy.go:438] [095cbb013b2b5288] [udp1] incoming a new work connection for udp proxy, 127.0.0.1:7200
    ---end of log---
  6. systemctl restart fprc/frps, choose either of both to restart, everything works fine after - there must be a manual restart, on either one, frpc or frps, problem solved, log is good. Otherwise - endless "port already used".

Describe the results you received:

  1. the udp1 proxy not work until a manual restart of the service
  2. corresponding error log

Describe the results you expected:

  1. the udp1 works as expected
  2. no "port already used" since no one use the 10194 port during the entire bootup process

Additional information you deem important (e.g. issue happens only occasionally):
Centos 7.x - bad, Raspbian Jessie on RPi3b - bad, but Raspbian buster on RPi 3b - no issue, and Raspbian buster on RPi 4 also works well - NO "port already used" at all.

And furthermore, if you have curiosity to the config:
this is not used to expose ports of a LAN service to the WAN
just the reverse side, it brings something from the WAN into the LAN - to make the clients in a restricted LAN area has limited connectivity to some critical service from WAN - just like them working in LAN.

Can you point out what caused this issue (optional)
I really don't get it - what's wrong with my config?

@Fisherworks

This comment has been minimized.

Copy link
Author

@Fisherworks Fisherworks commented Jan 9, 2020

如果对这个诡异的config有疑问,那很正常
因为好像没太多人这么用FRP,大家都是把运行在内网服务的个别端口,穿透到公网
这里的config刚好相反,是把运行在公网服务的个别端口,穿透到内网
除此以外就没什么特别的了

FRP还是很灵活实用的工具,希望作者老大有空帮忙调查下这个问题,这会对我们有非常大的帮助,谢谢!

@Fisherworks Fisherworks changed the title run FRPC and FRPS on same server may encounter - new proxy [udp1] error: port already used 单机同时运行FRPC和FRPS - new proxy [udp1] error: port already used Jan 10, 2020
@quickhot

This comment has been minimized.

Copy link

@quickhot quickhot commented Jan 19, 2020

[tcp1]
type = tcp
local_ip = any.domain.exists
local_port = 9093
remote_port = 9093
这里怎么能这么写呢,你是同一台机器啊~!

@Fisherworks

This comment has been minimized.

Copy link
Author

@Fisherworks Fisherworks commented Jan 19, 2020

[tcp1]
type = tcp
local_ip = any.domain.exists
local_port = 9093
remote_port = 9093
这里怎么能这么写呢,你是同一台机器啊~!

知道您会有这样的疑问
实际上是从any.domain.exists:9093 映射到 0.0.0.0:9093 这样不算同一台机器吧?
因为local_ip反而是云端(但是能够访问到),而remote其实是本地

这里唯一的问题是,frps或者frpc跟着系统启动,就报port already used
但系统启动后,再次restart frps或者frpc,就工作一切正常了,持续服务很多天都没事


你可能想问,为何不把frpc装到远端的机器上?

实际在普遍的用法中,frps在远端,frpc在本地
如果本地有三台机器的22要到远端,其实不用在3台机器上安装frpc,而是局域网1台机器安装frpc
配置文件写成
local ip 127.0.0.1(或者192.168.1.101)
local port 22
remote port 50122

local ip 192.168.1.102
local port 22
remote port 50222

local ip 192.168.1.103
local port 22
remote port 50322

就可以使用一个frpc,把本地三台机器的22,打到远端frps上


在我的配置方式中(把云端服务代理到本地),因为有多台局域网frps都想代理云端的同一套服务
如果frpc安装到云端,那么多一台局域网frps,云端就要新增运行一套frpc服务
但如果frpc和frps都运行在同一台机器上,这样反而云端不需要做任何配置


如果还不好理解
我们说的直观一点
您的环境有两个网段 192.168.1.x和192.168.100.x
1.x可以上外网,100.x不可以
如果想让100.x访问且只访问百度web
你不可能让百度服务器安装frpc
而是用一个双网口linux vm,从1.x的地址把baidu.com:443映射到100.x:443
所以自己既运行frpc,又运行frps
就可以让100.x的其他计算机,访问且只访问baidu https了


在我的试验中
走tcp的9093是没问题的
反而是走udp的10194,随系统启动时,是报错的;重启服务后,就不报错的

@Fisherworks

This comment has been minimized.

Copy link
Author

@Fisherworks Fisherworks commented Jan 21, 2020

因为需求比较简单(不涉及穿透多层NAT),转而捡起了iptables,放弃了FRP
毕竟是生产环境,等不起,其实还是蛮看好FRP的,配置轻松好懂又灵活
iptables -t nat -A PREROUTING -p udp -i ens16 --dport 10194 -j DNAT --to 3.3.3.3:1194 iptables -t nat -A PREROUTING -p tcp -i ens16 --dport 9093 -j DNAT --to 3.3.3.3:9093 iptables -t nat -A POSTROUTING -j MASQUERADE

还是希望作者哥们有空能关注下这个问题的

@Renfrew

This comment has been minimized.

Copy link

@Renfrew Renfrew commented Jan 21, 2020

我倒是觉得你开机启动的脚本可以让他等系统服务启动完成后再启动frp,毕竟你说的是启动完后重启不报错。这大概是启动顺序有问题。我Linux的启动脚本有设定启动顺序的。另外单机使用设置iptables是我的一般做法,但是现在nftables正在替换iptables,所以你可以给系统升下级,打打补丁,然后用nftablle设置路由。frp的使用场景不应该考虑单机使用。

另外你tcp1设定的两个端口可以是不同的,这样应该可以避免端口占用问题

@Fisherworks

This comment has been minimized.

Copy link
Author

@Fisherworks Fisherworks commented Jan 30, 2020

我倒是觉得你开机启动的脚本可以让他等系统服务启动完成后再启动frp,毕竟你说的是启动完后重启不报错。这大概是启动顺序有问题。我Linux的启动脚本有设定启动顺序的。另外单机使用设置iptables是我的一般做法,但是现在nftables正在替换iptables,所以你可以给系统升下级,打打补丁,然后用nftablle设置路由。frp的使用场景不应该考虑单机使用。

另外你tcp1设定的两个端口可以是不同的,这样应该可以避免端口占用问题

系统启动完成再起服务,我没有试过很高级的配置,起码在服务启动时延时5~10s再起frps/frpc进程,没用
tcp1两个端口其实没有冲突,毕竟配置local 9093实际上是云端机器的9093,而remote 9093实际是本地机器的,所以这一条从来没冲突过
实际报冲突的是upd1,local(云端)是1194,而remote(本地)是10194,然后报冲突

最后我确实用的iptables,系统用的ubuntu 18.04 LTS,确实带了nftables,但是没有太多可以参考的,所以还是用的iptables,毕竟这货也不用装 —— 应该是内核自带吧?而且可靠性经得起时间考验,只是配置没有frp这么好理解也好懂,需要2小时的现学现用

@fatedier

This comment has been minimized.

Copy link
Owner

@fatedier fatedier commented Feb 4, 2020

frps 的日志有吗?

看上去 reboot 之后第一次重连由于网络服务没有启动完成,往 114.114.114.114 发送 DNS 查询请求失败,之后没有正确释放端口,导致后续重试的时候显示端口已占用。

将 frps 放在网络服务启动完成之后启动应该是可以的,没有释放端口的问题需要进一步排查下。

@fatedier fatedier added question bug and removed question labels Feb 4, 2020
@fatedier fatedier closed this in 4a4cf55 Feb 4, 2020
@Fisherworks

This comment has been minimized.

Copy link
Author

@Fisherworks Fisherworks commented Feb 10, 2020

systemd配置文件已经让frps和frpc都在network.target之后启动的,按理说不该有DNS的问题,居然还是报错port already used,无论x86还是ARM,多种内核版本都一个样
而且有个细节要留意,如果没有其他设备来连接被转发的端口,在这里是10194和9093,则这个port already used大概率可能不会报,而一旦走这俩端口进来访问,frps和frpc log都会报port already used

@Fisherworks

This comment has been minimized.

Copy link
Author

@Fisherworks Fisherworks commented Feb 11, 2020

此外,bug为啥关掉了?

@fatedier

This comment has been minimized.

Copy link
Owner

@fatedier fatedier commented Feb 11, 2020

fix 此 bug 的 commit 已被合并到 master 分支,自动关闭,可以尝试更新版本。

@Fisherworks

This comment has been minimized.

Copy link
Author

@Fisherworks Fisherworks commented Feb 11, 2020

收到,谢谢 @fatedier 我去测一下

@Fisherworks

This comment has been minimized.

Copy link
Author

@Fisherworks Fisherworks commented Feb 11, 2020

ARM版测试0.31.2 release,机器reboot后,问题目前没有复现

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.