Properly configured Shadowsocks servers reportedly blocked in China? #69
Comments
|
自2021年3月起，至少三名用户汇报了他们的Shadowsocks服务器在使用了我们教程建议的配置后仍然出现不能ping通的情况。按照我们教程配置的Shadowsocks服务器本应可以抵御所有已知的来自GFW的主动探测以及（还未被GFW采用的）partitioning oracle攻击。 限于数据点有限，我们不能确定是审查者使用了新的检测方法，还是这只是个别用户的网络问题引发的误会。我们将迅速调查原因。与此同时，如果您曾按照这个教程配置Shadowsocks服务器，我们希望您能提供您的服务器的情况，包括被封锁了，或是运行正常的。您可以选择：
|
|
After calling for more users to report the status of their Shadowsocks servers from this post and from Twitter, one more user reported that "the Shadowsocks server configured according to the tutorial has been running stably for more than two months without any problem". We have been encouraging users to report any blocking they encountered; however, it is also important to know their servers are working properly. |
|
An up-to-date Outline server has been blocked in China. This server, located outside of China, has been running properly for more than two months, before it got blocked. The server possibly first got blocked around We confirmed this blocking on The result showed that only the Outline listening The blocking was |
|
July 1 will be the 100th anniversary of the Chinese Communist Party. Previous work shows that the censorship will usually be strengthened and advanced around these political sensitive period of time. While we will continue monitoring the censorship on Outline and other circumvention tools, we also encourage more users, developers and researchers to pay attention to the censorship in China this week. |
|
I'm using shadowsocks with chacha20-ietf-poly1305 by https://github.com/XTLS/Xray-core. |
|
@gfw-report I haven't heard of private servers being blocked. I know of a few providers that did not observe any issues recently. nthlink is a notable exception. They have always seen blocked servers, but their system is designed to deal with that via aggressive server rotation. However, as a centralized service, they are vulnerable to enumeration attacks, so it may not be Shadowsocks detection. This is the traffic from China as reported by the Outline servers that opted to share metrics: There aren't clear drops, except maybe a bit around April 19 and June 6, 2021. Keep in mind that the metrics are not from a random sample, so they may not be representative. The numbers are biased in an unknown way. Finally, I would like to point out that the choice of client does make a difference. The Outline client as well as the current shadowsocks-libev merge the socks header and initial user data in the same initial packet, which prevents fingerprinting based on packet size. Clients using an old version of ss-libev or other implementations may not be doing that and can expose the server. |
|
Another important thing to point out: if you are using plugins, that's not Shadowsocks anymore. I don't know how fingerprintable the different plugins are, so keep in mind that they could make you more vulnerable. |
|
I received a report about a shadowsocks-rust server being blocked in early June. The symptoms matched what was reported in #69 (comment): unidirectional, with only server-to-client traffic being blocked. At shadowsocks/shadowsocks-rust#556 (comment) there is the hypothesis that the replay filter itself is a feature that the GFW uses to detect Shadowsocks servers. The Shadowsocks server ignores client handshakes that reuse a previously observed salt. The replay cache is periodically reset. So an attack might look like this:
There's currently an experiment running to test the effect of the replay filter on detectability. shadowsocks-rust with the replay filter enabled was repeatedly blocked (different ports on the same host) in the past week. Disabling the replay filter stops the server from being blocked. This suggests that the GFW is using the behavior of the replay filter in response to active probes (in shadowsocks-rust, at least, and maybe in other implementations) as a classification feature. It may be possible to frustrate this new kind of active probing by changing the way the server remembers and reacts to replays. |
|
@wkrp Interesting finding. It would be great if someone else was able to reproduce the experiment, and include the Outline Server in the test, since it behaves a bit differently. My understanding is that the biggest issue for fingerprinting is modified replays, where you get different behavior when you modify certain specific bytes. Replay protection is a way to protect against that, but there are other ways. For instance, the coalescing of IV, SOCKS header and initial data means that if you modify any byte in the first packet you will still get the same result (timeout). You don't need the replay filter in that case. However, you will get different results if you modify the second packet (really the second encrypted chunk, which usually matches the packet). For example:
Is that a reasonable behavior? Can the attacker use that information somehow? If it's not useful to the attacker, then we don't need the filter.
Edit: Ignore the last part. Modifying any byte in the IV, SOCKS or initial data will still lead to a timeout these days. |
|
Thank you for reporting on the blocking, @maker2002. While we have no evidence that the blocking is caused by the active probing attack, our initial testing indeed suggests that the Xray implementation of Shadowsocks has active probing weaknesses. These active probing attacks have been previously proposed by Frolov et al. and found being used by the GFW (Alice et al.). We have opened an issue here: XTLS/Xray-core#625 It is worth noting that Outline servers have fixed this weakness for a long time and we tested and confirmed that such weakness did not exist in the latest version of Outline server. In other words, this weakness cannot be the causes of the blocking of this Outline server: #69 (comment) |
|
Thank you for your summary and insights, @wkrp. We left our observations and thoughts here: shadowsocks/shadowsocks-rust#556 (comment)
We will design and conduct experiments to validate/falsify @Mygod 's hypothesis. We will include Outline.
That's a key insight. |
|
There is another report about shadowsocks-rust with xray-plugin got blocked here: shadowsocks/shadowsocks-rust#549 (comment) And raw shadowsocks blocked in 3 days: shadowsocks/shadowsocks-rust#549 (comment)
|
|
I believe the best thing to do now is to reproduce the replay filter toggle experiment with a tcpdump packet capture. This can provide us with detailed intelligence about the behaviour of censorship tools. Currently, the user report based intelligence gathering is not very useful other than providing clues. If the replay filter is proven to be the vulnerability exploited by the the GFW. The method to resolve it isn't the removal of this security feature, but to return random data of a calculated length to the attacker's client instead of shutting down the connection or returning no data when a replay is detected. An attacker without the required secret key cannot tell the difference between random data or valid server responses(when done carefully). Thus, returning random data achieve the same goal as turning off the replay filter without security complications. We should always try to reduce the compromise on the security aspect of proxy implementation. (This post express the personal opinions of the author, instead of the affiliated V2Ray/V2Fly organization.) |
|
From #69 (comment):
@xiaokangwang This may open up new fingerprinting possibilities: send multiple repeated packets, look at the response size entropy. If random, then it's likely Shadowsocks, especially if varies widely. The average packet size may also give a clue. This reminds me of how ShadowsocksR gets detected (random packet sizes). |
Thanks @fortuna . That's correct, this is an issue I initially overlooked. There are two ways to solve this: The first one is to remember the original initial response length and replay random data of that length on replay. The second one is to maintain a database of destinations and their distribution of the lengths of the first reply. Both methods have performance issues and aren't perfect. Maybe the best way to resolve these kinds of issues in the long term will be to design a new protocol(or protocols) and migrate these kinds of issues at the protocol level. Designing a new protocol that incorporates server-side random into sessions can eliminate the need for replay checking. However, it still needs to consider how should it respond to an invalid message from a remote peer. A little out of topic thought, the root issue here is: how should a censorship resistance tool react when it encounters an invalid message. |
|
From #69 (comment):
Thanks @gfw-report! If you use the stock Outline Server using the Outline Manager or the install script, you will get replay protection enabled. If you need to disable it, you will have to use outline-ss-server directly. The replay protection is disabled by default in outline-ss-server. You can increase the number of recorded salts with Note that the protection against replays of server data is always on, regardless of the |
|
An up-to-date Shadowsocks-libev server has been blocked in China. This server, located outside of China, has been running properly since Jun 24 2021, before it got blocked on July 20. The server was configured strictly following this tutorial. We confirmed this blocking by 1) sending ICMP pings to the server ( The result showed that only the Shadowsocks-libev listening port was blocked, not the entire IP address. Particularly, ICMP pings from China could still receive echo reply. The blocking was single directional, meaning the censor only dropped packets from server to the client; SYN packets from China could still reach the server. |
|
@gfw-report Did the server have replay protection enabled or disabled? How is the experiment going? |
Yes, the Shadowsocks-libev server has replay protection enabled.
Starting from July 12, we ran two outline servers on two different IP addresses within the same subnet outside of China. The server were configured following your instructions. The only difference is that one server has replay protection enable, while the other has replay protection disabled. We then make two connections to each server every 15 seconds from China. The underlying proxies traffic is HTTP and TLS. Neither of the servers has been blocked yet. |
|
You might need to crank up the number of connections. Three to four days at most should be enough to trigger from my experience. |
|
Keep in mind that the Outline server and shadowsocks-libev have slightly different behaviors. @gfw-report: Was the blocked shadowsocks-libev server receiving the same pattern of traffic? |
|
My wife just moved back to the Mainland temporarily and we couldn't communicate using Signal anymore. I first tried to install the TLS-Proxy but that didn't work. A OpenVPN connection also didn't help. Then I came across this thread and gave it a try to install the Shadowsocks server using the tutorial linked above (https://gfw.report/blog/ss_tutorial/en/). Installation was smooth and quite flawless. Using the OpenVPN connection she managed to download the Outline client and I could send her the ss-link via WhatsApp (I specifically avoided WeChat). She could connect to my Shadowsocks server and now we can use the Signal messenger again. Even a 3-way video call worked pretty well, even though it says it's not perfect for streaming. The client also works on her PC now and she can access her Google mails and other company stuff she needs. Since the OpenVPN is flaky but Shadowsocks seems to work just fine. Since she's the only one to use my server, I would hope it'll fly under the radar and won't get blocked, but yeah. Let's stay optimistic. Just for information. The server is in Hong Kong and runs on a Raspi 4 with Ubuntu 20.04. Thank you guys for that clear tutorial and all this work. Highly appreciated to stay connected. |
|
It seems my optimism was a bit too early. The VPN now seems to be no longer working. When doing a DNS Leak Test, my wife gets various IP addresses, instead of the single one from my Unbound server on my network. Would it help to just change the password? Or password and URL? Any other tips? |
|
Hi @MatthK - I’m the Product Manager for Outline. Can you confirm the DNS Leak Test problem was occurring with the Outline Client? If so, can you give us more details such as on which platforms, with which leak test, and whether the problem persists if she restarts the client? I’m trying to understand whether the client is crashing on her devices and that’s the source of the test discrepancy. |
|
Hi, @MatthK
DNS Leak Test detects if there is a misconfiguration of the DNS setting, not the proxy itself. It is used to detect whether your DNS traffic(which includes your abridged browsing history) is sent to an unintended server. You may update your system DNS, and browser proxy settings to prevent DNS leaks. It does not show who can your proxy or who have used it. It does not show whether it has been blocked or sabotaged. If you suspect the connection credential is leaked, you can update the password to prevent other people from connecting it with the old password. This does not prevent censorship agency from blocking your proxy with the connection credential since blocking it would only require the IP address(and optionally the port number) for an ss proxy. Your connection credential may leak during transit or after it arrived on your device. On some platform, software installed on the system or the operating system itself will scan your files and upload them to the vendor's server. Why do you think it is no longer working? Is it because of a DNS leak, or you can no longer connect to it? P.S.: I don't think this is supposed to be a user support ticket system. (Since we are already here you can submit more feedback to help us find the true issue. I have no intention to suppress discussion.) |
|
"I don't think this is supposed to be a user support ticket system." OK, point taken. |
Likewise acknowledged. Apologies. For Outline questions feel free to use our tracker or Reddit r/outlinevpn. On topic - I’m still curious about if the test results from @MatthK mean that the proxy was not working and thus we cannot rely on the previous data point that it hasn’t been blocked. (Sorry for the triple negatives.) Is there other evidence that it is working? (Visiting blocked sites, Signal working, etc.) |
|
@cjhenck It's clearly working. Outline client doesn't have a routing system like many other popular censorship circumvention solutions in China. When it's connected, everything gets proxied through the remote shadowsocks server, so you either have working Internet, or nothing works. |
|
I don't have a problem with helping to diagnose user issues, as long as it's relevant to the topic. Anything specific to Outline configuration is probably better handled in an Outline forum. But like @cjhenck, I am curious the two facts that @MatthK posted, which may or may not have the same cause:
If the Outline connection stopped working, there could be many causes. There could be a problem at the server, or at the client, or there could be some kind of interference in the middle (such as the server being blocked by a firewall). What specifically is going wrong is something you can troubleshoot with the Outline devs. But it would be consistent with other observations that the GFW has somehow identified the server as an Outline server and blocked its IP address and port number. An easier way to check if requests are going through the Outline proxy (easier than doing a DNS leak test) is visit an IP-checker web site (e.g.), or just Google "my IP address", and see if it matches the IP address of the Outline server. If it does not match, but the client is able to browse various sites, then there's a good chance there's some kind of misconfiguration or the Outline client just isn't running. As @database64128 says, it's unlikely that Outline would leave you with a "half-working" setup. I don't know how the DNS leak test works, but it's possible that even if the Outline server is configured to use a designated resolver, the test reports the IP addresses of upstream recursive resolvers. I wouldn't take this test as conclusive, unless you also have results from when the VPN was working that show a difference. But the mention of DNS leaks does bring to mind a hypothesis for how Shadowsocks servers might be discovered: Hypothesis: The GFW takes advantage of misconfigured clients with leaky DNS to help discover circumvention servers. It identifies source IP addresses that (1) make a DNS query for a name that would normally be blocked, then (2) begin a TCP session with an unclassifiable protocol. When this happens often enough, it blocks the destination IP address / port of the TCP session. However, this hypothesis has a major flaw, which is that a Shadowsocks client with leaky DNS is likely not to work well, because of the GFW's DNS poisoning. The client would query a DNS name, get a poisoned (useless) IP address in response, give that IP address to the Shadowsocks server through the tunnel, and the Shadowsocks server would simply fail to connect. A configuration that leaks DNS would probably be noticed by the user quickly, at least in China. Tor emits a warning ("Your application is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information.") when it gets a SOCKS request without a DNS name to resolve. A Shadowsocks client could similarly warn when it gets |
Such leaks are actually pretty common with misconfigured V2Ray setups. Most users configure V2Ray with both domain rules and IP rules. A typical setup is to first check if the domain is in the Chinese domain list. If not, resolve the domain using the configured DNS servers and then check if the resolved IP is a Chinese IP. If not, then V2Ray makes the request using the original hostname (not the resolved IP address) via the proxy. This setup would've been fine if the routing rules ensure that traffic to these configured DNS servers goes through the proxy. However, many users add Chinese DNS servers in hopes that it would prevent unlisted Chinese sites from being proxied, which is a totally unnecessary but very dangerous action. These DNS servers are in the Chinese IP list, and therefore DNS queries are made with direct connection. And because the requests are made with the original target address preserved by default (not using resolved IP), when connecting to an endpoint with a "poisoned" DNS response, as long as the response is a non-Chinese IP, it would appear to be working just fine, because by default this invalid IP address is only used in V2Ray's internal router. To avoid DNS leaks, users should be advised against configuring V2Ray with Chinese DNS servers. Examples with Chinese DNS servers in the official documentation should be removed or annotated with warnings. V2Ray does support placing some constraints to prevent certain DNS servers from being used to resolve certain domains. But it can be quite tricky to make it right. This is even worse with clients like Clash, where DNS queries don't go through its internal router, and always use direct connection. Clash is extremely popular among users of commercial censorship circumvention services. |
|
@MatthK Are you intended to use that Unbound server as your DNS server instead of the one provided by ISP or VPS provider? Can you still use the proxy to browse unrestricted Internet? It is possible that @MatthK intended to use a custom DNS server, and this DNS setting is overridden by the proxy software or socks5 protocol remote domain name resolution. I need more information to know whether the DNS server used is provided by a Chinese ISP or the VPS provider. If it is from the VPS provider, then @MatthK didn't configure his computer to use that Unbound DNS server, and the proxy is working as intended. If the DNS server is provided by a Chinese ISP, then a DNS leak happened. The proxy connection for web traffic is likely to be working as intended. If the ss server is blocked, the DNS leak test will not be able to complete. The DNS leak test requires a working connection, with or without a DNS leak. |
|
Strangely, the two Outline servers mentioned in this comment have still not been blocked yet as of August 6, 2021. |
|
I have only been lightly following this thread and missed that @MatthK was trying to use alternative DNS servers. Outline currently hard codes the DNS servers in the client. We've had requests to allow clients to override it but my personal feeling is that Outline's client strength is simplicity rather than advanced functionality (where shadowsocks-android and others shine). However, I do want to eventually remove the dependency on third-party DNS and rely on a DNS forwarder on the VPS so the server operator can specify the recursive, but we don't have the bandwidth at the moment to implement that. |
|
@MatthK, thanks for the report, but we need more information.
What makes you conclude that?
Getting multiple IPs doesn't mean a DNS leak. Those tests are misleading, they expect the IPs to match your ISP. With Outline, they won't match. You should expect to see a backend IP from OpenDNS, Cloudflare or Quad9. This IP may not even match the IP or the resolver you talk to because the resolution may be delegated. My best guess is that the client was not working. The Windows and Linux clients have some issues handling network changes, which is hard since they don't provide a VPN API we can use. If that's the case, disconnecting and reconnecting should work. You may need to close the app first. |
|
OK, here's a bit of background. I have currently two shadowsocks server running at my home in Hong Kong. Each runs on a Raspberry Pi with Ubuntu 20.04 LTS. They each use different passwords ( I also have a Pihole installed which uses a local unbound server as the forwarding resolver. The Router is blocking any DNS requests via NAT rules (Port 53 and 853) and points them to my unbound config. If you're on my network, you pretty much get DNS from my little Raspberry, unless you use DNS over HTTPS. I prefer to keep as little a digital trace as possible, so that's why I prefer to do the DNS resolving myself. When I try to configure various clients at my home to use 8.8.8.8 as the DNS Server and then do the DNS leak test, I always only see my own public IP as the result. Single address, never multiples. So I assume, my setup does the intended job. The initial setup (of the Shadowsock server) was done, cos the pre-installed OpenVPN wouldn't let her connect to Signal, which is our families messenger of choice. So when I say "it's (not) working", then I usually mean that connecting to read and write messages in Signal is working (or not). My wife also managed to install it on her notebook, which allowed her to connect to her GMail account. Besides that, we don't use the VPN for much else. After the initial setup, using Signal was again possible, and we even managed to get a decent 3-way video call to work. Now a few days ago, she complained and said she can't use Signal anymore. While she can get a connection to the SS server, Signal remains mute. I asked her then, to do the DNS leak test, which showed a bunch of mainland China IP addresses/domains. Here's the partial list she got: I asked her to verify that the DNS server in her Outline profile points to my pihole (192.168.7.3) but had to realize, that there's no way to configure that in the iPhone Outline app. On my Android Shadowsocks client, I can configure this. Yesterday she could connect again when I sent her a link to my second server. This morning, it doesn't work again. She can connect to the server, even received messages in Signal, but can't send any. I asked her to restart the app, and even restart her phone. Now here comes the strange part. Although my wife was about to give up, I asked her to do the IP check and DNS leak tests again. A couple of tries with connecting to both servers, and suddenly it works again. All DNS leak tests show my home address only and Signal works, both for receiving and sending messages. I feel quite embarrassed, because it looks more like it was a user fault rather than a systematic problem. Or it was some random fluke (unlikely, I know). And unfortunately I can't try it myself, as I'm not in the mainland. I did experience though previously (more than two years ago when I still was myself in the mainland) some randomness with my OpenVPN connections to my home. Sometimes it did work, while a half an hour later it suddenly wouldn't anymore, to then work again a day or so later. PS: This is not meant to get support. I'm just trying to point to some potential issues. It could be, that I have screwed up some things, but I'm just trying to point out (potential) problems that might affect others that really need to rely on this solution. PPS: I obviously didn't share the SS-Links through Wechat, as I perceive this channel as compromised. I did send her the links only through WhatsApp (less preferred channel) or then directly in Signal (once it was working). But talking about VPN and Signal in Wechat might have triggered some flags and could have put her phone under special watch? |
|
@MatthK The Outline Client UI on iOS can be glitchy sometimes. It might display "connected", but the settings app says "not connected". Make sure to double check with the system VPN settings. For iOS, I would recommend eycorsican/leaf. It's a lot more reliable than Outline Client on iOS devices. The App Store link is in the project's README. |
|
Ok, that would at least explain to some extent the seen behaviour. If Outline claims it has a connection, when in fact the system is not, then the DNS leak test would obviously show the above results. |
Server: shadowsocks-rust v1.11.2 I think I have encountered a similar situation. I run shadowsocks service for many friends (in China). Every once in a while (log starting last year), one of my friends would report to me that their service was not usable. However, other services using other ports like other users' shadowsocks, SSH 22, HTTP 80 443, ICMP are fine. Then I asked the cloud service provider, they told me everything was fine. This problem can be solved by changing IP, so I didn't care much. Last night I decided to figure it out. A friend told me his port was not accessible again. So I moved the IP to another NIC, removed the shadowsocks on this port, opened SSH port, then I SSH to this specific port. The first few SSH tries were not working. I was angry typing the ticket to the cloud provider. Then I tried one access with IP:port instead of DOMAIN:port, the port was accessible again. This didn't make sense to me last night... But since you brought it up here, I think it might be the same case. I will continue to test and try to observe this problem again. Could anyone tell me how to tell if it's a |
@RebelliousWhiz A single directional block cannot be easily diagnosed with a software log. Packet capturing is the most reliable method for detecting this kind of restriction. To create a packet dump, run Speaking of a single directional block, is it possible for us to create a tool that workaround this with source address forging? |
ReQrypt (previous discussion here) is kind of like that, but in the wrong direction for the GFW. It effectively spoofs in the client→server direction, and allows packets to flow naturally in the server→client direction.
|
|
On November 6, 2021, a user reported that a Shadowsocks-libev server (3.3.5-1, edge channel) configured according to this tutorial got blocked after a week of use. In particular, the config file is as follows: {
"server":["::0","0.0.0.0"],
"server_port":[REDACTED],
"encryption_method":"chacha20-ietf-poly1305",
"password":"[REDACTED]",
"mode":"tcp_and_udp",
"fast_open":false
}Since neither the server nor the service got restarted during the week-long usage, it is less likely that the replay filter got reset. The blocking is done by dropping packets as the user reported:
The user also reported seeing "a lot of TCP Retransmission" on the server side, indicating that it is likely that the SYN+ACK packets from server to client got dropped. |
|
Since the GFW has been reportedly doing port blocking, rather than IP blocking, the following small trick may mitigate the incovenience when port blocking happens. A user can run the following command on server to redirect both TCP and UDP traffic ranging from port sudo iptables -t nat -A PREROUTING -p tcp --dport 12000:12010 -j REDIRECT --to-port 8388
sudo iptables -t nat -A PREROUTING -p udp --dport 12000:12010 -j REDIRECT --to-port 8388Remember to:
This way, whenever a port on server got blocked, a user only needs to change the configurations of server_port on the clients, without having to login to the server, change configuration, and then restart Shadowsocks. For example, if you had been using port When properly configured, the output should look like this: sudo iptables -t nat -L PREROUTING -nv --line-numberChain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:12000:12010 redir ports 8388
2 0 0 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:12000:12010 redir ports 8388Note that setting a PREROUTING rule on ephermeral ports ( |
|
With outline-ss-server, you can set up the same credential on multiple ports, without having to deal with iptables. The config format is quite straightforward (example). |
|
Between August 19 and 22, 2022, we received twelve user reports on the blocking of their properly configured Shadowsocks and Outline servers. Before getting blocking, their servers had been running properly for a relatively long time, ranging from 25 days to 13 months. Two Chinese discussion threads are available at here and here. From the user reports and our testing on two blocked servers that users granted us access to, this new blocking is different from the dynamic blocking of fully encrypted traffic since November 2021 in many ways. Below is a table for comparison:
Some additional details of this new blocking incident include:
Can you corroborate this new blocking incident from the traffic metrics of Outline? @fortuna |
|
I can also confirm this block. But I noticed the problem starting before Pelosi's visit to Taiwan. During that time, I suspected a few of my users were sending sensitive content through the internet, and I tried to isolate a few aggressive users. After a few attempts, IP still got blocked after a few days or so, and it has been consistently behaving like that. Changing IP can only solve the problem temporarily. Now I have to rely on my users' feedback to update the IPs. I have a few servers that can be used to identify the problem. If any of the developers need resources to test the find out the problem, please contact me. |
|
I have been providing stable services to my friends and family for quite a long time (stable for almost two years). I am pretty sure there's nothing wrong with the server configuration, IP latency, or package drop issue. I can also confirm there's no interference from Chinese malware like 360 virus scanner or Tencent PC protector. I noticed those software would restrict Shadowsocks traffic a long time ago, so every user of mine will be instructed to remove those software upon installation. |
|
Earlier this week, two of my servers' IPs were blocked in mainland China by GFW. Both servers were deployed using Outline Server, and has been stably operated for over a year and 6 months respectively. It is worth mentioning that these two servers use CN2 GIA route for connections between US and China. A newly assigned IP were blocked within a hour after another Outline Server deployment, which is never seen before. |
|
Shadowsocks-libev 还能用不？？ |
I suggest remaining calm as we do not know the exact reason for the block. Further observation is required. If changing IP can solve the problem temporarily, please try to take the temporary solution as needed. No need to panic as IP blocks can be random or unreasonable. In the meantime, I also suggest taking necessary security actions like hardening your Linux defense (like public key authentication, complicated password, self-deployed cloud images instead of cloud-provided images), using more secured shadowsocks encryption (like AES-256-GCM), or even applying an extra layer of VPN on top of your shadowsocks server to hide your fingerprint (like ExpressVPN or Surfshark). |
|
谢谢
rebelliouswhiz ***@***.***> 于2022年8月30日周二 11:41写道：
… Shadowsocks-libev 还能用不？？
I suggest remaining calm as we do not know the exact reason for the block.
Further observation is required. If changing IP can solve the problem
temporarily, please try to take the temporary solution as needed.
No need to panic as IP blocks can be random or unreasonable.
In the meantime, I also suggest taking necessary security actions like
hardening your Linux defense (like public key authentication, complicated
password, self-deployed cloud images instead of cloud-provided images),
using more secured shadowsocks encryption (like AES-256-GCM), or even
applying an extra layer of VPN on top of your shadowsocks server to hide
your fingerprint (like ExpressVPN or Surfshark).
—
Reply to this email directly, view it on GitHub
<#69 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2Z6RD6SO343GTT7ZPLTUU3V3V7ILANCNFSM43PWSMOQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Since March 2021, at least three users have reported that their Shadowsocks-libev servers became not pingable (temporarily in some cases) even after following the recommended setup in this tutorial (中文版). The tutorial documented how to setup a Shadowsocks-libev server that could defend against all known active probing attacks from the GFW as well as the partitioning oracle attack.
We document their reports in this post and we are taking immediate actions to investigate the causes.
At the same time, if you ever setup your servers by following our tutorial, we welcome you to report the status of your servers, no matter they are blocked or not. You can choose to:
Edited on May 5, 2021: add details from additional user report
The first report says that on the night of March 3, 2021, the server was not responding temporarily and since the morning of March 4, the server had not been pingable from at least two different network. The server remained not pingable for at least six hours until the user decided to discard the server. It appears that the user had setup the Shadowsocks server as recommended:
shadowsocks-libev 3.3.5-1 751 latest/edge max-c-lv -;chacha20-ietf-poly1305;openssl rand -base64 18;tcp_onlymode;ufwto only allow traffic to port22and the Shadowsocks port24xxx;The second report says that the server was not responding for half an hour on March 14, 2021, and has been working properly since then.
The third report says that the server was not pingable for approximately an hour on April 20, 2021, and have been working properly since then.
We were not able to find more reports on the recent blocking of Shadowsocks. Specifically, we looked up the open and closed Github issues in the following places:
The text was updated successfully, but these errors were encountered: