如何判断谷歌 DNS 是否被 ISP 劫持

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 ，路由器和光猫，运营商那儿还有三次！

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 ！

yicun

2015-09-18 21:44:19 +08:00

@miyuki @fengxing thank you
用了这个 WinMTR
https://github.com/oott123/WinMTR

gdtv

2015-09-18 21:48:25 +08:00

怎么解决这种劫持呢？

gdtv

2015-09-18 23:22:12 +08:00

@gdtv 我自问自答吧，最简单的解决方法是在 OpenWrt 里设置 DNS 转发为 /#/208.67.222.222#5353

zro

2015-09-18 23:58:34 +08:00

@gdtv 移动网络无法连接 208.67.222.222 ，肿么破？

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

vpslover

2015-09-19 01:27:37 +08:00

我这里 8.8.8.8 延迟 2-3ms 不用说肯定假的

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#..@......n
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.*.

xiaoc19

2015-09-19 10:13:37 +08:00

@wheat 我这种情况是 ISP 直接把 8.8.8.8 劫持为自己的 DNS

gdtv

2015-09-19 10:55:44 +08:00

@zro 我这里移动光纤可以连接 208.67.222.222#5353

xiaoc19

2015-09-19 11:00:56 +08:00

@gdtv 我这边也是， 20ms 左右，到香港服务器，不过感觉慢

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 服务器了，在美国国内至少得有几跳才可能。。。。

要知道移动在香港也有分部的。

wclebb

2015-09-19 15:41:51 +08:00

其实 DNS 貌似的确会被劫持
我也无法解释，不管用 DNS 是什么，打开的时候是运营商我就「惊喜」。

lanlanlan

2015-09-19 16:17:00 +08:00

记得前些天移动劫持了 223.5.5.5/32 223.6.6.6/32 8888 8844 到他们自己的递归 DNS 服务器上数小时后恢复正常

wql

2015-09-20 20:18:34 +08:00

其实由于是 Anycast ，运营商只要建立一台服务器，规定他是 8.8.8.8 ，然后发布恶意的 BGP 黑路由。这样就能劫持了。
看来不 FQ 不行。

zro

2015-10-02 17:11:30 +08:00

@gdtv 我这从网关出来，接下来的第二跳就开始* * *状态了，一直跳到 30 跳都是 * * *

@lanlanlan 移动现在还直接劫持 12306 到自己的镜像服务器，账号密码估计都能随时看

gdtv

2015-10-02 17:49:21 +08:00

@zro

"移动现在还直接劫持 12306 到自己的镜像服务器"? 吓死我了

zro

2015-10-02 19:54:26 +08:00

@gdtv 貌似是个很高级的代理，具体原理不太懂，访问的 IP 不是 12306 自己的，是本省移动的， PING 时 13ms 左右（用来抢票是不是会很快？），路由器 Traceroute 到 kyfw.12306.cn 只有 6 跳，没有一跳是出省的。。。

lanlanlan

2015-10-05 11:45:33 +08:00

@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]
中国江苏南京