基于某些众所周知的原因，在天朝上网非常需要勇气和技术。 今天在跟某人聊天时了解到Chrome竟然没办法使用proxy进行DNS查询<1>， 导致DNS查询结果持续被污染。 虽然用proxychains能把一切流量塞进代理里面， 不过用proxychains启动浏览器的话，各种自动代理插件就失效了，所以这是个得不偿失的方法。 青蛙晚上的时候突然想到iptables是不是可以把DNS查询流量转发进ssh tunnel呢？ 上网google一番之后，发现这是可行的，而且其实用不到iptables，只要nc就够了。

要用SSH Tunnel转发DNS流量，最大的问题是要把DNS协议使用的UDP协议转换为TCP协议，然后在proxy端还要转换回来。 所以目前青蛙想到的方案有一个很大的缺陷，就是如果ssh服务器上不提供nc命令的话，下面的操作是没法完成的。

首先，用SSH连接ssh服务器，这里青蛙打了一套组合拳，ssh -L + -D组合，分别负责DNS流量和普通数据流量：

ssh -D1080 -L5353:127.0.0.1:5353 user@ssh-server

-L 参数的目的是在本地机器上打开一个5353端口，发送到这个端口的数据都会被转发到ssh服务器上的5353端口上。

然后，在ssh服务器上执行：

server$ mkfifo /tmp/fifo
server …

今天的Tip是关于虚拟化的。

问题的起因是青蛙当时使用的VirtualBox的网络配置很不方便， guset系统启动之后不能改网络连接类型不说（后来的版本做了改进，但是用着还是不够舒服）， NAT模式下还不能直接跟Host系统通信。

于是青蛙痛下决心，学习了一下Linux tap和br设备的用法， 写了一个小脚本来搞定虚拟机的网络问题。

这个脚本同样也可以用于KVM的虚拟机。

这个脚本会根据配置文件建立一系列的tap设备， 然后桥街到几个br设备上去，然后在br上设置好IP， 如果需要NAT功能则配置iptables规则。

脚本文件在这里：

http://gfrog.googlecode.com/hg/script/vnet.sh

配置文件如下：

USER=gfrog           #指定建立tap设备时所用的用户名
VNET_NUM=2         #需要建立的虚拟网络数
EXITIF=eth0           #SNAT的出口接口

#以下是每个虚拟网络的配置
[vnet1]
VETH_NUM=4          #虚拟网络中包含的tap设备数
VNET_IP=11.11.1.1/24  #虚拟网络br设备上配置的ip地址
DONAT=no                  #是否需要做nat

[vnet2 …

今天继续关于ssh的话题。

青蛙本来想把今天这个主题放在昨天一起讲的，但是这两个Tip的关联不大，最后决定还是分开说。

在平时上网过程中，有可能遇到某个服务器（我们叫他S）无法访问的问题。

但是如果另外一台主机（叫做P）可以访问到S，并且我们还有P上面的ssh权限，那就可以把P当作跳板，直接访问到S。

假设要访问S上面的http（80）服务，那就执行如下命令：

ssh user@P的地址 -L 8080:S的地址:80

这个命令会在本地打开8080端口，将连接转发到S的80端口上，这样就达到了从本地直接访问S的目的。

事实上ssh的-L参数主要是用来建立一条客户端到服务器之间的安全隧道，以便安全的传输数据。