这是一个创建于 911 天前的主题，其中的信息可能已经有所发展或是发生改变。
有一种新方法可以测试 IP 有没有被墙。用这个方法甚至不需要拥有 IP 或者在上面开任何服务。
我们可以通过构建一个 DNS 请求来触发污染，同时检测有没有收到伪造的 A 记录结果来判断是否被墙。
以 dig.ping.pe 为例，
找了两个被墙的 IP ，第一个是被检测到有代理的，应该会在一段时候之后放出来。104.254.96.227
第二个大概率是永久屏蔽了。198.35.26.96
一个没有被屏蔽的 IP 。204.79.197.200
一个被反向墙的 IP ，应该也会在一段时间之后放出来。183.232.141.112
一个没有被反向墙的 IP 。58.32.16.1
选择一个被污染的域名，比如刚刚被污染的 patreon.com 。
在 dig.ping.pe 输入 dig patreon.com:TXT:被测试的 IP
104.254.96.227 和 198.35.26.96
墙内都收不到伪造的 A 记录。
204.79.197.200
可以收到伪造的 A 记录。
183.232.141.112
虽然被反向墙了，但是墙外还是可以收到伪造的 A 记录。不过不是很稳定，我推测墙的负载或者连接外国的速度和污染的成功率有关。这个 IP 的污染成功率比较低，说明跨国连接速度不够精品。
58.32.16.1
没有被反向墙的 IP 。外国稳定收到伪造的 A 记录。大概因为这个 IP 是电信精品网。
得出结论：
出墙的顺序是这样的。
墙内宽带-----屏蔽 IP 的设备-污染 DNS 的设备-----墙外。
所以如果 IP 被屏蔽了，是收不到污染结果的。
从墙外发送请求到墙内是一直可以收到污染结果的，即使墙内的 IP 被反向墙了，还是可以收到伪造的 A 记录，因为从外国到墙内方向屏蔽 IP 的设备在污染 DNS 的设备之后。
如果你是研究者，你可以通过这个方法测试有多少外国的 IP 被屏蔽了。也可以用这个方法测试域名有没有被污染。
探索污染成功率和跨国速度的关系。
有被屏蔽的外国 IP ，可以从这个 IP 构造触发污染的 DNS 请求到 58.32.16.1 ，看是否有伪造的 A 记录。按照推测的墙的设备位置，应该还是可以收到污染结果的。因为会先到污染 DNS 的设备再到屏蔽 IP 的设备。
我们可以通过构建一个 DNS 请求来触发污染，同时检测有没有收到伪造的 A 记录结果来判断是否被墙。
以 dig.ping.pe 为例，
找了两个被墙的 IP ，第一个是被检测到有代理的，应该会在一段时候之后放出来。104.254.96.227
第二个大概率是永久屏蔽了。198.35.26.96
一个没有被屏蔽的 IP 。204.79.197.200
一个被反向墙的 IP ，应该也会在一段时间之后放出来。183.232.141.112
一个没有被反向墙的 IP 。58.32.16.1
选择一个被污染的域名，比如刚刚被污染的 patreon.com 。
在 dig.ping.pe 输入 dig patreon.com:TXT:被测试的 IP
104.254.96.227 和 198.35.26.96
墙内都收不到伪造的 A 记录。
204.79.197.200
可以收到伪造的 A 记录。
183.232.141.112
虽然被反向墙了，但是墙外还是可以收到伪造的 A 记录。不过不是很稳定，我推测墙的负载或者连接外国的速度和污染的成功率有关。这个 IP 的污染成功率比较低，说明跨国连接速度不够精品。
58.32.16.1
没有被反向墙的 IP 。外国稳定收到伪造的 A 记录。大概因为这个 IP 是电信精品网。
得出结论：
出墙的顺序是这样的。
墙内宽带-----屏蔽 IP 的设备-污染 DNS 的设备-----墙外。
所以如果 IP 被屏蔽了，是收不到污染结果的。
从墙外发送请求到墙内是一直可以收到污染结果的，即使墙内的 IP 被反向墙了，还是可以收到伪造的 A 记录，因为从外国到墙内方向屏蔽 IP 的设备在污染 DNS 的设备之后。
如果你是研究者，你可以通过这个方法测试有多少外国的 IP 被屏蔽了。也可以用这个方法测试域名有没有被污染。
探索污染成功率和跨国速度的关系。
有被屏蔽的外国 IP ，可以从这个 IP 构造触发污染的 DNS 请求到 58.32.16.1 ，看是否有伪造的 A 记录。按照推测的墙的设备位置，应该还是可以收到污染结果的。因为会先到污染 DNS 的设备再到屏蔽 IP 的设备。
第 1 条附言 · 2022-06-06 00:27:58 +08:00
@philippiela 也可以用此方法测试端口的审查，都不需要拥有被测试的 IP 或者在 IP 上开服务。
举几个例子好了。对于任意端口发送 DNS 请求一样会触发污染。可以用这个工具。https://ping.sx/dig 。
对于任意端口访问 HTTP 的 store.steampowered.com 请求会触发 RST 。
对于任意端口发送 SNI 含有被审查的域名也会触发 RST 。
观察不到 RST 或者伪造的 A 记录就是端口被墙了。还有种可能是你选择的收发双方通讯不过墙，都在墙外 /墙内，或者就是专线了。
找了一个专线的 IP120.136.22.1 。只有部分路由走专线。查看 https://mtr.ping.pe/120.136.22.1 https://dig.ping.pe/patreon.com:TXT:120.136.22.1
只有使用联通 169 出墙的才会让外国 IP 收到污染，使用专线路由的无法收到污染。
举几个例子好了。对于任意端口发送 DNS 请求一样会触发污染。可以用这个工具。https://ping.sx/dig 。
对于任意端口访问 HTTP 的 store.steampowered.com 请求会触发 RST 。
对于任意端口发送 SNI 含有被审查的域名也会触发 RST 。
观察不到 RST 或者伪造的 A 记录就是端口被墙了。还有种可能是你选择的收发双方通讯不过墙，都在墙外 /墙内，或者就是专线了。
找了一个专线的 IP120.136.22.1 。只有部分路由走专线。查看 https://mtr.ping.pe/120.136.22.1 https://dig.ping.pe/patreon.com:TXT:120.136.22.1
只有使用联通 169 出墙的才会让外国 IP 收到污染，使用专线路由的无法收到污染。
第 2 条附言 · 2022-06-09 00:39:22 +08:00
最近另外的一个帖子被 Topic Not Found 了，我看着通知在这里回复一下。对于 404 表示理解，毕竟 mod 如果在香港或者要去香港，或者转机都可能有牢狱之灾。问题出在建墙的那帮人身上，让其他人要面临基本法附件三的威胁和其他风险，只能被迫审查了。
@S179276SP IP transit 应该不受到影响。很多印度，越南，马来西亚或者泰国连台湾都路过香港，那些测试点都显示正常的。
@czfy 差不多，一旦开了先河之后搞什么都肆无忌惮了。
@wwbfred 那个网页在 Government Service Network (GSN) AS4782 上。中时新闻用的是 Cloudflare 。不过确实有这种可能，被那个网页屏蔽了。但是起码内地是把那个 IP 的 443 端口墙了。
@LGA1150 确实可以收到污染的结果。但是这个方法只能检测 53 端口在不在名单上。用 cURL 还是可以测出来 443 端口是被墙封了。
8.8.8.8 的 443 端口被封锁了，而 9.9.9.9 没有。
curl --resolve 'www.bbc.com:443:9.9.9.9' https://www.bbc.com
OpenSSL SSL_connect: Connection reset by peer in connection to www.bbc.com:443
curl --resolve 'www.bbc.com:443:8.8.8.8' https://www.bbc.com
Failed to connect to www.bbc.com port 443: Connection timed out
curl --resolve 'www.bbc.com:443:210.69.230.67' https://www.bbc.com
Failed to connect to www.bbc.com port 443: Connection timed out
说明 210.69.230.67 和 8.8.8.8 的 443 端口都被墙了。
@txydhr 有点难验证。不过可以证明内地是把那网站墙了。
@S179276SP IP transit 应该不受到影响。很多印度，越南，马来西亚或者泰国连台湾都路过香港，那些测试点都显示正常的。
@czfy 差不多，一旦开了先河之后搞什么都肆无忌惮了。
@wwbfred 那个网页在 Government Service Network (GSN) AS4782 上。中时新闻用的是 Cloudflare 。不过确实有这种可能，被那个网页屏蔽了。但是起码内地是把那个 IP 的 443 端口墙了。
@LGA1150 确实可以收到污染的结果。但是这个方法只能检测 53 端口在不在名单上。用 cURL 还是可以测出来 443 端口是被墙封了。
8.8.8.8 的 443 端口被封锁了，而 9.9.9.9 没有。
curl --resolve 'www.bbc.com:443:9.9.9.9' https://www.bbc.com
OpenSSL SSL_connect: Connection reset by peer in connection to www.bbc.com:443
curl --resolve 'www.bbc.com:443:8.8.8.8' https://www.bbc.com
Failed to connect to www.bbc.com port 443: Connection timed out
curl --resolve 'www.bbc.com:443:210.69.230.67' https://www.bbc.com
Failed to connect to www.bbc.com port 443: Connection timed out
说明 210.69.230.67 和 8.8.8.8 的 443 端口都被墙了。
@txydhr 有点难验证。不过可以证明内地是把那网站墙了。
 |
