最近在研究 gfw。。又不小心看到这个网站这么多 geek 就来提问了＝。＝一些关于 block 的原理的问题

DNS 参考资料

› dnslib for Python

This topic created in 4331 days ago, the information mentioned may be changed or developed.

1. 看了一些资料之后动手dig Google.com，发现114DNS和8888的UDP返回的ip都是173.194.127.x，TCP请求8888也是一样的回复，这是说114DNS这种国内的DNS也可以正确解析google了？
2. 用浏览器访问173.194.127.196，进度条不动，也没有错误提示，最后说服务器未响应。加上https后也一样。这是什么原理？IP Block？不用重置连接的话是怎么Block这些ip的？
3. ping 173.194.127.196，第一次回复是53ms，美国的ip怎么能这么快，看起来像是gfw的回复吧？第二次ping开始就Timeout了，这又是什么原理＝＝

114DNS

block

原理

33 replies • 2014-09-02 01:29:08 +08:00

ywywywx

Jul 31, 2014

哦对了，V2EX的DNS延迟比114DNS大，又有挺多人用，优势在哪里？

kurtrossel

Jul 31, 2014

回答一楼：放心，且没有广告

izoabr

Jul 31, 2014

我大概理解是这样的：
做tcp包拦截有几种方式。
1、给发reset过去，双向要求断开
2、drop掉，就向进了黑洞
3、reject，这样的话丢掉之后，会给发送一个丢弃通知

我估计你是遇到了drop，还不给你丢弃通知。

不知道对不对哦。

xinglp

Jul 31, 2014

ping 延迟这个确实很奇怪，正常应该是200毫秒左右

tobyxdd

Jul 31, 2014

google主站的dns从来没污染过屏蔽都是按ip+80和443端口

bombless

Jul 31, 2014

gfw的东西在机房，tcp的内容完全可以劫持掉的，http换个404什么的不稀奇。
isp给网页插广告也是这个原理。

tobyxdd

Jul 31, 2014

而且ip段在美国不代表那ip就是美国的吧 google应该是广播到了其他国家服务器

ywywywx

Jul 31, 2014

@izoabr
@tobyxdd
@xinglp 刚刚想起来有一种方式是用路由表把请求发到其他地方，就用Traceroute看了一下173.194.127.196的记录，最后竟然发现请求到了美国的google服务器。。。但是网页还是打不开，ping150ms，难道只会阻断TCP连接？
试了一下Facebook，Traceroute从电信的上海骨干网之后就没消息了，Twitter的话被从北京转到韩国，但是google的话就不会这样。Google的特殊对待是有原因的吗？

tobyxdd

Jul 31, 2014

ping走的是icmp不受影响 gfw只屏了google端口80和443的tcp

sdcg1994

Jul 31, 2014

线路劣化而已，让出于多数的屁民以为是谷歌自己服务器的问题

ywywywx

Jul 31, 2014

@tobyxdd ping不受影响？ping的时候75%的丢包率看起来就不正常。

ywywywx

Jul 31, 2014

@sdcg1994 感觉这样的人完全没有威胁。。

sohoer

Jul 31, 2014

先看看这个
http://v2ex.com/t/125255

ywywywx

Jul 31, 2014

@sohoer 好长，慢慢看

zhxhwyzh14

Jul 31, 2014

看维基百科

BOOM

Jul 31, 2014 via iPad

感觉google的ip太多，封不过来吧。
不像fb什么的就那几个ip

sasber

Jul 31, 2014

@BOOM
这次谷歌自己的IP段几乎都被屏蔽了，只有部分google globle cache还能正常访问。谷歌的IP地址很容易找到的，找谷歌的AS号，然后就全部出来了，然后GFW上面就可以直接封IP段的80，443端口了（可能是间歇性屏蔽）

wy315700

Jul 31, 2014

1:google用了any cast技术，从大陆连过去应该是到香港的节点
2:GFW对TCP连接进行了干扰，干扰你三次握手

ywywywx

Jul 31, 2014 via iPad

@wy315700 干扰三次握手应该会显示连接被重置，我以为是用路由表误导，但是Tracerouter确实发现有到谷歌的服务器，这才觉得很奇怪。

