ghost commented 3 years ago

99 说过的，本人测试使用 `github.com` 或 `raw.githubusercontent.com` SNI 连接任意国外IP都会受到干扰。

github.com 第一次HTTPS握手并不会收到 RST ，但是看起来之后的到对应端口的连接都被路由黑洞屏蔽。

raw.githubusercontent.com 也有上述情况。有时可以看到RST，但是RST不能稳定触发。

连接被屏蔽的时间是60秒，或180秒，和RST行为相同。

其他域名，像FastGithub中写的 api.github.com *.githubassets.com 等不会受到这个干扰。

SeaHOH commented 3 years ago

不定时黑洞 github.map.fastly.net 解析结果的 IP 是一直存在的现象，这两天比较频繁。“这是由 SNI 触发的”，之前没有深究过，因为基本没有观察到过 RST，我以为首次 SNI 只会触发 RST。看你这么分析好像是有些与众不同，等下次观察到黑洞时我会实验下这个推测。

ghost commented 3 years ago

我是用 fastly.net , fastly.com 和 Cloudflare 的 1.0.0.1/24 测试的。

你可以重复看看

curl -v https://github.com --connect-to ::1.0.0.3

第二次或第三次一定 timeout 。

SeaHOH commented 3 years ago

刚刚正好遇到黑洞，实验了一下，然而其它 IP 上 githubusercontent.com 的多个子域名都未触发黑洞。你选择的 IP 是特殊的，确如你所描述之后会超时，估计是防御措施，换其它 IP 并不能重复此现象。

ghost commented 3 years ago

我只看到 raw.githubusercontent.com 会这样，其他子域名不会。

估计是防御措施

不可能的，我日常测试SNI重置就是使用 1.0.0.1/24。

SeaHOH commented 3 years ago

实验了多个，包含 raw，都不会触发黑洞。

SeaHOH commented 3 years ago

不要使用 Cloudflare 的 IP 来测试，部署有大量防御措施。

ghost commented 3 years ago

换 apache.org , un.org, example.com 结果一样。。。

SeaHOH commented 3 years ago

对的，你的测试方法有问题。我刚才静置了五分钟，然后空白 SNI 连接 raw.githubusercontent.com，并没有用，你这个 RP 是无效的。

ghost commented 3 years ago

其它 IP

是什么呢？

ghost commented 3 years ago

对的，你的测试方法有问题。

意思是，这三个都看到了黑洞

SeaHOH commented 3 years ago

做测试不要使用单一样本/条件

其它 IP

是什么呢？

随便找几个 IP 不属于 Cloudflare 的国外网站。

对的，你的测试方法有问题。

意思是，这三个都看到了黑洞

我指的是你先前的测试。你之后使用不同 SNI 得出一样的结果，这就说明你之前的试验设计有问题。

ghost commented 3 years ago

使用不同 SNI 得出一样的结果

我指的是 --connect-to 后的服务器

SeaHOH commented 3 years ago

使用不同 SNI 得出一样的结果

我指的是 --connect-to 后的服务器

我测试的结果，都用的是 github.com：

151.101.2.132 (apache.org) 未触发
157.150.185.49 (un.org) 未触发，偶尔会超时
93.184.216.34 (example.com) 未触发，偶尔会超时

ghost commented 3 years ago

希望大家不要跑题~

笑死

https://github.com/521xueweihan/GitHub520/issues/53

ghost commented 3 years ago

521xueweihan/GitHub520#53

不同地区测试结果有差。

SeaHOH commented 3 years ago

我现在正反向测试中，不再探究具体干扰机制，即配置空白 SNI，然后等待，看是否会出现被黑洞的时候，如果一直不出现，说明你这个应对策略是有效的。

SeaHOH commented 3 years ago

我发现我们俩对什么是 IP 黑洞这个现象有所分歧，黑洞和丢包都不会出现 RST。先描述一下，这里存在两种不同的无法连接的现象，以下 IP 指解析 raw.githubusercontent.com 得到的所有 4 个 IP，触发使用的 SNI 也是 raw.githubusercontent.com。

