search

heiher / hev-socks5-server

A high-performance socks5 server for Unix (Linux/Android/BSD/macOS/iOS)
MIT License
269 stars 40 forks source link

Suspicious UDP rebind leads to disconnect in udp traversals #62

Open Clockware opened 3 months ago

Clockware commented 3 months ago

Hi. As a start, I'll shortly say that I was looking for a portable, fully functioning, precompiled for many platforms, SOCKS5 Server, and this one caught my attention and was the best in my testing so far.

However, I'm here to report the bug (or so I think). One of the tests I perform to test UDP proxies is playing games that utilize UDP protocols (legacy Blizzard games mostly), it's great test to see how "transparent" proxy really is. The first main test was: VPS hosting hev-socks5, me connecting from Windows 11 through proxifier-analog to the VPS address. I got disconnected after 6 minutes in the game.

I started narrowing issue down: 1) I moved hev-socks5 from VPS to my router 2) I changed proxifiers, as well as utilizing SOCKS5 global on OS to avoid any proxifier issues

But the issue remained, and very clearly detectable from Info logs of the server. Typical disconnect looks like this:

[2024-08-04 14:50:38] [I] 0x7fc6762b0b60 io timeout [2024-08-04 14:50:43] [I] 0x7fc6762b0ea0 io timeout [2024-08-04 14:50:43] [I] 0x7fc6762b0ac0 io timeout [2024-08-04 14:50:49] [I] 0x7fc6762b4b70 io timeout

[2024-08-04 14:52:12] [I] 0x7fc6762b4ec0 io timeout [2024-08-04 14:53:11] [I] 0x7fc6762b4a30 io timeout

[2024-08-04 14:58:12] [I] 0x7fc6762b0ea0 io timeout

[2024-08-04 15:03:25] [I] 0x7fc6762b4e20 io timeout [2024-08-04 15:03:35] [I] 0x7fc6762b4f60 io timeout

It's the full log using "info". I have others but this is the shortest one, only 6 minutes from udp binds.

I really liked the project and decided to report it in case the owner fixes it faster than I'll do SOCKS5 by myself :) There are so many socks5 projects yet not so many of them are portable and high quality.

I can only say that everything works correctly without the SOCKS5, and I also got positive results from using ShadowSocks (although it's not quite socks5), however I'm interested in SOCKS5 specifically right now because of more flexible clients.

heiher commented 3 months ago

If there is no data transmission in both directions of TCP and UDP for more than the configured timeout (read-write-timeout), the session will be closed. The default value of read-write-timeout is 60 seconds, try to increase it?

Clockware commented 3 months ago

If there is no data transmission in both directions of TCP and UDP for more than the configured timeout (read-write-timeout), the session will be closed. The default value of read-write-timeout is 60 seconds, try to increase it?

I can do that, yes (saw the setting). But there is certain level of distrust for this solution long-term, and here's why:

Which is why I have a strong sense that UDP death might be tied to the death of something that is non-UDP related (thread, associate TCP connection, some other TCP connection, etc). And if I increase timeout for 2 hours, it'll just mean that I get the same effects but after 2 hours (somewhat harder to replicate, I don't play that long, but never impossible), because the timeout doesn't actually care for UDP.

Makes by UDP connection rely on a happy thread. What you suggest will indeed help me locally, but this still has to be reported.

Clockware commented 3 months ago

RFC1928:

A UDP association terminates when the TCP connection that the UDP ASSOCIATE request arrived on terminates.

If that's why connection terminates, I guess what I'm seeking is not RFC compliant socks5 server. I need UDP connection to stay if there are packets to relay. I can't force all socks5 clients and proxifiers in the world to keep that tcp connection even if it's their fault.