ywywywx

Jul 31, 2014 via iPad

@BOOM 用iPad上V2EX好蛋疼，回复的时候点回复按钮没反应，还要长按点打开。。这是Bug吧？

BOOM

Jul 31, 2014

@ywywywx 还好。习惯就好。。

wy315700

Jul 31, 2014

@ywywywx 是直接丢包。这样就不会显示重置，而是会显示超时。Tracerouter用的是icmp协议，GFW应该只干扰TCP和UDP协议，所以会出现各种ping的通但是连不上的情况

lazyphp

Aug 1, 2014

@tobyxdd 明显没有不是纯粹IP+端口屏蔽的。
早期google抽风时，都是hk为主。可以跳转到 jp等其他国家域名。后来这些都屏蔽了，可以说明GFW当时的策略是检测域名是否包含google。
后面IP盛行，最后才一一封闭IP的

21grams

Aug 1, 2014

114dns是无污染的

tobyxdd

Aug 1, 2014

@lazyphp 我指的是没有封死整个ip所有端口只阻挡80和443国内访问不了但google服务器用随机端口发起连接抓取国内网站不受影响以往gfw屏蔽的其他网站都是所有端口双向挡死

ywywywx

Aug 1, 2014 via iPhone

@tobyxdd 原来是这样，只封端口。看起来Dropbox也是和Google一样只封端口，再加一个DNS污染，但是我正常解析ip后用客户端上传的时候速度只有300kB/s，既然没干扰这么慢也是正常的？

tobyxdd

Aug 1, 2014

@ywywywx 正常可能走的国际出口很慢不行就挂个快点的vpn

jerryjhou

Aug 2, 2014

@ywywywx Dropbox连端口也没封，其实封端口是很高的待遇，Facebook都享受不了，Twitter是完全封死IP。
BTW,173.194.127是香港的，国内ISP一部分直接路由到香港，但大部分都到美国(Google可能针对国内做了点优化，路由到美国后直接发送到当地服务器上，不再路由到香港，这样也能降低它自己跨太平洋传输成本，但是如果使用欧洲IP段就没这待遇，照样给你发送到欧洲去)

ywywywx

Aug 2, 2014

@jerryjhou Dropbox原来只封了部分ip。108.160.165.62这个dropbox.com的ip打不开，204.236.220.7这样用来传文件的ip可以连接。
173.194.127.196是香港的吗，怎么看？我只知道用ip的网站来看＝。＝

gamexg

Aug 2, 2014

我自己搭的ss，联通线路几秒钟就把端口封了，抓包显示并不是reset，而是直接drop。换个端口网页打开半个就接着封掉了。电信线路就没问题。

wwbfred

Aug 4, 2014

1.对于google.com并没有做dns污染,无论是哪里的dns解析都会是正确的.114dns属于缓存服务器,想要查询google的ip地址第一次或者缓存期过了都要去访问ns1.google.com(还有ns2 ns3 ns4),这一过程会经过gfw. twitter/facebook等同理.所以墙有污染的,国内的缓存服务器一定有污染.
2.墙对于google 74.125与173.194段的ip没有进行完全的封锁,它对于大部分ip放行了icmp数据包,封锁/劣化了tcp数据包(或是80/443端口的数据包),这就导致能ping通,ping不丢包,但完全无法访问或是访问非常不流畅.这可以通过tcping命令来观察到(系统不自带).
3.美国的ip服务器不一定在美国,你所说的173.194.127.196应该是在香港.ping的数据包的确是由google返回的,不是伪造的.再次ping出现timeout就是当前时间段对icmp数据包也进行了封锁/劣化,你刚刚ping的时候正好放行了.

ywywywx

Aug 5, 2014

@wwbfred 嗯看出来了，第一次ping的反应都很快，应该是香港。这样的方式我们能做到吗，不通过隧道换IP？

webfury

Sep 2, 2014

FUCK GFW!

最近在研究 gfw。。又不小心看到这个网站这么多 geek 就来提问了 ＝。＝ 一些关于 block 的原理的问题

最近在研究 gfw。。又不小心看到这个网站这么多 geek 就来提问了＝。＝一些关于 block 的原理的问题