有什么有效的姿势 来判断域名或 IP 被 Qiang? [集思广益]

[notgod]

希望做个检测工具,部署国内节点作为检测用途
让公众查询域名或 IP 是不是被 Qiang

因为这玩意这么多年实在太不透明了,然后提供个 API,做监控服务
这样一些极端情况下,调用监控可以更换 DNS 解析的 IP,保证服务在国内的高可用性

这个工具理想状态下 是这样工作的
用户输入域名 点击检测

国外检测节点 = CURL 直接读取 URL 一般都返回 200=>500 的正常状态码
国内检测节点 = CURL 不现实 因为被 Rest 的链接 CURL 是直接返回错误的
无法做准确的判断,到底是被 Rest 来还是对方服务器不通还是其他原因
而且在一个时间段,这个 IP 在请求所有国外 IP 都是 Rest (N 分钟后才会恢复)

那么问题来了 是不是有一个有效的方式 在网络底层做数据包的校队或者验证?

比如 国内检测节点 查询域名

1. DNS 层检测 判断被污染或者挟持 返回结果
这个我的想法是 同时 dig any 结果缓存 然后分别 dig 国内服务器 和国外服务器 进行比对结果
因为考虑到有些使用 CDN 和多 IP, 所以看看国外和国内的返回 IP 是不是都存在于缓存的 ANY 结果内
如果存在 代表 OK,如果不存在 代表异常,如果返回的 IP 是 DNS 区域 IP 代表被挟持了

2. DNS 层正常 检测发送的请求 数据包校队 返回结果
这个是个问题,底层的问题 底层的问题 底层的问题 老衲真不知道啊......

等等 组成一个逻辑 ......

后续可以增加一些邮件订阅 提交后订阅
在一个时间周期 重新检查一次 来判断是临时被 Qiang 还是永久被 Qiang
还可以检测是域名被墙还是 IP 被 Qiang
等等

如果有什么 github 的项目 相关的
或者有什么想法 都可以谈谈

讨论收集 WALL 的 IP 然后屏蔽的 就免开尊口了
旁路设备发送的数据包 IP 是网关随机的 不现实

[strwei]

http://www.checkgfw.com/
https://github.com/greatfire

[notgod]

