Open KaraRyougi opened 1 year ago
@gfw-report @klzgrad
Some additional information of yet another layer of censorship device (傲盾) deployed at the provincial level:
It is said that the default IP of these devices is 10.80.20.1. You can traceroute / ping this IP directly from your residential network. This has been confirmed by some people in Guangdong.
Thanks for this information. I don't see anything clearly anomalous in Cloudflare Radar or IODA between 10:45 and 15:00 UTC on 2023-05-12 (which doesn't mean the reports are incorrect). The Psiphon Data Engine looks like it does not have data from the past few hours yet.
If anyone has experienced new kinds of interference, please post in this thread.
https://radar.cloudflare.com/cn
https://ioda.inetintel.cc.gatech.edu/country/CN?from=1683653054&until=1683912254
I have received increased reports of blocking of NaiveProxy in recent days but it is different from your report in nature: detected and blocked on per-connection basis, activated after detection in realtime, enforced by packet dropping, the same server is partially blocked from some client regions, and can recover in tens of minutes. I think it is technically unrelated to your report, but may be related in the trend of decentralizing censorship systems.
昨天我正常使用ssh打命令也断了,ping发现国外IP全部不通,切换为ipv6就好了,只不过我在ssh控制台上用vim一直复制粘贴.
Yesterday I used ssh to enter commands normally also broke, ping found that all foreign IP is not available, switch to ipv6 on the good, but I use vim in the ssh console has been copy and paste.
enforced by packet dropping
I have now observed this behavior for SSH blocking - no TCP RST packets, just packet drop. The SSH blocking will also trigger an international traffic ban.
I can't reproduce the ICMP ping test (CMCC Guangdong)
traceroute to 10.80.20.1 (10.80.20.1), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 0.532 ms 0.508 ms 0.532 ms
2 192.168.1.1 (192.168.1.1) 1.498 ms 1.465 ms 1.802 ms
(privacy related redacted)
7 120.198.176.74 (120.198.176.74) 22.878 ms 32.183 ms 27.729 ms
8 * * *
9 * * *
10 * * *
Iran is experiencing a massive firewall update too. In the recent days, most of IPs got blocked. cloudflare worker which worked nicely in past few days, and also clean IPs of cloudflare, both experiencing heavy issues at the moment.
@wkrp
Per https://www.cloudflarestatus.com/, at May 12
Cloudflare identified a drop in traffic from China sources, however it was found that this is not due to any issue with Cloudflare services. Connectivity from some locations inside China may continue to experience performance issues.
No further details, though.
On Sat, May 13, 2023, 1:44 AM wkrp @.***> wrote:
Thanks for this information. I don't see anything clearly anomalous in Cloudflare Radar https://radar.cloudflare.com/cn or IODA https://ioda.inetintel.cc.gatech.edu/country/CN?from=1683653054&until=1683912254 between 10:45 and 15:00 UTC on 2023-05-12 (which doesn't mean the reports are incorrect). The Psiphon Data Engine https://psix.ca/d/nyi8gE6Zk/regional-overview?orgId=2&var-region=CN&from=1683308294852&to=1683913094852 looks like it does not have data from the past few hours yet.
If anyone has experienced new kinds of interference, please post in this thread.
https://radar.cloudflare.com/cn
[image: Internet traffic trends in China | Last 7 days | May 12 2023 17:19 UTC] https://user-images.githubusercontent.com/41267675/238040712-f519f8a2-f395-406c-8d58-cc3442b44e92.png
https://ioda.inetintel.cc.gatech.edu/country/CN?from=1683653054&until=1683912254
[image: Internet Connectivity for China: May 9, 2023 5:24 pm - May 12, 2023 5:24pm UTC] https://user-images.githubusercontent.com/41267675/238040395-7c59c5df-6a62-4024-baed-4453b3ba7d39.png
— Reply to this email directly, view it on GitHub https://github.com/net4people/bbs/issues/248#issuecomment-1546079411, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6LC6ZGAZB2FT7EGZD5BH3XFZZJNANCNFSM6AAAAAAX7VFAGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Per https://www.cloudflarestatus.com/, at May 12
Link to the specific incident (archive):
- Investigating 2023-05-12 09:59
Cloudflare is investigating issues with network performance in China. Some end-users located in China may see an increase in errors or timeouts when trying to reach specific Cloudflare IPs.
We are working to analyse and mitigate this problem. More updates to follow shortly.
- Update 2023-05-12 11:16
We are continuing to investigate this issue.
- Resolved 2023-05-12 12:12
Cloudflare identified a drop in traffic from China sources, however it was found that this is not due to any issue with Cloudflare services. Connectivity from some locations inside China may continue to experience performance issues.
It looks to me like Cloudflare investigated for 2 hours and found that they were not the cause of the problem. Possibly that means it was government network interference, though they don't say.
Wondering: if the client ignores RST, then this blocking method is useless?
It has been reported today (May 12, 2023) that there is yet another large scale blocking of proxy tools in China. We (AperNet) have also observed a sudden drop of our network traffic at around 18:45 China Time, but recovered soon after.
What is unusual this time is that:
(1) Once proxy traffic is detected, the user can face a total international traffic ban.
(2) The blocking happens near the end user, probably at the metropolitan area network level / on the same L2, which means traffic going through IEPL / IPLC is also subject to censorship now. This is evident by the facts that: (a) even a proxy connection to a domestic server can trigger the TCP RST, and (b) the forged TCP RST packets have exactly the same TTL as normal packets from the user, yet the IP option field is still 0. (TCP window size of the RST packets is also 0, btw.)
It seems TCP desynchronization techniques are still effective, though.
One data point indicates the blocking behavior disappeared at 23:00.