Streisand: Making a Streisand server resilient to blocking China

[ortonomy]

So, I cloned Streisand a few weeks ago, and despite some initial connection hiccups, I managed to set up Streisand on Digital Ocean in two locations, SF and LON.

Things were going grand, and then after a week or so of usage of Shadowsocks with Potatso on my iPhone, it all stopped working. I checked my server and it was running fine and if I used an already VPN'd connection, I could see the Streisand server, enter my password and get to the webpage for downloading clients and connecting to the various VPN services.

However, on any connection not already VPN'd and over the wall, the servers became inaccessible. I'm guessing that means the GFW had straight up blocked those IPs from being accessible any more and therefore cut my access to Shadowsocks (you can't use a proxy if the proxy itself is blocked.)

So, I wondered, anybody else running private Shadowsocks using Streisand in China, who _hasn't_ had it blocked after a few weeks? How do you avoid it? Do you rotate the ports that your server is on? Are there a 'suspicious' set of ports that the GFW looks for if an IP is using them, start blocking? I was all ready to celebrate having my own private VPN when the ban hammer came done...

Community thoughts?

[nickolasclarke]

There is lots of chat about this in previous issues, but basically the GFW
uses machine learning to detect behavior that suggests circumnavigation of
censorship and blocks/throttles the IP. I negotiate around this by using
new public IP's for my streisand instance whenever I detect such
throttling.

On Sun, Sep 25, 2016 at 11:39 PM Gregory Orton [email protected]
wrote:

So, I cloned Streisand a few weeks ago, and despite some initial
connection hiccups, I managed to set up Streisand on Digital Ocean in two
locations, SF and LON.

Things were going grand, and then after a week or so of usage of
Shadowsocks with Potatso on my iPhone, it all stopped working. I checked my
server and it was running fine and if I used an already VPN'd connection, I
could see the Streisand server, enter my password and get to the webpage
for downloading clients and connecting to the various VPN services.

However, on any connection not already VPN'd and over the wall, the
servers became inaccessible. I'm guessing that means the GFW had straight
up blocked those IPs from being accessible any more and therefore cut my
access to Shadowsocks (you can't use a proxy if the proxy itself is
blocked.)

So, I wondered, anybody else running private Shadowsocks using Streisand
in China, who _hasn't_ had it blocked after a few weeks? How do you avoid
it? Do you rotate the ports that your server is on? Are there a
'suspicious' set of ports that the GFW looks for if an IP is using them,
start blocking? I was all ready to celebrate having my own private VPN when
the ban hammer came done...

Community thoughts?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jlund/streisand/issues/413, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACE5KLvltX7H9LEaZfy0eAIKDsOUcCTUks5qt1p0gaJpZM4KGKBA
.

[ortonomy]

@kydan - yes, I'd read a few of the issues, but not really seen many solutions or work arounds. I'd have to look into digital ocean to see if there is a way of changing the public IP easily.

Do you have an automatic way of detecting the throttling that you could share?

Additionally - when you do that, how can you update the Streisand documentation (for example the generated docs on your computer) - do you know if there's a way? These are useful for sharing with family and friends.

[nickolasclarke]

Yeah currently I have a bit of a hack to work around the issues. First,
when I make a new instance of streisand, once it is complete I create a
snapshot of the new instance. I then have a simple node script that I run
that finds that snapshot, creates a new droplet from it, updates some of
the config files that rely on the external IP and then tears down the old
one. Unfortunately that is the only way you can currently get a new public
IP on DO. Other providers have more agreeable ways from what I understand,
especially AWS. I do not update the documentation at the moment, as I
mostly just use shadowsocks.

As for detecting throttling, I've played around with a few different ideas,
but right now I am using my devices frequently enough that I usually detect
problems quickly and can quickly run the script myself.

On Sun, Sep 25, 2016 at 11:47 PM Gregory Orton [email protected]
wrote:

@kydan https://github.com/kydan - yes, I'd read a few of the issues,
but not really seen many solutions or work arounds. I'd have to look into
digital ocean to see if there is a way of changing the public IP easily.

Do you have an automatic way of detecting the throttling that you could
share?

Additionally - when you do that, how can you update the Streisand
documentation (for example the generated docs on your computer) - do you
know if there's a way? These are useful for sharing with family and friends.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/jlund/streisand/issues/413#issuecomment-249484179,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACE5KEu5Chx_fGGKtXTbGWHBwAE2DRCGks5qt1xwgaJpZM4KGKBA
.

[denoza]

I have also had problems with DO. I think it is a provider issue. Some provider's work well compared to DO. For example: I have had less problems with vultr compared to DO. I think this thread will be useful for you. https://github.com/jlund/streisand/issues/190

[PeterRistCMS]

@kydan You mentioned you are updating some of the config files that rely on external IP.

Do you mind to share which config files those are? I'm in the process of changing the IP and somehow missing some files to change. So it would be really handy to have list to check against. Thanks.

[ortonomy]

@denoza - thanks for that. I don't want to sound ungrateful, but I don't think the thread of 'verified that it works here' is actually useful or that productive. The GFW is adaptive, so reading a report of even one day old that it 'works here' is not really 'current' so to speak.

Further to this, shadowsocks was always working for me, the issue was that the GFW actively banned the IP of my DO server. So no amount of checking if stuff works is going to bring it back.

This makes for interesting reading about the GFW's adaptive abilities: http://blog.zorinaq.com/my-experience-with-the-great-firewall-of-china/

[alimakki]

An interesting writeup by someone's experience with the GFW: http://blog.zorinaq.com/my-experience-with-the-great-firewall-of-china/

Could be some useful techniques for circumvention of the GFW.

[ortonomy]

@alimakki - that's the same article I referenced?

[alimakki]

@geligelu oh damn you're right I didn't notice it. :-/

[jlund]

I just merged in support for Shadowsocks One-time Authentication which reportedly helps with GFW resiliency in addition to its enhanced security properties. I'm interested to hear the results!

[nickolasclarke]

I'll spin a new one today and give it a shot!

On Mon, Oct 10, 2016, 06:54 Joshua Lund [email protected] wrote:

I just merged in support for Shadowsocks One-time Authentication
https://shadowsocks.org/en/spec/one-time-auth.html which reportedly
helps with GFW resiliency in addition to its enhanced security properties.
I'm interested to hear the results!

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/jlund/streisand/issues/413#issuecomment-252519029,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACE5KFm4Inenq5SoYCccJgdlVR_l7S3uks5qyXCZgaJpZM4KGKBA
.

[jlund]

Thanks to @yuanl for making OTA support happen!

[ortonomy]

@yuanl and @jlund - do I need to do any special configuration to enable this OTA feature?

[ortonomy]

@yuanl and @jlund - additionally, does this affect the Shadowsocks client more than it does the streisand dist?

[dbateyko]

@nickolasclarke , would you be up for sharing your node script? I'm having the same trouble with the GFW and starting up a new droplet each time another gets blocked has been pretty time-consuming.

[nickolasclarke]

@dbateyko yeah, let me clean it up for generic use and I'll send a link.

[dbateyko]

@nickolasclarke, awesome, thanks!

[cyberthal]

@nickolasclarke I'm also interested in using the script to automatically reprovision a DO Streisand instance. I didn't see it on your Github?

[nickolasclarke]

@dbateyko @cyberthal sorry for the long delay on this. The version I was running was EXTREMELY hacky, and was not suitable for general use. I used this as an opportunity to learn some new ES6 features in JS and I've since put my very rudimentary MVP into github for version tracking that you can see here: https://github.com/nickolasclarke/juke.

There are still a lot of hard-coded variables etc that are not documented, so essentially I am putting this here so you can track for progress on it when I finish it up. It works for my server, but it is not quite ready for general consumption. I think the rest should go quick though.

[Ev3y]

So the solution discussed here works with spinning up a new DO droplet from a Streisand snapshot and using a script to update to the new IP address from there. But what about working with server firewall rules to use DO's floating IP system for the outgoing connections? If this is possible to do, then one would still have to run a script to update the IP address, but it would first mean simply changing the floating IP of the server, instead of having to snapshot and redeploy the server.

With either solution it would be necessary to update the connection profiles, requiring the user to reconnect all of their devices; however, would it be possible to point the server to a static domain name that would have connection profiles generated for it just like for the IP address? This way, the user could use the new connection profiles if they wish, but if it was just the IP address that was blocked and not the domain name then the connection profiles would remain the same, without need of an update. All the user would have to do is point the domain name to the new IP address.

Also, while probably not useful for circumventing GFW IP-banning, using a floating IP for outgoing http/https requests could allow for quick changing of said floating outgoing IP for anonymity purposes, while not needing to update the connection profiles. This would require it to be possible to use a floating IP for such purposes, or it to be possible to change only the outgoing IP address in other providers, like AWS.

[nickolasclarke]

@Ev3y I'm doing much the same with my script, but not with floating IPs. I update a domain record hosted by DO with the new IP of the server with an extremely short TTL once the new instance is loaded and can be reached. Mileage in china varies though, as DNS queries to any DNS server outside the GFW, or even just to domains with primary DNS servers outside the GFW often are very spotty in many parts of the country. TBH, I usually still run with the IP instead and just have to update profiles by hand. Doesnt scale well. I'm also not sure what of the particular configurations for the different services that require information about the external IP (shadowsocks and L2TP/IPSEC, possibly others) can use a domain in lieu of an IP.

I looked briefly into DO floating IP's but it seemed more complicated than the solution I came up with. Either was going to require changing configuration files on the server, and simply nuking an old instance for a new one and grabbing the IP from the callback seemed like less configuration.

[jlund]

I just merged WireGuard support into the master branch today. I'm curious and excited to hear how this performs in China. Early results look promising, and its design should make it highly resilient to active probing attacks. If you are a Linux user in China, please give it a shot!

[cyberthal]

Thanks for your work on this. I will try to remember to check it out next time I need to reprovision my Streisand.

My Streisand IP gets blocked about once a month by the GFW. I use OpenConnect.

Are you suggesting that WireGuard may avoid this?

My understanding was that GFW was learning from the unusual amount of bandwidth going to a single IP address, and interdicting based on that. In which case, maybe changing protocol won't help.

[nickolasclarke]

@cyberthal @Ev3y I finally finished the MVP of Juke, my simple script for redeploying a streisand instance on DO that has been blocked. It currently only handles automatic reconfiguration of Shadowsocks, though other services may work without any changes to their configuration. I've not tested.

Its my very first complete node program and it still needs a lot of work. I've been using it as a learning exercise. PR's welcome if its helpful to you.

@jlund I'll spin a new instance and give wireguard a try asap!

[adespain]

https://nakedsecurity.sophos.com/2017/01/25/china-clamps-down-tighter-on-web-use-with-new-vpn-ban/

[denoza]

@nickolasclarke I have had problems with setting up wireguard from within China. I opened an issue in this regard #486. If you are able to use it successfully, I will be glad to have your suggestions.

[nickolasclarke]

@denoza I've got the server set up, but I've not yet tested the client since I primarily run windows. I'll try to do so this weekend.

[cyberthal]

Wireguard failed for me here:

$ sudo wg-quick up wg0-client
[#] ip link add wg0-client type wireguard
RTNETLINK answers: Operation not supported
wg0-client is not a valid WireGuard interface

On virtualbox guest manjaro xfce 64 bit.

[hydrandt]

@cyberthal There is a problem with your wireguard installation. How did you install it? Maybe you compiled wireguard from source and your kernel got updated? In that case go again to the directory with wireguard source and do make clean, make, make install.

[cyberthal]

@hydrandt I installed it through pacman, Manjaro's package manager. I'll try again after an update.

[jlund]

Did you install the Linux headers first?

sudo pacman -S linux-headers

[cyberthal]

@jlund Probably not. I recall searching unsuccessfully for how to do so.

I'll add that to the procedure, thanks.

[denoza]

WIreguard is a real beast. It works brilliant (until now) in China. And no other service matches its performance.

[cyberthal]

@jlund Linux headers are installed. Following the Streisand wireguard instructions yields the following error on an updated Manjaro 64 bit VirtualBox guest:

$ sudo wg-quick up wg0-client
[#] ip link add wg0-client type wireguard
RTNETLINK answers: Operation not supported
wg0-client is not a valid WireGuard interface
Usage: wg show { | all | interfaces } [public-key | private-key | preshared-key | listen-port | fwmark | peers | endpoints | allowed-ips | latest-handshakes | transfer | persistent-keepalive | dump]
[#] ip link delete dev wg0-client
Cannot find device "wg0-client"

[zx2c4]

Follow the instructions on https://www.wireguard.io/install/

[cpu]

Hi folks,

This issue ended up being a long & fairly free form discussion on a number of topics which makes it hard to treat it as an actionable issue on the repo any longer.

I'm going to mark this issue closed. If there are unresolved issues that the original participants still want addressed I'd encourage you to find pre-existing issues to add to, or to open a new issue if there aren't pre-existing ones for your topic. Thanks!