1
Cipool 2022-06-05 17:35:59 +08:00 via Android
非常有趣的思路，收藏了
|
 |
2
wuvvu 2022-06-05 18:58:26 +08:00
不明觉厉，这个是什么原理
这个网页的 dig 命令最后一个参数不是指定 dns 服务器么，为什么可以这样来请求？ |
 |
3
myguybetter 2022-06-05 19:35:25 +08:00
这个思路不错，收藏了，正巧这两天 v 不稳定，试了下果然是中招了
|
 |
4
mmtromsb456 2022-06-05 19:47:07 +08:00  4
@wuvvu #2
看了两遍大概明白了原理,楼主漏了一个前提没有说,就是国内节点发起 DNS 请求的时候,如果 body 中是已经污染了的域名,那么哪怕目标 NAMESERVER 并不是一个部署了 DNS 解析服务的地址,GFW 依然会在网络中抢答这个请求并返回一个污染了的结果 如果这个目标 IP 已经是被封禁的状态,按照楼主推测的部署顺序,因为先经过封禁 IP 的设备再到 DNS 污染抢答的设备,那么无论国内 /国外都无法返回污染 /正确的结果 |
 |
5
Askiz 2022-06-05 19:55:01 +08:00 via Android
思路不错，请求 TXT 记录返回的却是 A 记录
|
 |
