V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
notgod
V2EX  ›  问与答

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

  •  
  •   notgod · 2016-08-02 17:32:01 +08:00 · 4004 次点击
    这是一个创建于 2825 天前的主题,其中的信息可能已经有所发展或是发生改变。
    希望做个检测工具,部署国内节点作为检测用途
    让公众查询域名或 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 是网关随机的 不现实
    第 1 条附言  ·  2016-08-03 05:43:29 +08:00
    第一个版本
    只能测试域名 只能测试域名 只能测试域名 只能测试域名 只能测试域名

    返回 JSON

    正常 200
    有 head 和 data
    https://www.boip.net/hehe.php?url=www.baidu.com

    异常 和谐
    https://www.boip.net/hehe.php?url=www.google.com
    head 为空 且 status 为 ERROR 如果 msg 为 Connection reset by peer 90%的把握被螃蟹了
    {"head":"","data":{"status":"ERROR","msg":"Recv failure: Connection reset by peer"}}

    这个是调用国内缓存服务器 因为很多 IP 地址
    随机抽选一个 IP 来测试
    但是以国内网络的尿性 很难 100%准确的

    另外提下 缓存服务器这个不是一定要使用静态资源来测的
    因为域名被螃蟹的话 是直接 Reset 了
    23 条回复    2016-08-03 07:59:32 +08:00
    strwei
        1
    strwei  
       2016-08-02 17:42:00 +08:00   ❤️ 1
    notgod
        2
    notgod  
    OP
       2016-08-02 17:47:40 +08:00
    主要测试方法
    首先 我们访问百度
    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
        3
    Otho  
       2016-08-02 17:53:02 +08:00
    @strwei http://www.checkgfw.com/ 显示百度 都被墙了 -_-!
    notgod
        4
    notgod  
    OP
       2016-08-02 17:57:38 +08:00
    @strwei 我要讨论的是判断机制 不是要工具 你跑偏了

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

    这个问题感觉真心无解
    strwei
        5
    strwei  
       2016-08-02 17:59:54 +08:00
    @Otho 你确定你访问的是 http://baidu.com 而不是 https://www.baidu.com 或者 www.baidu.com
    strwei
        6
    strwei  
       2016-08-02 18:01:28 +08:00
    notgod
        7
    notgod  
    OP
       2016-08-02 18:02:05 +08:00
    @strwei 输入 baidu.com 显示被 Qiang 了 已验证
    Hanxv
        8
    Hanxv  
       2016-08-02 18:04:07 +08:00 via Android
    docker
    用户查询→新建容器→进行检测→返回结果→关闭容器,等待下一次查询
    SuperFashi
        9
    SuperFashi  
       2016-08-02 18:05:43 +08:00 via Android
    这个不是很简单的一件事吗,换句话说,控制变量呗。因为你只判断有没有被墙,而这里的变量只有一个,就是墙,所以你只要搞两台(理想 100%uptime 的)服务器,一台国内一台国外,同时访问看行不行不就好了。

    详细一点,对于 ip 来说,发 icmp 包。对于域名来说,解析就好了。判断:被墙 == !国内 & 国外
    Tink
        10
    Tink  
       2016-08-02 18:10:31 +08:00 via iPhone
    9l 的办法好
    notgod
        11
    notgod  
    OP
       2016-08-02 18:12:49 +08:00
    @Hanxv 这个不现实的

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

    就是我上面说的 查询 baidu.com 正常 查询 Google 异常
    这个时候如果查询国内的服务器 IP 正常
    如果查询任意国外 IP 都异常
    只是单纯的因为你之前访问了 Google 这个 IP 会在 N 时间段内 无法访问国外 IP
    Hanxv
        12
    Hanxv  
       2016-08-02 18:27:00 +08:00 via Android
    @notgod 构建速度没你想的那么慢
    jrhu05
        13
    jrhu05  
       2016-08-02 18:30:08 +08:00
    如果有一份不断维护更新的列表清单的话......_(:зゝ∠)_
    notgod
        14
    notgod  
    OP
       2016-08-02 18:43:15 +08:00
    @Hanxv 和快慢无关 不符合这种应用场景 只是一个单纯的测试
    你想象下 当 API 开放请求,一个 512M 内存的 VPS 同时处理几百上千的队列 并发请求 NN 个
    建几百上千个 docker? 根本不现实
    如果只是单一容器 更没必要的

    @jrhu05
    这个我的想法是检测的时候
    如果是非临时被 Qiang 的 就加入 Ban 列表 提供一个 API 生成给 PAC 那些东西调用
    有想过,这样数据量上来了,命中率就高
    SuperFashi
        15
    SuperFashi  
       2016-08-02 18:57:58 +08:00 via Android
    @notgod
    你说的那种情况存在吗,能给我个例子是一下吗?
    notgod
        16
    notgod  
    OP
       2016-08-02 19:00:56 +08:00
    @SuperFashi 见 2 楼的测试
    SuperFashi
        17
    SuperFashi  
       2016-08-02 19:09:11 +08:00 via Android
    @notgod
    你那测试不靠谱啊,首先我不能重现你的错误。其次那个 ip 目测是一个反代(还是国内的 ip ?),上面说了对于 ip 来说发 icmp 包,而不是请求资源。当然对于禁 icmp 的,我们还可以 port knocking 。
    notgod
        18
    notgod  
    OP
       2016-08-02 19:29:42 +08:00
    @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
        19
    ids  
       2016-08-02 19:35:20 +08:00 via Android
    @Otho qq 也墙了
    notgod
        20
    notgod  
    OP
       2016-08-02 19:36:49 +08:00
    @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 了
    SuperFashi
        21
    SuperFashi  
       2016-08-02 20:31:56 +08:00
    这样还怎么向别人询问问题啊,我用安卓回帖又不代表我用手机测试。

    首先说 ping :

    https://superfashi.b0.upaiyun.com/wp-content/uploads/2016/08/sp160802_200604.png

    我说过了,对于 ip 来说看 ping ,也就是说对于那个 ip 来说,没有被墙,可以正常访问,事实上确实如此,访问 ip 会被 301 到 Google ,然后挂掉 。但是从截图来看,只在北京可以 ping 通(?)。对于网站有着另外的处理方法,目前来看就是解析。

    再说你说的那个临时的问题:

    https://superfashi.b0.upaiyun.com/wp-content/uploads/2016/08/sp160802_201717.png

    https://superfashi.b0.upaiyun.com/wp-content/uploads/2016/08/sp160802_201748.png

    我的结果截然不同,先是连接,然后默认一分钟返回 timeout ,接着访问正常资源,没有问题。

    难道我们的墙不是一个版本的?
    notgod
        22
    notgod  
    OP
       2016-08-03 01:32:26 +08:00
    @SuperFashi

    拿 Qiang 外的机器测试
    你可能拿国内的机器 你自己的机器到反向代理的 120 国内机器 因为是国内到国内 这段握手根本不过 Qiang
    所以返回 504 超时的错误
    非常明显的就已经不对了

    Ping 的问题
    北京电信和联通一致 非 301 Redirect 到 www.google.com 导致的 rest
    Google 是 ASN 下所有 IP 被污染了 非漏网 IP 导致的可 Ping
    因为 Qiang 并不会判断你是北京联通访问的这个 IP 还是南京电信访问的这个 IP
    一视同仁的污染目标 IP
    SuperFashi
        23
    SuperFashi  
       2016-08-03 07:59:32 +08:00 via Android
    @notgod
    504 超时我猜是因为反代机器也是国内机器,连接不上从而导致的超时。

    ping 不行就拿 tcpping 呗,不太清楚墙什么机制,为啥北京能够 ping 通。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2820 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 10:07 · PVG 18:07 · LAX 03:07 · JFK 06:07
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.