Open GoogleCodeExporter opened 9 years ago
滿有意思的想法,聽起來是基於graceMode模式來增加智能的判��
�最新被污染的域名,進而進行一些腳本的處理是嗎?
graceMode已經可以解決CDN問題,透過dnsmasq的static
config也可以解決部分常用域名的DNS污染問題,您希望透過新��
�腳本來做到怎樣的功能呢?
Original comment by pahud...@gmail.com
on 13 Feb 2012 at 8:08
以下摘自graceMode 的介绍
----------------------------------------------
使用本地DNS(ISP提供的DNS或local DNS),
讓DNS查詢可以非常快速穩定,同時具有CDN加速的優勢,然而��
�於有劫持風險的域名例如twitter, youtube,
facebook等則強迫使用Google DNS,
這樣一來如果VPN不穩導致DNS解析不穩,頂多也只是影響twitter,
youtube,
facebook等有劫持風險的網站,其他網站完全不用擔心解析問題
。(注:事實上本文最後的dnsmasq_options設置方式完全可以避免t
witter facebook等劫持風險)
----------------------------------------------
实际上GFW的域名污染列表是一直变化的,去年我用autoproxy的��
�候就遇到敏感时期封锁一些常用网站(例如华尔街日报),�
��后再解封的例子。特别是像我这种经常通过Google搜索到国外
网站、论坛上搜索资料的人,事前不可能知道我将访问哪些��
�名,也不可能知道哪些域名被污染。如果每次遇到域名被污�
��都要手动添加并刷新本地DNS缓存太累了,所以才弄了个这个
办法。
这个目的就是为了通过手中有限的被污染域名列表来避免任��
�域名被污染。
对比下graceMode和该方法的区别:
graceMode:只要访问的域名不在graceMode的域名列表中就会导致��
�页打不开,需要手动上路由器修改
该方法:除非POSIONEDDOMAIN里所有的域名都解封或者GFW改变其行
为使得返回的IP完全随机,才会导致需要用户手动干预。个人
认为当POSIONEDDOMAIN里所有的域名都解封的时候,墙也该倒了,
也用不到翻墙了。
Original comment by hack...@aim.com
on 13 Feb 2012 at 8:46
了解,這個討論蠻有意思的。
進一步再問問:
1.
你在國外網站上網的時候,打不開一個網站,你如何知道這��
�一個DNS污染的情況?
2. 如果確定是DNS污染的話,是否你需要手動加入 NONEXISTDOMAIN
variables裡面重新執行一次你的腳本,執行了腳本之後如果是��
�個已知的污染IP則封鎖國內DNS對這個IP的解析,而讓2nd DNS(via
VPN的國外DNS)來進行正確的解析,長久下來就可以累積自己的
POSIONEDDOMAIN 是嗎?
Original comment by pahud...@gmail.com
on 13 Feb 2012 at 8:56
還有一個我擔心的問題, /etc/resolv.conf裡面設置兩台nameservers,
一般來說都是先讓第一台解析,如果沒有回應才讓第二台解��
�,但如果ISP
DNS回應慢了的情況,或是其他無法預期的網路狀況造成1st
DNS來不及解析,fall-back給2nd DNS了(或者OS直接選了2nd
DNS來解析),這樣很可能國內網站的CDN架構也會亂套了。上海�
��信的user連到北京網通去,而用戶一直沒發現。
這個情況也是有可能的,我在一般公司環境內網有兩台DNS,
但有時候總是會跑到第二台DNS進行解析。
Original comment by pahud...@gmail.com
on 13 Feb 2012 at 9:03
對了,這段是怎麼做到的?
2
如果查的是被污染的域名,数据包会被丢弃,DNS客户端会使��
�位于国外的副DNS查询,GFW依然会返回错误IP,但是还是会被��
�弃,紧接着正确的IP就会返回,可以避免DNS污染
如果2nd DNS在國外,也不走VPN, 2nd DNS被污染的返回結果被DROP,
為什麼接著正確的IP就會返回呢?
Original comment by pahud...@gmail.com
on 13 Feb 2012 at 9:19
这样设置了以后应该不会再遇到DNS污染了。因为GFW返回的伪��
�包是有特征的(即返回的IP是固定的那几个),通过识别该��
�征来丢弃GFW伪造的数据包。
NONEXISTDOMAIN
那段其实是为了防止ISP提供的DNS对于不存在的域名会返回他��
�己IP,如果用dnsmasq的话可以用bogus-nxdomain来解决,就不需要��
�这段代码了。
POSIONEDDOMAIN
是不积攒的,只是为了通过POSIONEDDOMAIN来识别GFW伪造的数据包
的特征。
一般来说ISP的DNS返回速度要比国外的DNS快很多啊,如果真慢��
�,确实会造成CDN错乱,不过这种情况应该并不多见,实在不�
��可以多设置几个ISP的DNS在前面(当然,这样的话第一次查询
被污染域名等的时间就更长了)。对了,dnsmasq需要加 -o 选项
-o, --strict-order
By default, dnsmasq will send queries to any of the upstream servers it knows
about and tries to favour servers that are known to be up. Setting this flag
forces dnsmasq to try each query with each server strictly in the order they
appear in /etc/resolv.conf
目前GFW是在旁路监听的,并没有像防火墙一样串连到主干网��
�所以GFW无法丢弃数据包,只能产生干扰数据包,包括TCP的RST�
��是一样的,如果客户端和服务器都忽略就能无视GFW继续通讯��
�.
不信的话你可以拿抓包工具看下,用8.8.8.8查询www.twitter.com是否
最终正确的IP会返回
Original comment by hack...@aim.com
on 13 Feb 2012 at 10:18
了解,我看懂你的設計了,非常不錯!!
不知道DDWRT的iptables是否也支持 -m string --algo bm --hex-string ,
如果有的話我找時間來玩看看。
Original comment by pahud...@gmail.com
on 13 Feb 2012 at 10:25
剛剛仔細玩了一下,你這個方法真的非常不錯,可惜DDWRT的ipt
ables不支持這些module, OpenWRT很適合做這樣的運用。
這樣的確是最好的方法,學習了!
Original comment by pahud...@gmail.com
on 13 Feb 2012 at 2:10
不支持string模块吗?
抱歉我手头没有DD-WRT路由器,不过翻了下DD-WRT的代码,发现��
�面有这个模块的代码的。
http://svn.dd-wrt.com:8000/browser/src/linux/brcm/linux-2.6.23/net/netfilter/xt_
string.c
不知道是不是默认没有带这个模块?
不过这个脚本的耗时我还是不太满意,刚我又看了下dig命令��
�用法,发现可以用批量查询,试了下速度提升也没有多少提�
��。估计只有写成程序才能做到异步发起大量DNS查询请求再等
待回应了。
Original comment by hack...@aim.com
on 13 Feb 2012 at 5:18
lz我是小白
想问问 这个代码可以加入到番茄固件吗?
能不能搞个教材.
那真是服务大众了.
先谢谢了.
虽然看不大懂,但是判断机制是很棒的,更加智能化~
Original comment by linjimmyiphone@gmail.com
on 1 Apr 2012 at 3:09
现在手头只有openwrt的路由器。
不过上面的脚本用到的有些模块估计番茄固件不会默认自带��
�(基于固件大小考虑),你可能需要重新编译固件(如果可�
��的话)才能把脚本移植到番茄上
Original comment by hack...@aim.com
on 12 Apr 2012 at 8:22
tomato 固件可以用 u32 模块。
iptables -I INPUT -p udp -m udp --sport 53 -m u32 --u32
"0&0x0F000000=0x05000000 &&
22&0xFFFF@16=0x5d2e0859,0xcb620741,0x0807c62d,0x4e10310f,0x2e52ae44,0xf3b9bb27,0
xf3b9bb1e,0x9f6a794b,0x253d369e,0x9f1803ad" -j DROP
iptables -I INPUT -p udp -m udp --sport 53 -m u32 --u32
"0&0x0F000000=0x05000000 && 22&0xFFFF@16=0x3b1803ad" -j DROP
Original comment by lir...@gmail.com
on 14 Sep 2012 at 7:00
Original issue reported on code.google.com by
hack...@aim.com
on 13 Feb 2012 at 7:34