[转帖]鹏博士旗下家庭宽带被 ICMP 劫持，请使用鹏博士的 V2 们注意吧！
bclerdx · 2017-04-29 00:22:54 +08:00 · 6163 次点击这是一个创建于 2800 天前的主题，其中的信息可能已经有所发展或是发生改变。
转自： https://tieba.baidu.com/p/3115126085
宽带通劫持大法再升级，闻所未闻见所未见的 ICMP 劫持！
我真真心的给宽带通跪了= = 我在此之间是从来没有听说过还有这么一个玩儿法叫 ICMP 协议劫持的，后续问了机房的哥们才信了= =
大概两周前就感觉宽带通的 PING 出来的延迟和丢包率有点问题。就包括之前被上级廊坊联通禁 PINIG 的线路都能正常 PING 出来值，并且延迟还好的要命。
然后就开始陆续怀疑起来。
宽带通说;你们不是嫌我们丢包率高延迟高么？好！我把 ICMP 协议整个给你劫持掉。
劫持的思路是这样的，只要发现协议头为 ICMP 协议的，则将数据包指向一个经过专门优化的路由上，这个路由发往全国的延迟都很低，而且丢包率也很低。这样，就算你实际用起来卡的再厉害，无论你 PING 和 TRACE 你的延迟都是很低而且不会丢包的。他们就能说这是网站的问题，不是我们网的问题。。
发现的经过是自从开始怀疑这件事以后就联系了几个朋友帮忙从不同 BAS 测试，首先分别查看了对外的公网 IP，北京电信通 联通 天津电信 廊坊联通的都有，但是，分别 PING 了北京联通和上海电信的骨干路由器，延迟竟然出乎意料的一致，而且不同出口的 TTL 差距竟然只有个别的相差 1 其它的都一模一样。
后续通过 TRACE 发现了一个神秘的 IP，172.16.100.94，这个 IP 在不同 BAS 的不同出口上均出现在 202.99 的电信通的核心路由器出口后的吓一跳，相信这个私网 IP 就是 ICMP 劫持的关键，在电信通的核心出口上进行 ICMP 协议过滤，如果发现了此协议遍将数据引导到此 IP 上，到此之后所有 ICMP 协议的数据包都是走了这条专门经过优化的路径。
也就导致了你无论什么线路，什么时间测试延迟和丢包的好的不行。即便你实际用起来再卡！
另外，最近宽带通已经劫持掉了 SPEEDTEST 的北京师范大学节点。相信更多的节点在不远的将来也会遭此毒手。
在此，只奉劝宽带通一句！好自为之。！
(你现在应该做的应该是把经历放在线路和出口优化上，而不是想各种办法来劫持啊劫持！你就算 ICMP 劫持了，用起来该卡的不是还是卡？你这样做只是在自欺欺人，就算你工程师自己测试那都没法测试出真实路径和丢包率了。我就呵呵呵呵呵呵呵呵呵)
宽带通劫持大法再升级，闻所未闻见所未见的 ICMP 劫持！
我真真心的给宽带通跪了= = 我在此之间是从来没有听说过还有这么一个玩儿法叫 ICMP 协议劫持的，后续问了机房的哥们才信了= =
大概两周前就感觉宽带通的 PING 出来的延迟和丢包率有点问题。就包括之前被上级廊坊联通禁 PINIG 的线路都能正常 PING 出来值，并且延迟还好的要命。
然后就开始陆续怀疑起来。
宽带通说;你们不是嫌我们丢包率高延迟高么？好！我把 ICMP 协议整个给你劫持掉。
劫持的思路是这样的，只要发现协议头为 ICMP 协议的，则将数据包指向一个经过专门优化的路由上，这个路由发往全国的延迟都很低，而且丢包率也很低。这样，就算你实际用起来卡的再厉害，无论你 PING 和 TRACE 你的延迟都是很低而且不会丢包的。他们就能说这是网站的问题，不是我们网的问题。。
发现的经过是自从开始怀疑这件事以后就联系了几个朋友帮忙从不同 BAS 测试，首先分别查看了对外的公网 IP，北京电信通 联通 天津电信 廊坊联通的都有，但是，分别 PING 了北京联通和上海电信的骨干路由器，延迟竟然出乎意料的一致，而且不同出口的 TTL 差距竟然只有个别的相差 1 其它的都一模一样。
后续通过 TRACE 发现了一个神秘的 IP，172.16.100.94，这个 IP 在不同 BAS 的不同出口上均出现在 202.99 的电信通的核心路由器出口后的吓一跳，相信这个私网 IP 就是 ICMP 劫持的关键，在电信通的核心出口上进行 ICMP 协议过滤，如果发现了此协议遍将数据引导到此 IP 上，到此之后所有 ICMP 协议的数据包都是走了这条专门经过优化的路径。
也就导致了你无论什么线路，什么时间测试延迟和丢包的好的不行。即便你实际用起来再卡！
另外，最近宽带通已经劫持掉了 SPEEDTEST 的北京师范大学节点。相信更多的节点在不远的将来也会遭此毒手。
在此，只奉劝宽带通一句！好自为之。！
(你现在应该做的应该是把经历放在线路和出口优化上，而不是想各种办法来劫持啊劫持！你就算 ICMP 劫持了，用起来该卡的不是还是卡？你这样做只是在自欺欺人，就算你工程师自己测试那都没法测试出真实路径和丢包率了。我就呵呵呵呵呵呵呵呵呵)
 |
1
freshmanc 2017-04-29 17:28:42 +08:00 via Android
有趣…
|
 |
2
windscolorme 2017-04-29 23:31:12 +08:00  1
移动，快来学习下宽带通的优秀技术
|
 |
3
whileFalse 2017-04-30 06:55:31 +08:00 via iPhone
所以请求是真的传输到目标路由器上了么？还是说直接打到一个假服务器上。
如果是前者的话，可以研究走 icmp 的 vpn 了。 |
 |
4
yexm0 2017-04-30 19:19:55 +08:00 via iPhone
移动家是时候向鹏博士取取经了。
|
 |
5
adfsadfssfd 2017-04-30 21:35:39 +08:00
你又不脑残 为什么转百度贴吧的垃圾?
在 edge 做 PBR 成本那么高 给 ICMP 提升一下 QoS 倒是有可能 |
 |
6
bclerdx OP @adfsadfssfd 请你注意说胡方式！我仅仅是提醒大伙注意，做好心里准备。
|
 |
7
z99123 2017-05-01 11:20:34 +08:00
@yexm0 深圳长城宽带更加病狂。出口直接把 UDP 小包都丢弃了，直接连游戏一上去延迟都是 300-500.目测 ICMP 部分劫持
|
 |
8
rtxux 2017-05-01 11:41:00 +08:00
如果包真的发到了目标服务器，可以试试 VPN over ICMP 了
|
 |
11
mytsing520 2017-05-01 15:26:51 +08:00
14 年的帖子。。
你不知道移动有个业务叫域名强制解析么 |
 |
13
diguoemo 2017-05-02 12:46:00 +08:00
softether 的 icmpvpn 可以用
|
 |
14
miyuki 2017-05-02 16:21:49 +08:00 via Android
在挺多游戏 VPN 那见过这种原理的假 Ping
没想到宽带运营商这么与时俱进 |
 |
15
120 2017-05-02 17:05:09 +08:00
试试 tcp ping ？
|
|
16
bclerdx OP 怎么测试是假 ping ？
|
 |
17
zhengxiaowai 2017-05-03 10:26:48 +08:00
|
 |
18
NETBB 2017-05-03 13:21:24 +08:00 via iPhone
很久以前不就已经劫持了么？鹏博士花样多着呢，有 10000 种方法压缩成本。值得广大运营商研究借鉴，可以有效降低互联线路采购成本。
|
 |
20
snsd 2017-05-05 08:56:38 +08:00 via iPhone
@zhengxiaowai 有没有现成能用的 exe ？
|
|
21
zhengxiaowai 2017-05-05 10:29:05 +08:00 1
|
 |
22
chinawrj 2017-05-05 13:25:47 +08:00
国内就这么肆无忌惮的践踏别人的权利。
|
 |
23
onion83 2017-05-05 16:23:18 +08:00
|
|
24
bclerdx OP @zhengxiaowai 不错！收录了。
|
|
25
NETBB 2017-05-06 23:38:48 +08:00 via Android
@bclerdx 没说反。跟国外运营商互联的时候，直接采购人家 n 条廉价家宽，拼成高带宽的通道。效果棒棒的。长宽的很多出口都是 n*百兆家宽拼起来的
|
|
28
bclerdx OP @NETBB 难道三大 ISP 外网互联没有成本么？要是在压缩成本的话，你把网内资源弄的牛逼一些也行呀，但是事实并不是这样。
|
 |
29
EricInBj 2017-05-09 09:50:50 +08:00
单位以前接的大楼物业的鹏博士，妈的居然劫持 apk 做缓存，要命的是万年不更新。。。
|
 |
30
codehz 2017-05-09 10:18:04 +08:00
话说既然 ICMP 优化的这么好的话，是不是可以用 ICMP 代理呢？就是那种 ICMP Tunnel /斜眼笑
|
 |
32
QQ2171775959 2017-05-10 09:35:17 +08:00
确实是有这么一种技术，也有一些机房为了忽悠客户而这样子操作，不过用户都不是傻子，用了一段时间后，都会离开的，毕竟网站的访问速度摆在那里的。如果他们本身的网络就很快，很稳定，那么他们就不需要这样子操作的，一般这样子操作的都是些较差的线路。
|
|
33
bclerdx OP @QQ2171775959 详细说说细节，谢谢！
|
Select Language