浅谈智能路由器未来的战略意义

2014-10-17

智能路由器

大学时候因为所学专业接触路由器较多的缘故,我那时候(08、09年)就有做智能路由器的想法,不过我这人很懒,一直没有付诸实践,所以就一直停留在想法阶段了。果不其然,这几年随着互联网向各个领域延伸,智能路由器终究还是火起来了,也算是对我的判断的证明吧。

有人说做智能路由器为的是采集用户数据,或者通过大数据为用户做推荐。我觉得这种想法很危险。试想,如果有哪个公司胆敢用路由器来监控用户行为、采集用户数据,这无疑是一种赤裸裸的盗窃行为。在个人隐私越来越被重视的今天,如果做路由器为的是采集用户数据,或者有这种倾向,无疑是玩火自焚。 阅读全文 »

使VSFTPD Ftp Server同时支持IPv4和IPv6网络

2014-10-10

VSFTPD Ftp Server

虽然VSFTPD Ftp Server本身支持IPv6网络,而且在配置文件(/etc/vsftpd/vsftpd.conf)中就有一个“#listen_ipv6=YES”选项,但是默认情况下IPv6服务是不生效的。在实际应用中,如果我们想让VSFTPD同时支持IPv4和IPv6,似乎只要把“#listen_ipv6=YES”取消注释、然后重启VSFTPD服务就OK了。不过我在实际操作中发现,如果只是简单地取消掉“listen_ipv6=YES”的注释,重启服务时会提示VSFTPD在IPv4和IPv6网络下同时运行产生冲突,错误信息如下:

500 OOPS: run two copies of vsftpd for IPv4 and IPv6

这可咋办,难道VSFTPD不能同时在IPv4和IPv6网络下运行吗?我经过查资料后发现,根本不是这样,VSFTPD可以同时运行在IPv4和IPv6网络下,不过需要使用两个配置文件,将“listen=YES”和“listen_ipv6=YES”分别放在两个配置文件中,一个负责监听IPv4,一个负责监听IPv6,这样就不会冲突了。

经过测试,IPv4和IPv6确实都可以正常连接。

阅读全文 »

使用Apache2搭建Google加密反向代理

2014-09-01

Google数字证书被干扰

几个月前Google就被从IPv4网络上彻底干掉了,但是IPv6网络的用户并没有受到什么影响,或许是用户数量少的缘故吧。不过从今天早晨开始,IPv6下加密访问Google也开始变得不正常了——每次用Chrome打开“https://www.google.com.hk/”,都会提示“您的连接不是私密连接,攻击者可能会试图从www.google.com.hk窃取您的信息”。从目前已知的信息来看,应该是Google的SSL证书在传输过程中被人为干扰了。

Google的不能正常使用使我的工作受到了严重影响,所以我只能想办法解决喽。恰好我前段时间入手了一枚RamNode的VPS,所以我便用这枚VPS搭建一个反向代理。从效果来看,确实还不错,而且比用VPN要方便得多。 阅读全文 »

SoftEther VPN——Linux下搭建VPN可以如此简单

2014-08-09

SoftEther VPN logo

我前段时间入手了一枚RamNode的VPS。因为RamNode恰好同时支持IPv4和IPv6网络,而我所在的教育网存在IPv4网络按流量收费、而IPv6网络不限速不计费的情况,所以我便盘算着用这台VPS做跳板机,这样以后就不用为流量发愁了。为了达到这个目的,我尝试了多种方案——GoAgent、PPTP、L2TP、OpenVPN、ShadowSocks,以及本文推荐的SoftEther VPN

GoAgent和ShadowSocks的主要问题是不能支持全局代理,而且不知是不是ShadowSocks协议貌似被认证的缘故,我配置了数次均未成功;PPTP服务器的问题主要有两个:一个是容易被干扰,另一个是不支持IPv6访问,这样我就没法用它在IPv6网络下做跳板机了,排除;L2TP服务器的安全性不错,也支持IPv6,但是配置起来着实让人头大,所以只能作为备选方案;OpenVPN,我在配置完成后IPv4连接OK,IPv6未能配通。我在试尽各种利器却一无所获之时,偶然从老外网站上发现了这款名气不大、试用完后却惊呼神器的VPN软件——SoftEther VPN,真可谓是踏破铁鞋无觅处,得来全不费工夫。 阅读全文 »

适用于阿里云ACE的WordPress Rewrite规则

2014-08-06

阿里云(Aliyun)

随着阿里云ACE(阿里云引擎)功能的日臻完善,我最近在考虑将博客迁移到ACE平台上。因为我的博客中的大部分URL都使用了Rewrite,可是偏偏网络上并没有适用于阿里云ACE的,所以我只能自己写了。

在经历了繁复的拼凑过程之后,终于给搞出来了:

rewrite:
- url: ^$
script: /index.php last
- url: ^/(?!wp-)([\w/_-]+(\.html$)?)$
script: /index.php/$1 last

