Closed yuyuko233 closed 1 year ago
how did you solve this issue?
@yuyuko233 excuse me, could you tell me the methon to bypass the issue? I meet the same issue, and no idea now. Thanks in advance.
@yuyuko233 excuse me, could you tell me the methon to bypass the issue? I meet the same issue, and no idea now. Thanks in advance.
k8s? If it is k8s, I am directly using the host port without agent forwarding, hence I believe the issue is with UDP forwarding.
ports:
- name: tcp-nat-type
hostPort: 21115
containerPort: 21115
protocol: TCP
- name: tcp-hole
hostPort: 21116
containerPort: 21116
protocol: TCP
- name: udp-id-reg
hostPort: 21116
containerPort: 21116
protocol: UDP
@yuyuko233 i'm having the exact same issue on a server with debian 12. Any clue on how to solve? No kubernetes, just a normal docker container
Have you followed these exact docs?
https://rustdesk.com/docs/en/self-host/rustdesk-server-oss/docker/
@dinger1986 yep of course. The strange thing is that it doesn't connect even without docker, using the server binaries. Firewall disabled of course.
What are you hosting on?
@dinger1986 You mean os? Tried debian 11 and 12.
No sorry vps, vm bare metal
@dinger1986 vps. In the client log i have a bunch of register_pk of rsser due to key not confirmed errors. In the server's log i see the incoming connection from the client but the websocket is closed immediately.
Where's the vps hosted?
Don't need to tag me, I get these anyway 👍
hostaris, germany
Ok, never heard of them but sure they are standard vps, what firewall are you using?
I always use hetzner to test the techahold script and it works fine every time
I was using ufw but i made several tries and i've rebuild the vm from scratch and now no firewal is being used. Disabling the firewall was the first thing i did for testing. Outside the vm, in the control panel of the host i don't have any option to manage ports so i suppose everything is open by default. I have other services running and they works great. Actually, around a month ago, i tried rustdesk and it worked good so far. These problems i'm getting appeared yesterday: i was trying the last version and i found out this.
Oh, what version are you using?
Last version: 1.2.2 for the cliend and 1.1.8-2 for the server. Now i'm trying old versions but still nothing
How strange. Does networking work from that server? Not doing anything funky with ports or whatever?
Some providers will give you a "natted" address (amazon, oracle, ...). If this is the case, you also need to setup port forwarding in their networking setup.
If unsure, check the IP address by ssh'ing into the VPS: ip -br -c a
If you get an IP address that is DIFFERENT from the (expected) external address, then this can be the answer.
@paspo i run the command and the ip address is the same of the external one so no nat is going on. I really don't know what could be the problem
try to start a temporary web server on the rustdesk ports and check if it works. You can test all the tcp works that way.
If you have a php installed, you can just use php -S 0.0.0.0:7777
.
If you have python, try python3 -m http.server 7777
The last resort is the classic packet dumping.
You must check if connections are making their way to the correct process, to exclude some external interference.
Remember: you can do a quick check for your server with a command like this:
docker run --rm -ti --entrypoint /usr/bin/rustdesk-utils rustdesk/rustdesk-server-s6:latest doctor rustdesk.mydomain.com
(or you can just use the binary from the releases page)
@paspo the python http server works without problems. I've tried random ports and the same ports of rustdesk and it works flawless. this is the doctor's result:
Checking IP address: x.x.x.x
Is IPV4: true
Is IPV6: false
Reverse DNS lookup: DOESN'T MATCH
TCP Port 21114 (API): ERROR
TCP Port 21115 (hbbs extra port for nat test): OK in 0 ms
TCP Port 21116 (hbbs): OK in 0 ms
TCP Port 21117 (hbbr tcp): OK in 0 ms
TCP Port 21118 (hbbs websocket): OK in 0 ms
TCP Port 21119 (hbbr websocket): OK in 0 ms
Server log:
rustdesk-server | [2023-08-23 20:52:23.897549 +00:00] DEBUG [src/rendezvous_server.rs:1097] Tcp connection from [::ffff:x.x.x.x]:52025, ws: false
rustdesk-server | [2023-08-23 20:52:23.897871 +00:00] DEBUG [src/rendezvous_server.rs:1137] Tcp connection from [::ffff:x.x.x.x]:52025 closed
rustdesk-server | [2023-08-23 20:52:56.218287 +00:00] DEBUG [src/rendezvous_server.rs:1097] Tcp connection from [::ffff:x.x.x.x]:32904, ws: false
rustdesk-server | [2023-08-23 20:52:56.218770 +00:00] DEBUG [src/rendezvous_server.rs:1097] Tcp connection from [::ffff:x.x.x.x]:42626, ws: true
rustdesk-server | [2023-08-23 20:52:56.219403 +00:00] DEBUG [src/rendezvous_server.rs:1137] Tcp connection from [::ffff:x.x.x.x]:32904 closed
rustdesk-server | [2023-08-23 20:52:56.219839 +00:00] DEBUG [src/rendezvous_server.rs:1101] WebSocket protocol error: Handshake not finished
rustdesk-server |
rustdesk-server |
rustdesk-server | Caused by:
rustdesk-server | Handshake not finished, hbbs::rendezvous_server:src/rendezvous_server.rs:1101:13
rustdesk-server | [2023-08-23 20:52:56.220179 +00:00] DEBUG [src/relay_server.rs:400] WebSocket protocol error: Handshake not finished
rustdesk-server |
rustdesk-server |
rustdesk-server | Caused by:
rustdesk-server | Handshake not finished, hbbr::relay_server:src/relay_server.rs:400:9
rustdesk-server | [2023-08-23 20:53:24.740143 +00:00] DEBUG [src/rendezvous_server.rs:1097] Tcp connection from [::ffff:x.x.x.x]:52032, ws: false
rustdesk-server | [2023-08-23 20:53:24.740390 +00:00] DEBUG [src/rendezvous_server.rs:1137] Tcp connection from [::ffff:x.x.x.x]:52032 closed
rustdesk-server | [2023-08-23 20:54:26.710317 +00:00] DEBUG [src/rendezvous_server.rs:1097] Tcp connection from [::ffff:x.x.x.x]:52040, ws: false
rustdesk-server | [2023-08-23 20:54:26.710416 +00:00] DEBUG [src/rendezvous_server.rs:1137] Tcp connection from [::ffff:x.x.x.x]:52040 closed
Client log:
[2023-08-23 22:47:39.081132 +02:00] INFO [src\rendezvous_mediator.rs:114] start rendezvous mediator of rustdesk.domain
[2023-08-23 22:47:39.126419 +02:00] DEBUG [libs\hbb_common\src\udp.rs:35] Receive buf size of udp 0.0.0.0:0: Ok(65536)
[2023-08-23 22:47:39.127991 +02:00] INFO [src\rendezvous_mediator.rs:463] register_pk of manage due to key not confirmed
[2023-08-23 22:47:41.128230 +02:00] INFO [src\rendezvous_mediator.rs:463] register_pk of manage due to key not confirmed
[2023-08-23 22:47:42.128680 +02:00] INFO [src\rendezvous_mediator.rs:463] register_pk of manage due to key not confirmed
[2023-08-23 22:47:44.128090 +02:00] INFO [src\rendezvous_mediator.rs:463] register_pk of manage due to key not confirmed
...
...
so, it's not a port problem. Maybe it has something to do with the keys... can you try with an empty database? Just grab a fresh db_v2.sqlite3
Nothing, same error. Could it be a MTU problem?
I think it's possible that the client can't connect via UDP to the server.
@yuyuko233 how to check this?
You can try this.
https://www.ibm.com/support/pages/udp-connectivity-testing
The 33001 port in the IBM tutorial needs to be changed to the udp port for hbbs listening, which defaults to 21116 port.
https://rustdesk.com/docs/en/self-host/rustdesk-server-oss/install/#option-2
@graphixillusion - hi, There's no need to overcomplicate this, just watch your traffic on the server (Deb12) that rustdesk related...
as he said @paspo "The last resort is the classic packet dumping."
here is your tool for this purpose = https://www.wireshark.org/docs/man-pages/tshark.html (Wireshark CLI for headless Deb server)
It seems there is something wrong with the udp packets. I've contacted the customer care and ask to them. Let's see. Thank you to everyone for the support, i'll update here when i'll have the answers from them.
UPDATE:
I can confirm that it was a UDP connection problem. The customer care saw me that their ddos policy was blocking the udp ports and they allow only a little range. Using the allowed range make it works. I think it should be specified in the faq that if there is something wrong with UDP the connection will fails.
May I ask how it was resolved? I also encountered the same problem
May I ask how it was resolved? I also encountered the same problem
Check the firewall if it's blocking the udp port
请问是怎么解决的呢?我也遇到了同样的问题
检查防火墙是否拦截了udp端口
I have checked and found that the port is open and verified with nmap
May I ask how it was resolved? I also encountered the same problem
Check the firewall if it's blocking the udp port
I have checked and found that the port is open and verified with nmap
@kerlw 检查下有没有经过流量转发服务,我k8s是因为udp转发有问题,使用hostPort就没事了
Check the traffic proxy service. My K8s has a problem with UDP forwarding.
Describe the bug The client cannot be connected to the server, and the server has always prompted to disconnect the connection. Always remind:
客户端无法连接到服务端, 服务端一直提示断开连接 一直提示:
Describe the environment
./amd64/hbbr
and./amd64/hbbs -r 0.0.0.0
How to Reproduce the bug
./amd64/hbbr
and./amd64/hbbs -r 0.0.0.0
Additional context
Client log:
Server log: