Evan-Sign
commented
1 year ago 这条信息让我十分困惑。
有网友称广东电信宽带部分区域墙SNI判断出错，DNS纯净即可访问除Google/Telegram/Twitter等时效性强的网站。
和
5.企业自己播的IP基本不行 比如纽约时报 Telegram这些不行 Google Reddit Twitter 时效性强的网站不行
- 这里的“时效性”和能不能访问有何关系？
- 纽约时报中文网CDN用的是 CloudFront、英文网站用的是 Fastly，这也算“自己播的IP”？
现在测试的域名还不够多，只有不到10个，没办法确定是检测 SNI 功能失效还是仅仅是解封了部分网站。
另外如果真如消息所写，仅仅检测 SNI 功能失效了，那么IP被封锁的网站仍然是不能访问的，和“时效性”和“自己播的IP”无关。
纽约时报中文网CDN用的是 CloudFront、英文网站用的是 Fastly，这也算“自己播的IP”？ 看来他们测试没有测试纽约时报中文网，我看了一下，纽约时报中文网与英文网站确实使用的CDN不同，但是它们所使用的静态资源域名的CDN均为 Fastly ，导致纽约时报中文网即使能打开，页面也是空白的，而他们测试过程中显然没有使用除出口为香港地区外的纯净DNS作为入口，导致解析到IP为 151.101 开头的 Fastly CDN IP，而这些 Fastly CDN IP 是被墙了的，在使用出口为美国的纯净DNS作为入口后，解析到的IP为 146.75.93.164 ... <nytimes.map.fastly.net> 而这个时候纽约时报英文网和中文网站都可以正常访问及正确加载静态资源。
这里的“时效性”和能不能访问有何关系？ bbc.map.fastly.net 是 www.bbc.co.uk 最终解析到的CNAME域名，可以看到尾缀为fastly.net表明 BBC 与 纽约时报 使用的网站均为 Fastly ，但我没有使用过 Fastly CDN ，我发现直接访问这两个网站解析出来的CDN IP会显示This server could not prove that it is 146.75.93.164; its security certificate is from nytimes.com. This may be caused by a misconfiguration or an attacker intercepting your connection.，Fastly 似乎给它们提供了专用的IP。通过使用出口为美国的纯净DNS作为入口的方法这次并没有奏效， 很明显 BBC 被屏蔽的比纽约时报还狠，可能是我上面所说的 因为其解析出的IP为 Level 2 SNI，146.75.92.81 同样为 146.75 开头，直接访问它们表现出的行为不同，证书为纽约时报的IP 146.75.93.164 可以打开，而证书为 BBC 的IP 146.75.92.81 则会出现 响应时间过长 或 连接被重置 的回应，通过抓包可以看到收到了来自 GFW 的重传回应。
现在测试的域名还不够多，只有不到10个，没办法确定是检测 SNI 功能失效还是仅仅是解封了部分网站。 希望更多人可以在这里提供他们想测试的域名和他们的测试结果，给出他们访问过程的详细叙述。
需要注意的是如果您的环境已经可以访问 Level 1 域名/网站，直连访问 Level 2 域名/网站并不是完全没有可能，只要您一直 F5 很明显有很小概率您可以成功访问。
This message is very confusing to me.
Some netizens said that Guangdong Telecom broadband is part of the regional wall SNI filtering error, clean DNS can be accessed in addition to Google/Telegram/Twitter and other timely sites.
and
- Enterprises with their own IPs basically do not work, such as the New York Times, Telegram, Google, Reddit, Twitter, and other timely websites.
- What does "timeliness" have to do with accessibility?
- The New York Times uses CloudFront as its CDN for its Chinese website and Fastly for its English website, are these considered "self-owned IPs"?
There are not enough domains tested, less than 10, to determine if the SNI function is not working or just unblocking some sites.
In addition, if it is true that the SNI function is not working, then the blocked websites are still inaccessible, and it has nothing to do with "timeliness" or "self-owned IPs".
"The New York Times uses CloudFront as its CDN for its Chinese website and Fastly for its English website, are these considered 'self-owned IPs'?" It seems that their test did not test the Chinese website of the New York Times. I looked at it, the Chinese website of the New York Times and the English website do use different CDNs, but the CDNs of the static resource domain names they use are all Fastly, resulting in the Chinese website of the New York Times, even if it can be opened, being blank, and they obviously did not use a clean DNS as the entrance, except for exporting to Hong Kong, resulting in the resolution of the IP as a "self-owned IP". The entrance of Fastly CDN IP is "151.101", and these Fastly CDN IP are blocked. After using a clean DNS for the United States as the entrance, it resolves to the IP "146.75.93.164" ... "
"What does 'timeliness' have to do with accessibility?" "bbc.map.fastly.net" is the CNAME domain name that "www.bbc.co.uk" eventually resolves to, and you can see that the suffix "fastly.net" indicates that both the BBC and the New York Times use the website Fastly, but I haven't used the Fastly CDN, and I have found that when I access the CDN IPs of these two websites directly, they will show "This server could not prove that it is 146.75.93.164; its security certificate is from nytimes.com. This may be caused by a misconfiguration or an attacker intercepting your connection." Fastly seems to be giving them dedicated IPs, and by using a clean DNS with an exit to the US as an entry point it didn't work this time around. Apparently the BBC is being blocked even harder than the New York Times, probably due to what I called "Level 2 SNI" above, and it's not a good idea to use it as an entry point because its resolved IP "146.75.92.81" also starts with "146.75", directly accessing them shows different behavior, the IP "146.75.93.164" with New York Times's certificate can be opened, while the IP "146.75.92.81" with BBC's certificate shows a long response time or connection reset response, through a packet capture shows retransmission responses received from the GFW.
"There aren't enough domains in the test right now, less than 10, to determine if the detection of the SNI feature is failing or if it's just unblocking some of the sites." Hopefully more people will chime in with the domains they'd like to test and their test results, giving a detailed account of their procedure for accessing them.
It should be noted that if your environment already has access to Level 1 domains/websites, direct access to Level 2 domains/websites is not completely impossible, as long as you keep F5 there's obviously a very small probability that you'll be able to access them successfully.
今年6月8日广东电信无信号事件发生的同时，收到来自广东多地电信网友的报告，同时有TG频道爆出：广东电信部分区域墙SNI判断出错。
其信息内容记录的实验非常详细，但过去快一个月，这期间群里还有网友在不断尝试，发现这个现象不但没有消失，而且还扩散了。
图为上海电信出现同样的情况：
原文中提到了
如果用的是CDN并且你是第一次连会RST的 第二次刷新基本上都可以但是并没有说明这意味着什么，虽然给不出切实的证据，但是我想提出几种猜想：城市边界防火墙，一种为国际出口防火墙，它们实际上叫什么无从得知，所以是猜想。城市边界防火墙阻断失败了，那国际出口防火墙也不会再花时间去阻断。城市边界防火墙的同步或者其同步的规则有问题，接下来可能会有更多区域能体验到墙SNI判断出错，但是也不排除在本贴发出后该问题立马得到修复。城市边界防火墙做的可能是：给予被墙IP空路由(目前条件仅能判断单向，方向为出)，SNI判断，SNI Level 2 阻断，对境外IP的UDP 53污染(双向)。国际出口防火墙做的可能是：给予被墙IP空路由(目前条件仅能判断单向，方向为入)，SNI判断，SNI Level 1 阻断，对境外IP的UDP 53污染(双向)。如果我的猜想是对的，那这种现象更像是阻断出错而不是判断出错，同时也解释了为什么只有用全球性的那种大公司CDN的网站才可以，因为有些公司或组织的域名只是SNI阻断出错了，自己播或自己用的IP还是被墙的。
同时今年6月下旬，开始收到来自广东多地移动网友的报告，内容差不多是：手机YouTube能直连，Google Play可以直连。 而群里也有不少人反映，他们所在的地区，上述服务所依赖的域名DNS污染已经消失了。
目前不太确定它们之间是否有关联，上面的信息与给出的时间可能均不准确，发这个贴子的目的是希望更多人能知道更多事，虽然并没有什么用，但是希望评论区能友好讨论，欢迎给出你们的看法。
June 8 this year, netizens in many places in Guangdong Telecom at the same time reported a no-signal event, at the same time a TG channel broke out: Guangdong Telecom part of the regional wall SNI judgment error.
It recorded very detailed experiments, but in the past almost a month, there are still netizens who are constantly testing, and found that this phenomenon not only did not disappear, but also proliferated.
The picture shows that the same situation occurs in Shanghai Telecom:
The original article mentioned "if you use a CDN and the first time you connect is RST, the second refresh is basically fine" but did not explain what this means, and while no tangible evidence is given, I want to put forward a few conjectures:
If my guess is right, then this phenomenon is more like a blocking error than a classification error, and also explains why only sites with global big company CDNs are OK, because some companies or organizations have domains with just SNI blocking errors, and the IPs that they broadcast or use by themselves are still walled.
At the same time in late June this year, began to receive reports from mobile users in many places in Guangdong, the content is more or less the same: mobile YouTube can be directly connected, Google Play can be directly connected. And a number of people in the group also reported that the DNS poisoning of the domains on which the above services depended had disappeared in their area.
I'm not quite sure if they are related, the information above and the time given may not be accurate, the purpose of this post is to make more people aware of more things. It's not really useful but I hope that the comment section will be a friendly discussion, feel free to give your opinion.