As we are increasingly denied access to various resources on the network, the issue of bypassing locks becomes more and more relevant, which means that the question “How to bypass locks faster?” becomes more and more relevant.
Let's leave the topic of efficiency, in terms of bypassing DPI whitelist blacklists, for another case, and just compare the performance of popular lock bypass tools.
Attention: There will be a lot of pictures in the article under spoilers.
Disclaimer: This article compares the performance of popular vpnproxy solutions under "ideal" conditions. The results obtained and described here do not necessarily coincide with your results in the fields. Because the number in the speedtest will often depend not on how productive the bypass tool is, but on how your provider throttles QoS and blocks it.
Methodology
3 VPS were bought from a cloud provider (DO) in different countries of the world. 2 in the Netherlands, 1 in Germany. The most productive VPS (by the number of cores) was selected from those available for the account at the offer for coupon credits.
A private iperf3 server is deployed on the first Dutch server.
On the second Dutch server, various servers of the blocking bypass tools are deployed in turn.
A German VPS deployed a Linux desktop image (xubuntu) with VNC and a virtual desktop. This VPS is a conditional client, and various proxy VPN clients are launched on it one by one.
Speed measurements are carried out from three times, we focus on the average, we use 3 tools: in chromium through a web speedtest; in chromium via fast.com; from the console via iperf3 via proxychain4 (where you need to shove iperf3 traffic into a proxy).
A direct iperf3 client-server connection gives a speed of 2 Gbps in iperf3, and a little less in fastspeedtest.
An inquisitive reader may ask, "why didn't you choose speedtest-cli?" and will be right.
The Speedtest CLI proved to be an unreliable, inadequate way to measure throughput, for reasons unknown to me. Three consecutive measurements could give three completely different results, or, for example, show throughput much higher than the port speed of my VPS. Perhaps the problem is in my club hand, but it seemed impossible for me to conduct research with such an instrument.
As for the results for the three measurement methods (speedtest and perf), I consider the iperf indicators to be the most accurate, reliable, and fastspeedtest as reference. But some bypass tools did not allow to complete 3 measurements through iperf3 and in such cases, you can focus on speedtestfast.
speedtest gives different results
Инструментарий
In total, 24 different bypass tools and/or their combinations were tested, for each of them I will give a small explanation and my impressions of working with them. But in fact, the goal was to compare the speeds of shadowsocks (and a bunch of different obfuscators for it) openVPN and wireguard.
In this article, I will not touch on the question “what is the best way to hide traffic so that they are not disconnected”, because bypassing blocking is a reactive measure - we adapt to what the censor uses and act on this basis.
The results
Strongswanipsec
According to my impressions, it is very easy to set up, it works quite stably. Of the benefits - really cross-platform, without the need to look for clients for each platform.
download - 993 mbits; upload - 770mbits
SSH tunnel
Probably only the lazy did not write about the use of SSH as a tunnel tool. Of the minuses - the "crutality" of the solution, i.e. deploying it from a convenient beautiful client on each platform will not work. Of the benefits - good performance, there is no need to install anything on the server at all.
download - 1270 mbits; upload - 1140mbits
openvpn
OpenVPN was tested in 4 operating modes: tcp, tcp+sslh, tcp+stunnel, udp.
The OpenVPN servers were configured automatically by installing streisand.
As far as I can tell, at the moment only the stunnel mode is resistant to advanced DPI. The reason for the anomalous increase in throughput when wrapping openVPN-tcp in a stunnel is not clear to me, checks were made in several passes, at different times and on different days, the result was the same. Perhaps this is due to the network stack settings that are set when deploying streisand, write if you have any ideas why this is so.
openvpntcp: download - 760 mbits; upload - 659 mbits
openvpntcp+sslh: download - 794 mbits; upload - 693mbits
openvpntcp+stunnel: download - 619 mbits; upload - 943mbits
openvpnudp: download - 756 mbits; upload - 580mbits
open connect
Not the most popular tool for bypassing locks, it is included in the Streisand package, so it was decided to test it too.
download - 895 mbits; upload 715mbs
wire guard
A hype tool that is popular with Western users, the developers of the protocol even received some grants for development from protection funds. Works as a Linux kernel module, over UDP. Recently, clients for windowsios have appeared.
It was conceived by the creator as a simple quick way to watch Netflix while not in the states.
Hence the pros and cons. Pluses - a very fast protocol, the relative ease of installation and configuration. Cons - the developer did not initially create it in order to bypass serious locks, and therefore the guard is easily detected by the simplest tools, incl. wireshark.
wireguard protocol in wireshark
download - 1681 mbits; upload 1638mbs
Interestingly, the guard protocol is used in a third-party tunsafe client, which, when used with the same guard server, gives much worse results. It is likely that the windows client of the guard will show the same results:
tunsafeclient: download - 1007 mbits; upload - 1366 mbits
OutlineVPN
Outline is an implementation of the shadowsox server and client with a beautiful and convenient gui from Google's jigsaw. On windows, the outline client is simply a set of wrappers for the shadowsocks-local binaries (the shadowsocks-libev client) and badvpn (the tun2socks binary that directs all machine traffic to the local socks proxy).
Shadowsox was once resistant to the great Chinese firewall, but judging by the latest reviews, this is no longer the case. Unlike shadowsox, out of the box it does not support obfuscation through plugins, but this can be done manually by fiddling with the server and client.
download - 939 mbits; upload - 930mbits
ShadowsocksR
ShadowsocksR is a fork of the original shadowsocks written in python. In fact, it is a shadowsox to which several methods of traffic obfuscation are tightly nailed.
There are forks of ssR on libev and something else. The low throughput is probably due to the code language. The original python shadowsox is not much faster.
shadowsocksR: download 582mbits; upload 541mbits.
Shadow Socks
A Chinese block bypass tool that randomizes traffic and interferes with automatic analysis in other wonderful ways. Until recently, GFW did not block, they say that now it blocks only if you turn on the UDP relay.
Cross-platform (there are clients for any platform), supports working with PT like Torah obfuscators, there are several obfuscators of their own or adapted to it, fast.
There are a bunch of shadowsocks client and server implementations, in different languages. In testing, shadowsocks-libev acted as a server, clients were different. The fastest Linux client turned out to be shadowsocks2 on go, distributed as a default client in streisand, I can’t say how much more productive shadowsocks-windows is. In most of the further tests, shadowsocks2 was used as a client. Screenshots with testing of pure shadowsocks-libev were not made, due to the obvious lag of this implementation.
shadowsocks2: download - 1876 mbits; upload - 1981 mbits.
shadowsocks-rust: download - 1605 mbits; upload - 1895 mbits.
Shadowsocks-libev: download - 1584 mbits; upload - 1265 mbits.
simple-obfs
Shadowsox plugin, now depreciated but still working (though not always well). Largely superseded by the v2ray-plugin. Obfuscates traffic either under http-websocket (and allows you to spoof the destination header, pretending that you are not going to watch pornhub, but for example, the site of the constitution of the Russian Federation) or under pseudo-tls (pseudo, because it does not use any certificates, the simplest DPI such as free nDPI are detected as “tls no cert.” You can no longer spoof headers in tls mode).
Fast enough, installed from the repo with one command, configured very simply, has a built-in failover function (when traffic from a non-simple obfs client arrives on the port that simple obfs listens to, it forwards it to the address you specify in the settings - like this In this way, you can avoid manually checking port 80, for example, by simply redirecting to a website with http, as well as blocking through connection probes).
shadowsockss-obfs-tls: download - 1618 mbits; upload 1971mbits.
shadowsockss-obfs-http: download - 1582 mbits; upload - 1965 mbits.
Simple obfs in http mode can also work through a CDN reverse proxy (for example, cloudflare), so for our provider the traffic will look like http-plaintext traffic to cloudflare, this allows us to hide our tunnel a little better, and at the same time separate the entry point and traffic output - the provider sees that your traffic is going towards the CDN ip address, and extremist likes on the pictures are put down at this moment from the VPS ip address. I must say that it is s-obfs through CF that works ambiguously, periodically not opening some http resources, for example. So, it was not possible to test the upload using iperf via shadowsockss-obfs+CF, but judging by the results of the speedtest, the throughput is at the level of shadowsocksv2ray-plugin-tls+CF. I don’t attach screenshots with iperf3, because they are not to be relied upon.
download (speedtest) - 887; upload (speedtest) - 1154.
Download (iperf3) - 1625; upload (iperf3) - NA.
v2ray plugin
V2ray-plugin replaced simple-obfs as the main "official" obfuscator for ss-lib. Unlike simple obfs, it is not yet in the repositories, and you either need to download a pre-built binary, or compile it yourself.
Supports 3 modes of operation: default, http-websocket (with support for spoofing destination host headers); tls-websocket (unlike s-obfs, this is a full-fledged tls traffic that is recognized by any reverse proxy web server and, for example, allows you to configure tls termination on cloudflare servers or in nginx); quic - works via udp, but unfortunately the performance of quick in v2ray is very low.
Of the advantages compared to simple-obfs: the v2ray plugin works without problems via CF in http-websocket mode with any traffic, in tls-mode it is full-fledged tls-traffic, it requires certificates for operation (for example, from let's encrypt or self-signed).
shadowsocksv2ray-plugin-http: download - 1404 mbits; upload 1938mbits.
shadowsocksv2ray-plugin-tls: download - 1214 mbits; upload 1898mbs.
shadowsocksv2ray-plugin-quic: download - 183 mbits; upload 384mbits.
As I said, v2ray can set headers, and thus you can work with it through a reverse proxy CDN (cloudfler for example). On the one hand, this complicates the detection of the tunnel, on the other hand, it can slightly increase (and sometimes reduce) the lag - it all depends on the location of you and the servers. At the moment, CF is testing work with quic, but this mode is not yet available (at least for free accounts).
shadowsocksv2ray-plugin-http+CF: download - 1284 mbits; upload 1785mbs.
shadowsocksv2ray-plugin-tls+CF: download - 1261 mbits; upload 1881mbits.
Cloak
Clock is the result of further development of the GoQuiet obfuscator. Simulates TLS traffic, works accordingly over TCP. At the moment, the author has released the second version of the plugin, cloak-2, which differs significantly from the original cloak.
According to the developer, the first version of the plugin used the tls 1.2 resume session mechanism to spoof the destination address for tls. After the release of the new version (klok-2), all the wiki pages on the github that describe this mechanism were deleted; there is no mention of this in the current description of encryption obfuscation. According to the author's description, the first version of clock is not used due to the presence of “critical vulnerabilities in crypto”. At the time of the tests, there was only the first version of the cesspool, its binaries are still on the github, and among other things, critical vulnerabilities are not very important, because. Shadowsox encrypts traffic in the same way as without a clock, and the cloaca does not affect the crypto of Shadowsox.
shadowsockscloak: download - 1533; upload - 1970mbits
Kcptun
kcptun uses as transport and in some special cases allows to achieve an increase in throughput. Unfortunately (or fortunately) this is largely true for users from China, some of whose mobile operators are heavily throttling TCP and not touching UDP.
Kcptun is gluttonous as hell, and easily loads 100% 4 Ziono-Cores when tested by 1 client. In addition, the plugin is “slow”, and when working through iperf3, it does not finish the tests to the end. We focus on the speedtest in the browser.
shadowsockskcptun: download (speedtest) - 546 mbits; upload (speedtest) 854 mbits.
Conclusion
Do you need a simple fast VPN to wrap up the traffic of the entire machine? Then your choice is guard. Do you want proxies (for selective tunneling or stream splitting of virtual persons) or is it more important for you to obfuscate traffic from serious blocking? Then look at shadowsox with tlshttp obfuscation. Do you want to be sure that your Internet will work while the Internet is working at all? Choose to proxy traffic through important CDNs, blocking which will lead to the fall of half of the Internet in the country.
pivot table sorted by downloads
Source: habr.com