主要测试方法
首先 我们访问百度
curl -I -v 120.52.72.23/ss.bdimg.com/static/superman/img/logo_top_ca79a146.png
* About to connect() to 120.52.72.23 port 80 (#0)
* Trying 120.52.72.23...
* Connected to 120.52.72.23 (120.52.72.23) port 80 (#0)
> HEAD /ss.bdimg.com/static/superman/img/logo_top_ca79a146.png HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 120.52.72.23
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx
Server: nginx
< Date: Tue, 02 Aug 2016 09:36:20 GMT
Date: Tue, 02 Aug 2016 09:36:20 GMT
< Content-Type: image/png
Content-Type: image/png
< Content-Length: 1636
Content-Length: 1636
< Connection: keep-alive
Connection: keep-alive
< ETag: "57512c91-664"
ETag: "57512c91-664"
< Last-Modified: Fri, 03 Jun 2016 07:06:57 GMT
Last-Modified: Fri, 03 Jun 2016 07:06:57 GMT
< Expires: Wed, 17 Aug 2016 06:10:30 GMT
Expires: Wed, 17 Aug 2016 06:10:30 GMT
< Age: 334744
Age: 334744
< Cache-Control: max-age=2592000
Cache-Control: max-age=2592000
< Ohc-Response-Time: 1 1 0 0 0 3
Ohc-Response-Time: 1 1 0 0 0 3
< via: ltgj23 HIT
via: ltgj23 HIT
< Accept-Ranges: bytes
Accept-Ranges: bytes
<
* Connection #0 to host 120.52.72.23 left intact
返回 OK

在访问谷歌
curl -I -v 120.52.72.23/www.google.com/images/nav_logo242.png
* About to connect() to 120.52.72.23 port 80 (#0)
* Trying 120.52.72.23...
* Connected to 120.52.72.23 (120.52.72.23) port 80 (#0)
> HEAD /www.google.com/images/nav_logo242.png HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 120.52.72.23
> Accept: */*
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer
阵亡了


在随便访问一个 正常情况下可访问的资源
curl -I -v 120.52.72.23/www.webhostingtalk.com/images/inet-wht/logo.png
* About to connect() to 120.52.72.23 port 80 (#0)
* Trying 120.52.72.23...
* Connection refused
* Failed connect to 120.52.72.23:80; Connection refused
* Closing connection 0
curl: (7) Failed connect to 120.52.72.23:80; Connection refused
阵亡了
其实这个未访问谷歌之前 是可以访问的
你可以在浏览器 直接打开
http://120.52.72.23/www.webhostingtalk.com/images/inet-wht/logo.png
显示的是图片
只是因为当前 IP 访问了 Google 导致被关联
这种情况下 多次被关联也会临时被 Qiang 的 我 100%确认并且测试过


这样多用户测试的话 就不准确了
使用一堆国内节点轮换测试 也不现实 成本在那里

[Otho]

@strwei http://www.checkgfw.com/ 显示百度 都被墙了 -_-!

[notgod]

@strwei 我要讨论的是判断机制 不是要工具 你跑偏了

@Otho 就是我更新的那个问题连带问题 先 Google 在正常资源 也是异常的
实际上等会或者换个 IP 请求 是正常的

这个问题感觉真心无解

[strwei]

@Otho 你确定你访问的是 http://baidu.com 而不是 https://www.baidu.com 或者 www.baidu.com

[strwei]

[notgod]

@strwei 输入 baidu.com 显示被 Qiang 了 已验证

[Hanxv]

docker
用户查询→新建容器→进行检测→返回结果→关闭容器，等待下一次查询

[SuperFashi]

这个不是很简单的一件事吗，换句话说，控制变量呗。因为你只判断有没有被墙，而这里的变量只有一个，就是墙，所以你只要搞两台（理想 100%uptime 的）服务器，一台国内一台国外，同时访问看行不行不就好了。

详细一点，对于 ip 来说，发 icmp 包。对于域名来说，解析就好了。判断：被墙 == !国内 & 国外

[Tink]

9l 的办法好

[notgod]

@Hanxv 这个不现实的

@SuperFashi
你说的这个是 http://www.websitepulse.com/help/testtools.china-test.html 的测试模式
但是它这个 不知道是如何解决连带的问题

就是我上面说的 查询 baidu.com 正常 查询 Google 异常
这个时候如果查询国内的服务器 IP 正常
如果查询任意国外 IP 都异常
只是单纯的因为你之前访问了 Google 这个 IP 会在 N 时间段内 无法访问国外 IP

[Hanxv]

@notgod 构建速度没你想的那么慢

[jrhu05]

如果有一份不断维护更新的列表清单的话......_(:зゝ∠)_

[notgod]

@Hanxv 和快慢无关 不符合这种应用场景 只是一个单纯的测试
你想象下 当 API 开放请求,一个 512M 内存的 VPS 同时处理几百上千的队列 并发请求 NN 个
建几百上千个 docker? 根本不现实
如果只是单一容器 更没必要的

@jrhu05
这个我的想法是检测的时候
如果是非临时被 Qiang 的 就加入 Ban 列表 提供一个 API 生成给 PAC 那些东西调用
有想过,这样数据量上来了,命中率就高

[SuperFashi]

@notgod
你说的那种情况存在吗，能给我个例子是一下吗？

[notgod]

@SuperFashi 见 2 楼的测试

[SuperFashi]

@notgod
你那测试不靠谱啊，首先我不能重现你的错误。其次那个 ip 目测是一个反代（还是国内的 ip ？），上面说了对于 ip 来说发 icmp 包，而不是请求资源。当然对于禁 icmp 的，我们还可以 port knocking 。

[notgod]

@SuperFashi 你拿安卓手机测不了什么的

这个问题 100%有 100%可重现
IP 是个反向代理 IP 国内 IP 这个不冲突 实际节点城市


看图更直观些
首先测百度
https://i.niupic.com/images/2016/08/02/bHjpZ6.jpg
OK 返回 200

在测试谷歌 和 一个没被 Qiang 的资源 (这个条件 = 未使用代理 尝试浏览器访问 是可以访问的)
https://i.niupic.com/images/2016/08/02/KpRwJV.jpg
结果异常

实际上等几分钟 在访问
https://i.niupic.com/images/2016/08/02/IQ7XW1.jpg
变 200 了

这个就是访问 Google 引起的连带问题

[ids]

@Otho qq 也墙了

[notgod]

@SuperFashi
另外你说使用 Ping 获得 icmp 这个更不靠谱了
比如 Google 的 IP 173.194.73.113
北京[电信] 173.194.73.113 美国 加利福尼亚州圣克拉拉县山景市谷歌公司 331ms 27

Ping 是可以获得返回的

但是访问
正确的应该返回 Google 的网站
实际上返回 Connection reset by peer

这个 IP 污染的和 ICMP 的包 一点关系都没有 根本捕获不到任何特征
不是说 Ping timeout 就代表被 Qiang 了