$Home|Elec|Tech|Misc|Pics

Slackware ShadowSocks server

12 July 2020
The ShadowSocks protocol is something I came across because a friend who is due to go back to China was asking about mobile proxies, and it was one of the protocols supported by an iPhone VPN app they had ended up buying. Since my existing StrongSwan IKEv2 server needed updating due to an expired certificate, I ended up deciding to try it for myself. Although distributed in source form the instructions for building & installing it on Linux assume Ubuntu, but since I mostly use Slackware I decided to work out how to build it for the latter. This article documents what I did to get it working.

After doing some background reading into ShadowSocks what struck me was how lightweight it is, in particular requiring a minimal amount of setup to get a proxy server operational. I suspect this is intentional because the typical life-expectency of VPN servers used to access blocked websites from China is often limited, so fast setup is favoured over pretty much everything else. Unlike most VPNs it is about getting outside rather than inside.

Software dependencies

Normally when I install Slackware I install pretty much all the disksets but for some reason the server I used to build ShadowSocks only had a subset of them installed, which was resulting in some odd error messages. The list below is probably not complete but it is the packakes that are most likley going to be missing. ShadowSocks also depends on some libraries that are not in the standard Slackware distribution but are available from SlackBuilds, and these are listed below. Easiest thing is to use SBoPkg to fetch and build them, as how to build and install SlackBuilds is beyond the scope of this article.

Building ShadowSocks

This is more or mess cut'n'pasted from the ShadowSocks online documentation, although with two notable changes: Specifically building version 3.3.4 rather than the bleeding-edge latest, and it is placed under /opt rather than the default location.

git clone https://github.com/shadowsocks/shadowsocks-libev.git cd shadowsocks-libev git checkout v3.3.4 git submodule update --init ./configure --prefix=/opt/shadowsocks make make install

Setup and running

ShadowSocks uses a small JSON file for configuration, and anyone with any sort of background in computer networking can easily guess what each parameter represents. The only odd one is method which is the encryption algorithm that is to be used. If server has the interface's actual IP address rather than the bind-to-everything place-holder 0.0.0.0 then it is possible, with the addition of other parameters the server part ignores, for the same config file to be used by both servers and clients.

{ "server" : "0.0.0.0", "server_port" : 8388, "password" : "sekret", "timeout" : 600, "method" : "aes-256-cfb", "user" : "nobody" }

The server can then be started using a command much like that below; parameters can instead be specified on the command-line, which will be demonstrated for the client setup. The -c parameter give the configuration file. The -f parameter daemonises the program so that it runs in the background, and writes the PID to the specified file.

/opt/shadowsocks/bin/ss-server -c /opt/shadowsocks/etc/shadowsocks.json -f /run/shadowsocks.pid

Client setup

For mobiles an Android client is available on Google Play, whereas for desktops there are basically two ways to route traffic: Applications individually using a local Socks proxy, and system-wide traffic using some fancy iptables rules. So far I have not tried out the latter. Most people will only be interested in browser traffic, in which case they can use the following to connect to proxy.example.com:8388 with password sekret and aes-256-cfb as the encryprion algorithm.

ss-local -s proxy.example.com -p 8388 -l 1080 -m aes-256-cfb -k sekret

A Socks proxy will appeaer on the local machine on port 1080 which Chrome/Chromium can connect to using the following command-line. This is the same one as used by the similar Socks-over-SSH method of tunelling.

chromium-browser --proxy-server="socks5://127.0.0.1:1080" --host-resolver-rules="MAP * 0.0.0.0 , EXCLUDE localhost"

One thing to keep in mind is that ShadowSock is not known for informative error messages. If the wrong encryption key is used for instance, the server will spit out errors about bad addresses, rather than reporting a password mismatch.