|
|
本帖最后由 taojson 于 2018-2-11 17:23 编辑
先说明：我所在地区目前没事，也就是说墙应该是在进行试点工作或逐渐部署。
事件如下：
我朋友是在另一个省，也是ss/ssr多年的老手。今天跟我说他的多个ss在早上突然不可用。但ip和端口都正常，通过其它协议都是可以直接访问的。多台服务器都是一样情况。
为确认是否为服务器被黑，把多台服务器都重装了，情况还是一样。
他将他的ss信息给我，我于本地连接使用，一切正常。我将我本地可使用的ss给他，他那出现一样的不可访问情况。
为确认是否为他所使用的网络（公司）本身有问题，于中午时间，通过手机流量，测试了移动、联通、电信的网络，全部出现一样的情况。
为确认是否为的电脑有问题，借用了多个手机、笔记本，在移动、联通、电信网络都进行了测试，全部一样。
我在他的电脑和服务器上抓包分析。
发现：在与ss服务端进行tcp握手确认的阶段，被reset.
为了确认是否真为tcp链接被reset，先后测试了近二十多个ss服务，测试了多个加密和混淆组合，包括自建的，网上分享的，还是两个收费的，都被reset.
联系与朋友同市但不同区的另一人，配合测试，全部不可使用。
联系与朋友同省但不同市的另一人，配合测试。全部都可使用。
----------------------------------------------------
上述描述重点：
1.服务器ip和端口，在国内是可正常访问的。
2.非ss协议，就算用同一个端口，都是可正常使用的
3.只要是ss/ssr协议(哪怕是第一次用)，立刻reset
=====================
补充：
ss的无流量特征，我也不怎么相信墙能在建议tcp连接时就reset.
所以我又重新试了几次，发现以下规律（但不是每次都重现）
1.新开的一台vps，手工安装的ssr,ssr源码为原版，第一次请求，连接建立成功了，但是立马就断
2.之后，ssr客户端不断的重试，与服务端的连接决大多数都被reset
3.偶尔服务端能接到请求数据，服务端日志会刷connect reset 或unsupported addrtype，刷哪种错不固定。
总的感觉是，墙能识别，识别后开始开扰tcp连接，开扰tcp连接的同时还修改数据
===================
说要抓包数据的，不是我舍不得，抓包数据我原封不动上传吧，我这的地址就暴露了，
我把我信息从包数据里移除吧，可能你们会觉得我数据造假。
===================
反正我这还正常，出事的朋友是江西人。
==================
各家自扫门前雪，晚上老子还吃鸡
===========================================================
2018-02-10恢复正常，应该是墙的一波测试完美结束
|
|
[复制链接]
发表于 2018-1-30 16:59:20