在一个时间段内，随机出现 IP 连接超时，但一定会有可连接的时候，看你们的测试，ICMP ping 应该始终是通的，其它端口也正常。
在一个时间段内，所有 IP 都连接超时，不论使用什么 SNI 设置，还未测试过 ICMP ping 和其它端口 (我认为是不通的)，等待机会确认。(https://github.com/URenko/Accesser/pull/103#issuecomment-907552910 已确认)

你观察到的 SNI 触发连接超时应该是前者，属于丢包 (ICMP ping 和其它端口都通畅)，这个现象是一直存在的，我之前以为这是单纯针对 IP，现在经过大量测试也已确认，如你所述 SNI 是必要触发条件；而我之前一直说的黑洞都是指后者，这个才是偶尔会出现。所以，我们之前对双方的测试结果和结论有所误会，不同地区/ISP 应该是没有太大差别的。丢包持续时间可能有区别，我这里最多六十几秒，没有出现过三五分钟的情况。

SeaHOH commented 3 years ago

空白 SNI 可避免平时的丢包，从这个角度来看，此 RP 是有效的。我之所以一直忽略这点，是因为我使用的工具会逐个尝试所有 IP，丢包对我没有造成实际影响，以致忽略。

SeaHOH commented 3 years ago

至于用这些 SNI 去触发其它不相干的 IP 丢包，使用其它不相干的 SNI 做对照。从我当前收集的数据来看，其触发丢包效果并不明确，不管是什么 SNI，丢包率都相差不大，而是主要和 IP 相关。

SeaHOH commented 3 years ago

我现在正反向测试中，不再探究具体干扰机制，即配置空白 SNI，然后等待，看是否会出现被黑洞的时候，如果一直不出现，说明你这个应对策略是有效的。

刚刚又出现黑洞了，空白 SNI 果然不行，对黑洞毫无用处。还没来得及测 ICMP ping 就又恢复了，继续等机会。

SeaHOH commented 3 years ago

间断密集型黑洞。。。

已经 ICMP ping 测试完毕，确实无回应，确认是真·黑洞。

今天黑洞真密集。刚才忘记测其它端口了，才测了 80 端口，果然是完全没反应。

SeaHOH commented 3 years ago

测试使用的 py 脚本，考虑不方便调用管理员权限，就直接调用 curl 和 ping，代码本身看起来简洁，但是输出比较杂乱，不如纯 py 脚本。

import os, time

# 排除代理干扰
os.environ.pop('HTTP_PROXY', None)
os.environ.pop('HTTPS_PROXY', None)

ips = '''
185.199.108.133
185.199.109.133
185.199.110.133
185.199.111.133
'''.split()

# 开始测试，不需要的项目可注释掉
while 1:
    for ip in ips:
        # 非黑洞，SNI 触发随机丢包可稳定重复
        os.system(f'curl -v https://raw.githubusercontent.com --connect-timeout 4 --connect-to ::{ip}')
        # 黑洞验证，非 443 端口
        os.system(f'curl -v http://www.microsoft.com --connect-timeout 4 --connect-to ::{ip}:80')
        # 黑洞验证，ICMP ping
        os.system(f'ping {ip}')
    time.sleep(2)

ghost commented 3 years ago

作为对照，可以在跑上面脚本之前（或者180秒后）看看空白SNI的情况

import os, time

# 排除代理干扰
os.environ.pop('HTTP_PROXY', None)
os.environ.pop('HTTPS_PROXY', None)

ips = '''
185.199.108.133
185.199.109.133
185.199.110.133
185.199.111.133
'''.split()

while 1:
    for ip in ips:
        # 模拟空白 SNI 连接
        os.system(f'curl -vk https://{{ip}} -H "Host: raw.githubusercontent.com" --connect-timeout 4 --connect-to ::{ip}')
        # 黑洞验证，非 443 端口
        os.system(f'curl -v http://www.microsoft.com --connect-timeout 4 --connect-to ::{ip}:80')
        # 黑洞验证，ICMP ping
        os.system(f'ping -w 3 {ip}')
    time.sleep(2)

SeaHOH commented 3 years ago

作为对照，可以在跑上面脚本之前看看空白SNI的情况

https://github.com/URenko/Accesser/pull/103#issuecomment-907551370 这里已经测试过空白 SNI 了，对黑洞毫无影响，只能避免触发丢包。

xljiulang commented 3 years ago

github.com是sni， raw.githubusercontent.com是sni+dns； https://github.com/dotnetcore/FastGithub/blob/master/FastGithub/appsettings/appsettings.github.json 目前fasgithub直接拦截网卡的dns数据包，解析匹配域名为127.0.0.1迫使流量转向fastgithub

URenko / Accesser

github.com and raw.githubusercontent.com #103

99 说过的，本人测试使用 `github.com` 或 `raw.githubusercontent.com` SNI 连接任意国外IP都会受到干扰。

URenko / Accesser

github.com and raw.githubusercontent.com #103

99 说过的，本人测试使用 github.com 或 raw.githubusercontent.com SNI 连接任意国外IP都会受到干扰。

99 说过的，本人测试使用 `github.com` 或 `raw.githubusercontent.com` SNI 连接任意国外IP都会受到干扰。