6
AlphaTauriHonda OP |
|
7
AlphaTauriHonda OP @Askiz 哈哈过奖了。之前发现请求了 TXT 记录却返回 A 记录的污染，真是觉得此地无银三百两。
|
 |
8
cloudsigma2022 2022-06-05 20:42:53 +08:00
|
 |
9
wwbfred 2022-06-05 22:08:29 +08:00
老办法了，只对路由黑洞有效。你还可以用它来测回国线路是不是专线，比如 Google 的 VPS 对 203.208.32.0/19 走的就是专线，没有污染。
|
 |
10
philippiela 2022-06-05 22:13:50 +08:00
都 2022 年了还在研究 ip 被墙？现在的墙都差不多形同虚设了，就算封都基本上只封端口
|
 |
11
ThirdFlame 2022-06-05 22:23:50 +08:00
测试了，OP 的思路很风骚。 有效
|
 |
12
Sekai 2022-06-05 22:37:11 +08:00
终于了解自己是怎样被狠狠地艹的了嘛（ bushi
|
 |
13
czwstc 2022-06-05 22:57:17 +08:00 1
有效，谢谢 OP
|
 |
14
dream7758522 2022-06-05 23:02:03 +08:00 via Android
如果大量伪造请求,用国际出口网关的 ip 测试.会不会有一天墙直接把国际出口给干趴了
|
|
15
AlphaTauriHonda OP @cloudsigma2022 结果是 Server 208.67.222.222 timed out 而不是伪造的 A 记录不正常。
是只有被测试的 IP 被墙或者 53 端口 UDP 或 TCP 被墙封锁才会有的结果。 根据有没有出现预期中的污染就可以判断墙的屏蔽名单上有没有这个 IP 或者 IP+端口。 |
 |
