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

Allow RemotePort to be optionally set in client JSON. #97

Merged
merged 1 commit into from
Feb 14, 2020

Conversation

beanslel
Copy link
Contributor

@beanslel beanslel commented Feb 12, 2020

This small patch adds the RemotePort variable to the ck-client JSON parser, so that it can be independently set when the Cloak client runs in shadowsocks mode. The motivation for this is as follows:

A single Shadowsocks instance has the ability to forward both TCP and UDP. TCP traffic will go through the plugin (Cloak), and UDP traffic will bypass the plugin and instead use a direct connection to the SS server over UDP.

When you run ss-server with -u (tcp_and_udp mode) and ck-server plugin, it will start a TCP listener on the port specified by BindAddr in the Cloak config (typically port 443) and an UDP listener on port SS_REMOTE_PORT (server_port in the config). So this creates the situation where you can potentially choose SS_REMOTE_PORT different from the BindAddr port. E.g.: Cloak can listen on public port TCP/443, and UDP raw Shadowsocks can listen on public port UDP/4000.

On the client side, however, there is no way to currently set SS_REMOTE_PORT independent of Cloak's RemotePort. Cloak will use SS_REMOTE_PORT specified in the SS config as RemotePort. So when you run ss-redir with -u (tcp_and_udp mode), Cloak plugin, and SS_REMOTE_PORT set to 443, it will connect to Cloak TCP on port 443, but will also attempt to connect to SS UDP on port 443. There is no way to change the UDP port to port 4000 in our example.

Technically, you could set SS_REMOTE_PORT on the server to port 443, and then it will create both a TCP and UDP listener on port 443. But personally I don't like doing this, because UDP port 443 is not commonly used for anything, so this may give away the fact that the server is not a normal webserver.

Setting RemotePort in the client JSON is optional. If it is specified, it is used. If it is not specified, Cloak falls back to the default behaviour of using SS_REMOTE_PORT or the -p variable as RemotePort. This is a very niche patch and most users will probably never need it, but it allows a bit more flexibility for people who also use SS as a UDP proxy and want to have different ports for TCP and UDP. I am currently using it in this way with this patch.

Importing strconv creates a little overhead, but the difference is small (on ARM it is around 300 bytes), on windows it is around 1kB. You could specify RemotePort as a string in json and then we don't need strconv, but I think this is unconventional and better to keep it as int in json and then convert it internally to string.

v2ray-plugin also has a similar functionality, where you can set the remotePort in JSON independently of the SS_REMOTE_PORT.

…N, Cloak falls back to SS_REMOTE_PORT in SS mode, or the -p argument in standalone
@malikshi
Copy link

If udp bypass plugin cloak(directly to ss-server) then Same as not using cloak plugin for bypass internet?? I'm bit confused

@beanslel
Copy link
Contributor Author

beanslel commented Feb 12, 2020

If udp bypass plugin cloak(directly to ss-server) then Same as not using cloak plugin for bypass internet?? I'm bit confused

Correct. UDP traffic bypasses the plugin (this is by shadowsocks design). If you only want to proxy UDP traffic, you can just run SS without plugin.

This patch just allows a single SS instance to run both Cloak on TCP and raw UDP SS with different ports. Then you don't need to launch a 2nd SS instance if you want to have a different UDP port.

@cbeuw cbeuw merged commit 23082af into cbeuw:master Feb 14, 2020
@beanslel beanslel deleted the remoteport branch February 15, 2020 04:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants