1
laiyingdong 2015-09-18 17:47:36 +08:00
ping 25ms 是不是到香港的 Google 服务器?
|
2
ScotGu 2015-09-18 18:04:41 +08:00
|
3
Strikeactor 2015-09-18 18:10:46 +08:00
traceroute 看看呢
|
4
yexm0 2015-09-18 18:24:16 +08:00
用延迟来判断毫无用处.
|
5
fengxiang 2015-09-18 18:29:41 +08:00
低于 220 不用看了,肯定假的。
|
6
halczy 2015-09-18 18:31:26 +08:00 via iPhone
Windows 下 tracert 8.8.8.8
Linux / OSX mtr 8.8.8.8 移动正常应该走 HKIX ,电信 163 网正常是 202.97.x.x 后和 Google 台湾直连。 |
7
halczy 2015-09-18 18:40:48 +08:00
|
10
xiaoc19 OP @halczy
@Strikeactor traceroute to 8.8.8.8 (8.8.8.8 ), 64 hops max, 72 byte packets 1 内网 2.273 ms 1.418 ms 1.588 ms 2 内网 1.560 ms 1.503 ms 1.308 ms 3 172.*** (172.***) 49.570 ms 84.148 ms 108.177 ms 4 120.196.14.217 (120.196.14.217 ) 11.917 ms 7.365 ms 7.313 ms 5 120.196.244.29 (120.196.244.29 ) 15.243 ms 16.530 ms 14.711 ms 6 211.136.208.25 (211.136.208.25 ) 19.400 ms 19.693 ms 19.681 ms 7 211.139.134.178 (211.139.134.178 ) 20.352 ms 20.007 ms 20.108 ms 8 183.235.225.206 (183.235.225.206 ) 21.886 ms 120.198.204.18 (120.198.204.18 ) 23.612 ms 21.909 ms 9 211.136.193.142 (211.136.193.142 ) 18.939 ms 120.198.206.130 (120.198.206.130 ) 22.942 ms 21.651 ms 10 183.235.224.242 (183.235.224.242 ) 21.243 ms 20.942 ms 26.260 ms 11 google-public-dns-a.google.com (8.8.8.8 ) 20.204 ms 22.196 ms 20.566 ms |
16
yicun 2015-09-18 19:48:56 +08:00
@xiaoc19 thank you
tracert 8.8.8.8 1 * <1 毫秒 <1 毫秒 192.168.0.1 2 1 ms 7 ms 1 ms 183.55.140.1 3 2 ms 1 ms 1 ms 119.146.39.93 4 9 ms 11 ms 11 ms 119.146.36.233 5 12 ms 11 ms 11 ms 119.146.125.93 6 * * * 请求超时。 7 11 ms 12 ms 10 ms 202.97.60.50 8 17 ms 17 ms 15 ms 202.97.61.118 9 * * 14 ms 202.97.62.214 10 18 ms * * 209.85.241.58 11 15 ms * * 216.239.40.13 12 * * 39 ms 209.85.253.89 13 44 ms * 45 ms 209.85.243.23 14 * * * 请求超时。 15 44 ms * * google-public-dns-a.google.com [8.8.8.8] 16 * * * 请求超时。 17 * * 143 ms google-public-dns-a.google.com [8.8.8.8] 跟踪完成。 tracert 8.8.4.4 1 17 ms <1 毫秒 <1 毫秒 192.168.0.1 2 2 ms 2 ms 1 ms 183.55.140.1 3 2 ms 2 ms 1 ms 119.146.39.93 4 8 ms 7 ms 7 ms 119.146.126.149 5 10 ms 7 ms 7 ms 119.146.125.38 6 14 ms 14 ms 10 ms 202.97.33.202 7 * * * 请求超时。 8 14 ms 15 ms 14 ms 202.97.61.26 9 10 ms 10 ms 10 ms 202.97.122.70 10 13 ms 12 ms 15 ms 216.239.42.193 11 11 ms 12 ms 12 ms 72.14.232.175 12 12 ms 12 ms 12 ms google-public-dns-b.google.com [8.8.4.4] |
19
fengxing 2015-09-18 20:56:23 +08:00
|
20
pmpio 2015-09-18 21:24:14 +08:00
各省移动网络不太一样的,我们湖南的貌似是直接在 NAT 服务器上将所有 UDP 53 端口的查询重定向到了移动自己的 DNS ,最明显的效果,使用 dig +trace 时,直接就给你返回最终结果,不是一层一层的返回的。所以,这样子的话,你无论设置哪个 ip 作为 dns 服务器都一样的效果,比如你搞成 1.1.1.1 ,尽管互联网上这个 ip 上可能并无 dns 服务,你查询时也会得到正确结果~!这就传说中最牛 B 的 dns 劫持。
我以前在公司内网的网关上用 iptables + bind 试过了的。 |
21
pmpio 2015-09-18 21:26:22 +08:00
正在 Ping 8.8.8.8 具有 32 字节的数据:
来自 8.8.8.8 的回复: 字节=32 时间=7ms TTL=55 来自 8.8.8.8 的回复: 字节=32 时间=8ms TTL=55 来自 8.8.8.8 的回复: 字节=32 时间=7ms TTL=55 来自 8.8.8.8 的回复: 字节=32 时间=7ms TTL=55 8.8.8.8 的 Ping 统计信息: 数据包: 已发送 = 4 ,已接收 = 4 ,丢失 = 0 (0% 丢失), 往返行程的估计时间(以毫秒为单位): 最短 = 7ms ,最长 = 8ms ,平均 = 7ms 我这貌似更快,还经过了 5 重 NAT 才出去呢,我家里两次 NAT ,路由器和光猫,运营商那儿还有三次! |
22
pmpio 2015-09-18 21:29:57 +08:00
通过最多 30 个跃点跟踪到 8.8.8.8 的路由
1 <1 毫秒 <1 毫秒 <1 毫秒 192.168.X.1 2 1 ms <1 毫秒 <1 毫秒 192.168.Y.1 3 108 ms 37 ms 12 ms 172.17.3.214 4 7 ms 4 ms 5 ms 172.17.3.213 5 * * * 请求超时。 6 5 ms 4 ms 5 ms 111.8.27.181 7 8 ms 9 ms 8 ms 211.142.209.157 8 11 ms 11 ms 10 ms 111.8.18.218 9 8 ms 7 ms 8 ms 8.8.8.8 跟踪完成。 看看湖南移动有多变态!!!直接自己弄个假的 8.8.8.8 ! |
23
yicun 2015-09-18 21:44:19 +08:00
|
24
gdtv 2015-09-18 21:48:25 +08:00
怎么解决这种劫持呢?
|
25
gdtv 2015-09-18 23:22:12 +08:00
@gdtv 我自问自答吧,最简单的解决方法是在 OpenWrt 里设置 DNS 转发为 /#/208.67.222.222#5353
|
27
youling 2015-09-19 01:23:20 +08:00
@fengxiang 不知道 google 的 DNS 是云 DNS ?自动判断最近的 google DNS 服务器,因此在中国也能达到 50 以下的延迟,并且 0 丢包。
http://www.infoq.com/cn/news/2015/05/gcp-network-data |
28
vpslover 2015-09-19 01:27:37 +08:00 via iPhone
我这里 8.8.8.8 延迟 2-3ms 不用说肯定假的
|
29
wheat 2015-09-19 10:09:05 +08:00
8.8.8.8 的 dns 是被污染,不是被劫持, dns 默认为 udp ,无连接,所以 dns 请求发出后, gfw 跟 8.8.8.8 都会返回结果给你,但是系统以收到的第一个返回作为结果, gfw 抢先于 8.8.8.8 答复 dns 请求,造成 dns 污染,
详情可以用 tcpdump 查看 dns 请求即可 sudo tcpdump -i en0 -S -X -n -vv 'udp and (src 8.8.8.8 or dst 8.8.8.8 )' 在另外一个窗口 dig twitter.com @8.8.8.8 以下为 tcpdump 结果 # 发送请求 tcpdump: listening on en0, link-type EN10MB (Ethernet ), capture size 65535 bytes 10:01:04.714855 IP (tos 0x0, ttl 64, id 21027, offset 0, flags [none], proto UDP (17 ), length 57 ) 10.0.0.110.59488 > 8.8.8.8.53: [udp sum ok] 42946+ A? twitter.com. (29 ) 0x0000: 4500 0039 5223 0000 4011 0e14 0a00 006e E..9R#[email protected] 0x0010: 0808 0808 e860 0035 0025 8638 a7c2 0100 .....`.5.%.8.... 0x0020: 0001 0000 0000 0000 0774 7769 7474 6572 .........twitter 0x0030: 0363 6f6d 0000 0100 01 .com..... # gfw 冒充 8.8.8.8 返回错误的 dns 结果 10:01:04.758214 IP (tos 0x0, ttl 55, id 28944, offset 0, flags [none], proto UDP (17 ), length 84 ) 8.8.8.8.53 > 10.0.0.110.59488: [udp sum ok] 42946 q: A? twitter.com. 1/0/0 twitter.com. A 159.106.121.75 (56 ) 0x0000: 4500 0054 7110 0000 3711 f80b 0808 0808 E..Tq...7....... 0x0010: 0a00 006e 0035 e860 0040 4d25 a7c2 8180 ...n.5.`.@M%.... 0x0020: 0001 0001 0000 0000 0774 7769 7474 6572 .........twitter 0x0030: 0363 6f6d 0000 0100 0107 7477 6974 7465 .com......twitte 0x0040: 7203 636f 6d00 0001 0001 0000 0ad4 0004 r.com........... 0x0050: 9f6a 794b .jyK 10:01:04.758553 IP (tos 0x0, ttl 117, id 59329, offset 0, flags [none], proto UDP (17 ), length 73 ) 8.8.8.8.53 > 10.0.0.110.59488: [udp sum ok] 42946 q: A? twitter.com. 1/0/0 twitter.com. A 203.98.7.65 (45 ) 0x0000: 4500 0049 e7c1 0000 7511 4365 0808 0808 E..I....u.Ce.... 0x0010: 0a00 006e 0035 e860 0035 d8fc a7c2 8180 ...n.5.`.5...... 0x0020: 0001 0001 0000 0000 0774 7769 7474 6572 .........twitter 0x0030: 0363 6f6d 0000 0100 01c0 0c00 0100 0100 .com............ 0x0040: 0007 7600 04cb 6207 41 ..v...b.A # 真正的 8.8.8.8 返回点结果 10:01:04.791550 IP (tos 0x0, ttl 44, id 37748, offset 0, flags [none], proto UDP (17 ), length 89 ) 8.8.8.8.53 > 10.0.0.110.59488: [udp sum ok] 42946 q: A? twitter.com. 2/0/0 twitter.com. A 104.244.42.129, twitter.com. A 104.244.42.193 (61 ) 0x0000: 4500 0059 9374 0000 2c11 e0a2 0808 0808 E..Y.t..,....... 0x0010: 0a00 006e 0035 e860 0045 5ece a7c2 8180 ...n.5.`.E^..... 0x0020: 0001 0002 0000 0000 0774 7769 7474 6572 .........twitter 0x0030: 0363 6f6d 0000 0100 01c0 0c00 0100 0100 .com............ 0x0040: 0000 2b00 0468 f42a 81c0 0c00 0100 0100 ..+..h.*........ 0x0050: 0000 2b00 0468 f42a c1 ..+..h.*. |
33
pmpio 2015-09-19 11:47:16 +08:00
@gdtv 我这也可以连。
traceroute to 208.67.222.222 (208.67.222.222 ), 30 hops max, 38 byte packets 1 192.168.*.1 0.676 ms 0.602 ms 0.728 ms 2 172.17.3.214 5.132 ms 5.058 ms 6.024 ms 3 172.17.3.213 7.357 ms 5.250 ms 3.633 ms 4 * * * 5 111.8.27.181 5.234 ms 3.494 ms 3.814 ms 6 211.142.209.157 6.760 ms 7.587 ms 7.655 ms 7 221.176.20.233 8.362 ms 9.357 ms 8.813 ms 8 221.176.17.182 30.584 ms 40.369 ms 30.839 ms 9 * 221.176.22.110 33.016 ms 31.257 ms 10 221.176.24.146 26.571 ms 23.536 ms 221.176.24.142 33.711 ms 11 211.136.1.105 23.698 ms 29.544 ms 30.478 ms 12 223.118.2.169 84.412 ms 73.491 ms 223.118.2.161 30.759 ms 13 123.255.90.189 37.130 ms 33.845 ms 40.325 ms 14 208.67.222.222 30.112 ms 31.458 ms 29.624 ms 不过感觉也是假的!上一跳 123.255.90.189 是香港的 ip ,不可能就直接到美国的这个 dns 服务器了,在美国国内至少得有几跳才可能。。。。 要知道移动在香港也有分部的。 |
34
wclebb 2015-09-19 15:41:51 +08:00
其实 DNS 貌似的确会被劫持
我也无法解释,不管用 DNS 是什么,打开的时候是运营商我就「惊喜」。 |
35
lanlanlan 2015-09-19 16:17:00 +08:00
记得前些天 移动劫持了 223.5.5.5/32 223.6.6.6/32 8888 8844 到他们自己的递归 DNS 服务器上 数小时后恢复正常
|
36
wql 2015-09-20 20:18:34 +08:00
其实由于是 Anycast ,运营商只要建立一台服务器,规定他是 8.8.8.8 ,然后发布恶意的 BGP 黑路由。这样就能劫持了。
看来不 FQ 不行。 |
37
zro 2015-10-02 17:11:30 +08:00
|
39
zro 2015-10-02 19:54:26 +08:00
@gdtv 貌似是个很高级的代理,具体原理不太懂,访问的 IP 不是 12306 自己的,是本省移动的, PING 时 13ms 左右(用来抢票是不是会很快?),路由器 Traceroute 到 kyfw.12306.cn 只有 6 跳,没有一跳是出省的。。。
|
40
lanlanlan 2015-10-05 11:45:33 +08:00 1
@zro 12306 用的网宿 CDN 没有出省可能是节点跟你同省了.6 跳也差不多了 我这儿是 7 跳从 ZJ 到南京的网宿节点
6 19 ms 112.25.56.242 [AS56046] 中国 江苏 南京 7 149 ms 112.25.56.58 [AS56046] 中国 江苏 南京 8 18 ms wangsu.CDN.promote.auth-dns.local [112.25.35.79] [AS56046] 中国 江苏 南京 |
41
xrjr2015 2015-10-23 13:58:43 +08:00
本人这里经过长期多次的监测, 8.8.4.4 好很多,速度也很快 30ms+,估计是香港的服务器!
|