16
lns103 2022-06-05 23:52:23 +08:00 via Android
@dream7758522 墙是好像有 IP 白名单的，联合国 IP ，部分国外大学 IP ，都是白名单，VPN 不会被掐，并且据说连 sni 阻断都触发不了
|
|
17
AlphaTauriHonda OP @wwbfred 我给出的例子中只有第二个是被路由黑洞的。198.35.26.96 是维基媒体基金会的。
第一个 IP 是 ACK 被丢弃了。104.254.96.227 曾经是 IT7 Networks 的。再给一个同类屏蔽的。103.234.220.205 ，是 HKBNES 的，搭建 TOR exit node 被墙了。 你 traceroute 就可以找到区别。搭建代理和 exit node 被墙 IP 的模式不是路由黑洞。路由黑洞级屏蔽连省级都出不了的。Traceroute 会发现上海电信 4812 连 4134 都没到就被屏蔽了。只有维基媒体基金会这类的才会这样屏蔽。 专线就太多了，详见我在 https://v2ex.com/t/836788#reply48 里的留言。用这个方法可以测试一个 IP 公网是否过墙。 |
|
18
wwbfred 2022-06-06 00:03:18 +08:00 1
@AlphaTauriHonda 好吧，我用词不能准确，只对 IP 地址有效。不过这的确是老办法了，我都用了好多年了。
|
|
19
wwbfred 2022-06-06 00:05:25 +08:00
@lns103 有测试过么？国外好多大学都是上了 CDN 的，而且很多 CDN 的 IP 都是通用的，也就是你强制解析到它的 IP 上直接白名单？
|
|
20
AlphaTauriHonda OP @dream7758522 是用外国 IP 吗？要“干趴”一定要收发双方在墙的两边。比如外国 IP NAMESERVER 写墙内 IP ，大量发送会触发污染的请求可以让墙的负载变高。或者墙内 IP NAMESERVER 写墙外 IP ，构造同样的 DNS 请求。
顺带一提墙的 DNS 污染是观察到成功率最低的特性。会触发 RST 的审查成功率和可靠性要比 DNS 污染高得多，SNI 触发的 RST 成功率在 98%左右。DNS 污染的成功率远低于此，可以看出此特性是墙的性能短板，要“干趴”国际出口确实该利用 DNS 污染。 |
|
21
AlphaTauriHonda OP @wwbfred 大概从 IP 墙出来第一天就有了。用了多年，觉得可靠分享啊哈哈哈
|
|
22
wwbfred 2022-06-06 00:11:10 +08:00
@AlphaTauriHonda 早就有人分享过了，我也是从哪儿看来的，之前还有人用它找墙的位置。
|
|
23
AlphaTauriHonda OP @wwbfred 靠 RST 或者污染发来的延迟就可以判断大概位置。看下来只有北上广。
|
|
24
wwbfred 2022-06-06 00:21:47 +08:00
@AlphaTauriHonda 他们找的是哪一跳，就是路由节点上墙在哪两跳之间。
|
 |
25
xinhangsong5678 2022-06-06 00:22:52 +08:00 via Android
@lns103 我有一个机场是阿里云香港腾讯云香港的线路，节点很少被封(v2ray 列表更新订阅，结果是 ip 几乎没有变过)
|
|
26
AlphaTauriHonda OP @wwbfred 感觉挺难验证的。
|
 |
27
i3x 2022-06-06 05:18:14 +08:00 via Android
@lns103 这个我确定，而且范围很大。我有个朋友在美西某名校留学。。。有一次我想看的论坛只针对家庭 as 开放的网站。。。给他搞了个 gen8 micro g1610t 放他实验室。。。那么多年了我至今可用。。。就五六年前有两个月中美海缆故障连不上。。。现在这种网站我一直是从他那上。。。。。就像他用我的手机注册国内账号，互相交换。。。。
|
 |
28
yokisama 2022-06-06 16:50:48 +08:00
感谢思路=w=
属于是接力打力了（ |
|
30
AlphaTauriHonda OP @uncleroot 能搜到的文章 GitHub 项目都是十年前的了。时效性不行，不太可能还适用于目前的情况。
|
 |
31
serafin 2022-06-08 00:15:41 +08:00
|
 |
32
zhengxinhn 2022-06-09 13:45:06 +08:00
很棒，这样即使禁 ping ，不知道开放的端口也能检测 IP 是否被墙
|
Select Language