阅读全文 »

jQuery获取JSON时IE浏览器提示Undefined错误的解决办法

2014-06-24

ajax_jquery_json

我昨天在做一个Java Web项目的时候,发现了一个非常奇怪的问题:某个页面在用jQuery的ajax()方法向服务器端请求JSON数据时,Chrome、FireFox甚至连IE 11都可以拿到数据,可是IE 8却偏偏不行。我用alert()函数显示了一下本应携带JSON数据的变量,我发现该变量的状态竟然是“undefined”。也就是说,是jQuery获取或解析JSON数据时失败了。更奇怪的是,在这个Web系统中恰好还有几个页面也使用了jQuery的ajax()方法,但它们都可以与服务器端正常交互。

为了解决这个“undefined”问题,我用Google搜遍了中英文网站,可惜即使是StackOverflow这样权威的技术网站,也没能解释出其中的原因或者给出一个让人十分信服的解决方案。网友给出的最常见的解决方案是引用一个叫做json2.js的文件,使用其中的JSON.parse( )方法来代替JavaScript的eval( )方法。可是我的项目中明明有一些页面是可以正常工作的,为什么我非得用这个函数来替换呢?出现问题的根源又是什么?所以我不得不自己寻找其中的原因了。

因为出现问题的代码在Chrome等浏览器中是可以正常运行的,所以我们首先可以排除语法错误。那会不会是输出的JSON字符串前后含有空格呢?我用trim( )函数处理掉了输出字符串前后可能存在的空格,可惜问题依然没有解决。排除掉了前两种可能产生错误的情况,那么问题只会在一个地方产生——JSON输出的文件头(Header)部分! 阅读全文 »

.CO域名快被这帮搞IT的玩坏了……

2014-06-14

.CO域名

鉴于近来国内访问Google的服务受阻,greatfire.org于前天推出了其基于亚马逊AWS的Google搜索镜像网站,地址是sinaapp.co。该网站随后因多家海外媒体的报道和众多微博大V的转发而一炮走红。我们不用想都知道,其结果必然是接受入侵检测装置的认证。不过比较狗血的是,新浪SAE旗下的sinaapp.com域名因为域名中也含有“sinaapp.co”字样,所以随同singaapp.co一同受到了“特殊照顾”——当从海外访问sinaapp.com域下的应用时,都会提示“连接被重置”。

虽然“认证”随着新浪方面的积极奔走而被取消,但这种使用知名网站类似域名的方法显然被玩坏了——greatfire.org的所有者随后注册了baidustatic.co(百度)、alicdn.co(阿里)、gtimg.co(腾讯)等国内知名网站的相似域名并指向其镜像网站。在V2EX上,有网友建议再注册几个诸如inhuanet.co、anqiu.com之类的域名;甚至有人YY,要是注册个chinamil.co域名然后被BLOCK掉,PLA会是什么反应。在我写这篇文章时,我发现chinamil.co确实已经指向过去了,不知后面会如何…… 阅读全文 »

阿里推阿里云解析,提供免费DNS解析服务

2014-04-06

阿里云解析

众所周知,BAT是国内互联网三巨头,他们几乎涉及了互联网的所有领域,在DNS解析领域亦是如此:腾讯拥有全国最大的DNS解析服务商DNSPod,百度依托提供Web安全服务的加速乐间接为用户提供DNS服务;而阿里,虽然控制着全国最大的域名注册商万网,但是其DNS服务长期以来只对在万网注册的域名开放。如今这种局面已经有所改观。在大约半个月前,万网的域名解析系统正式升级为阿里云解析,并宣布向非万网域名永久免费开放。如此一来,BAT三家就悉数加入到了DNS服务的战场中。 阅读全文 »

利用Chrome Data Compression作桌面版Chrome代理的扩展

2014-02-22

数月前,Google针对手机版Chrome浏览器推出了数据压缩(Data Compression)功能,其利用Google强大的服务器集群做代理服务器进行数据中转。

当用户打开代理功能后,所有的Web请求都将经过谷歌的服务器进行处理,而服务器会使用PageSpeed工具对相应内容进行压缩和优化,而Chrome与服务器之间采用谷歌的SPDY协议,从而对内容进行进一步的优化。经过这两次优化,传输的数据量就大大地减少了。 阅读全文 »

盘点近年来比较严重的DNS安全事件

2014-01-22

DNS安全

2014年1月21日下午,继上午腾讯旗下的QQ邮箱、QQ秀等业务因网络系统故障一度无法使用后,大陆境内发生了迄今为止最严重的DNS故障,大陆境内所有的通用顶级域(.com/.net/.org等)遭到DNS劫持/污染,所有域名被指向到一个位于美国的IP地址(65.49.2.178)。为了提高大家对DNS服务重要性的认识,下面由我带领大家盘点下近年来比较严重的DNS安全事件。 阅读全文 »

第 1 页,共 17 页12345...10...最旧 »