中国河南省地区的运营商似乎对IPV6没有那么强的审查力度/The operators in Henan Province, China, seem to have less stringent censorship regarding IPV6. #416
Comments
|
Are you using the same bridge line (网桥地址) on both networks? The bridge line contains either an IPv4 or an IPv6 address. If you use an IPv4 bridge line on a network that supports IPv6, you will still connect to the bridge using IPv4. So it may not be IPv6 support, but some other characteristic of the network that makes the bridge accessible. Maybe one of the networks is a wired network and the other is a mobile network? That can make a difference. If you have configured multiple bridge lines, a mix of IPv4 and IPv6, then it is possible that the IPv6 bridge lines start working when you are on a network that supports IPv6.
There are reports of different levels of blocking in Henan province. Usually, they say that Henan is more restrictive.
|
不，我仅仅使用了一个IPV6地址的obfs4网桥，以下是Tor日志。 No, I only used an obfs4 bridge with an IPV6 address. Below are the Tor logs. |
|
所有tor中继的IPv6地址都没有被GFW封禁。 None of the IPv6 addresses of tor relays are blocked by the GFW. |
|
一个tor中继出现在 tor中继列表一个小时以后就会被GFW封禁IPv4地址，但是tor中继的IPv6地址无论过去多久都不会被GFW封禁。 An IPv4 address of a tor relay will be blocked by the GFW after an hour, but the IPv6 address of the Tor relay will never be blocked by the GFW, no matter how long it has been. |
很不幸的，我在江苏时，在江苏省地区如果用IPV6 obfs4网桥，会立即被封锁（无论哪个运营商）。 我认为这可能是河南省的流量分析设备没有得到更新的缘故，但我向我的同学（他在河南省地区的运营商工作）询问时，他只是含糊不清地告诉我“我们在中国移动的内部会议上把这个叫做‘防洪’“。 而且我收到了很有趣的报告：
Unfortunately, when I was in Jiangsu, if I used the IPV6 obfs4 bridge in the Jiangsu Province area, I would be blocked immediately (regardless of which operator). I think this may be because the traffic analysis equipment in Henan Province has not been updated, but when I asked my classmate (who works for an operator in the Henan Province area), he just vaguely told me, “We call this ‘flood control’ at China Mobile's internal meetings.” And I received an interesting report:
|
|
河南的省墙也不管全随机数流量。 Henan's provincial wall also does not restrict fully random traffic. |
如果在IPV4下，这不成立（我使用Shadowsocks AEAD-2022和obfs4 iat-mode=0、1、2进行了一次测试，以Linode在一天之内给我发了最少四封关于实例被删除/开启的邮件为代价）。 我在这里的测试方法是：连接到某种反审查隧道后，立即传输最少30GB数据来试探河南省运营商的审查设备（的反应）。 如果你有兴趣我可以在这里贴一份录像，我对河南省的这些行为感到诧异（他们为什么会忽略这么大的漏洞？）。 This does not hold true under IPV4 (I tested with Shadowsocks AEAD-2022 and obfs4 iat-mode=0, 1, 2, at the cost of Linode sending me at least four emails a day about instances being deleted/started). My test method here is to immediately transfer at least 30GB of data after connecting to a certain anti-censorship tunnel to test the (reaction of) the Henan provincial operator's censorship equipment. If you are interested, I can post a video here. I was surprised by these actions by Henan Province (why would they ignore such a big loophole?). |
有些工作是出口GFW的事情，省墙不需要完成所有工作。比如封禁IP，目前没有看到省墙有物理意义上封禁IP的能力(空路由) Some work is the egress GFW's job, and the provincial wall does not need to do all the work. For example, IP blocking: currently, I don't see the provincial wall having the ability to block IPs in the physical sense (null routing). |
你说得对，我觉得可能我过于在意我家用的ISP的了（） （如果你觉得我说话方式很奇怪，呃，我患有自闭症且因此拿到了精神残疾证书，请见谅） You're right, I think I might be too concerned about my home ISP. ( ) (If you think I sound strange, well, I have autism and a mental disability certificate, so please forgive me.) |
啊 没事，我也是个ADHD( Ah, that's okay, I'm also ADHD. ( |
太好了，病友局（ASD+ADHD） 回归话题：类似的，如果在IPV6下用Shadowsocks AEAD-2022和obfs4 iat模式任意，甚至直接用Stream加密，那甚至都不会被运营商干扰（河南安阳-中国联通）。 然而，我在江苏省（我男朋友家里，运营商：江苏电信、江苏移动、江苏联通）就无法使用这个操作。有趣的事情：在测试obfs4 iat-mode=2时，我男朋友家的宽带突然间无法连通任何非中国大陆IP，就连ping都会全部丢包。 所以我对河南省的运营商审查诧异在于：他们是因为没有资金更换设备、还是说他们连熟悉IPV6的网络工程师都没有，才导致这些行为的吗？ 因为类似的情况我真的无法在河南省以外的省份复现，其他地区的运营商IPV6审查强度都比河南省高太多。 Great, fellow patient (ASD+ADHD) Back to the topic: Similarly, if you use Shadowsocks AEAD-2022 and obfs4 iat mode at will under IPV6, or even directly use Stream encryption, then it will not even be interfered with by the operator (Anyang, Henan Province - China Unicom). However, I was unable to use this configuration in Jiangsu Province (my boyfriend's home, operators: Jiangsu Telecom, Jiangsu Mobile, Jiangsu Unicom). An interesting thing: when I tested obfs4 iat-mode=2, my boyfriend's home broadband suddenly became unable to connect to any non–Chinese mainland IPs, and even pings would all drop packets. So I'm surprised by the censorship of operators in Henan Province: is it because they don't have the funds to replace equipment, or is it because they don't even have network engineers familiar with IPV6 that leads to this behavior? Because I really can't reproduce similar situations in provinces other than Henan Province, and the intensity of IPV6 censorship by operators in other regions is much higher than that in Henan Province. |
|
实际上tor的设计目前不能让IPv6单栈运行，否则如果 可以 以IPv6单栈连接tor守卫中继的话，那么都可以不要obfs网桥都能正常连入tor网络了。 至于现在能用IPv6连接obfs网桥，大概是obfs网桥目前可以用单栈IPv6来连接，而 tor守卫中继（入口中继）铁定是不能用单栈IPv6去连接的。 In fact, the design of the Tor network currently does not allow it to run with an IPv6-only stack. Otherwise, if it were possible to connect to the Tor guard relay with an IPv6-only stack, then it would be possible to connect to the Tor network without an obfs bridge. As for being able to connect to an obfs bridge using IPv6, it is probably because the obfs bridge can currently be connected using an IPv6-only stack, while the Tor guard relay (entry relay) definitely cannot be connected using an IPv6-only stack. |
所以江苏省的省墙应当是在干扰/审查/阻断 全随机数流量。但是我在河南，完全不了解江苏的情况，因此我的结论是根据你说的事实进行的猜测。 Therefore, the provincial wall of Jiangsu Province should be interfering with/censoring/blocking fully random traffic. However, I am in Henan and have no knowledge of the situation in Jiangsu, so my conclusion is a guess based on the facts you have stated. |
省墙应当主要审查的是应用层内容，网络层是v4还是v6并不重要。 The provincial firewall should mainly review the application layer content, and it does not matter whether the network layer is v4 or v6. |
另外还有个问题是，省墙不负责封禁IP，而出口GFW负责封禁IP。一旦涉及到封禁IP，就需要持续的追踪此IP在一段时间里流量显示出的状态（统计特征），这是挺费钱也费性能的。所以GFW才只能监控一部分IP的流量状态，所以当然也就不监控IPv6流量的 统计特征了。 而省墙阻断 流量 不是上面这个方式，省墙就单纯按连接来阻断，不需要统计什么东西（也不耗费多少算力），理论上可以对所有流量一视同仁。 Another problem is that the provincial firewall is not responsible for blocking IPs, while the egress GFW is. Once it comes to blocking IPs, it is necessary to continuously track the status (statistical characteristics) of the traffic displayed by this IP over a period of time, which is quite costly in terms of both money and performance. This is why the GFW can only monitor the traffic status of a portion of IPs, and of course it does not monitor the statistical characteristics of IPv6 traffic. The firewall blocks traffic not in the way described above. The firewall simply blocks connections without having to count anything (and without consuming much computing power). In theory, all traffic is treated equally. |
关于江苏省的随机数流量审查，刚好我们昨晚进行了测试。
我们昨天对江苏省（中国移动）的网络审查进行了测试，方法是Outline+prefix（伪造自己为HTTP）。 结果如图，在10.85秒就会被彻底封锁（同时，这个IP在南京市会被彻底封禁，即使是SSH连接。但在苏州移动却可以正常连接SSH）。 但是，带有prefix（伪造为HTTP 1.1）的outline服务器（同样的端口，都是853或者59201），在江苏省电信和江苏省联通不会遇到这个情况。然而，如果没有prefix，那么这三家运营商都会在十秒内封锁此地址（触发后封锁最少三十分钟，最高升级到南京市内无法连接这个IP）。 相关服务器端抓包文件在下方链接。 Regarding the randomized traffic inspection in Jiangsu Province, we happened to test it last night. We tested the network inspection in Jiangsu Province (China Mobile) yesterday by Outline+prefix (forging ourselves as HTTP). The result is as shown in the figure, and it will be completely blocked in 10.85 seconds (at the same time, this IP will be completely blocked in Nanjing, even for SSH connections. However, in Suzhou Mobile, SSH can be connected normally). However, outline servers with a prefix (falsely claiming to be HTTP 1.1) (the same port, either 853 or 59201) will not encounter this situation with Jiangsu Telecom or Jiangsu Unicom. However, without the prefix, all three operators will block the address within ten seconds (after triggering, the block will last at least 30 minutes, and it may be escalated to the point where the IP cannot be connected within Nanjing). The relevant server-side packet capture files are linked below. https://drive.google.com/drive/folders/1xFKbwhtoTefchQzGWm_s835WhRD43lJ6?usp=drive_link |
我很想试试这个，但是因为我不想再收到几次Linode关于实例删除/开启的邮件，我忽略此测试。 方法很简单，建立一个bridge=none的网桥，也就是仅声称自己是网桥但不使用任何”服务端传输插件“的”裸网桥“即可。 I really want to try this, but because I don't want to receive several more Linode emails about instance deletion/activation, I'll ignore this test. The method is very simple: create a bridge with bridge=none, that is, a “bare bridge” that only claims to be a bridge but does not use any “server-side transport plug-in”. |
The "dummy" transport in the examples directory of goptlib can do this. It acts like a pluggable transport, but it just passes the traffic through unmodified. You don't even need to run dummy-server on the server, you can run dummy-client on the client and give it the address of any ordinary Tor relay. UseBridges 1 ClientTransportPlugin dummy exec dummy-client Bridge dummy X.X.X.X:YYYY |
好的，明天测试一下。 Nice, I'll give it a try tomorrow. |
如题，我在中国河南省（使用的ISP：中国联通）居住。
当我在IPV6网络上连接obfs4 IAT-MODE=0的网桥时，这些网桥全部都可以正常连接。但反之切换到IPV4会立即失败。
类似的，我也直接使用Shadowsocks Stream加密，也不会遭到封锁。
我想知道这是否只是某个省份的个例，还是说在其他省份也可以复现？
As mentioned, I live in Henan Province, China (ISP used: China Unicom).
When I connect to obfs4 bridges with IAT-MODE=0 on an IPV6 network, all these bridges connect normally. However, switching to IPV4 fails immediately.
Similarly, I can also use Shadowsocks Stream encryption directly without being blocked.
I would like to know if this is just a case in a specific province or if it can be replicated in other provinces as well.
The text was updated successfully, but these errors were encountered: