如果遇到这种情况：
左侧主机在防火墙限制的情况下，除了53端口以外的端口都关闭了，同时防火墙基于协议的过滤，限制了左侧主机的22端口的出站流量，而没有限制22端口的入栈流量。左侧的主机无法通过SSH主动连接到右侧服务器。现在这种情况就可以做远程端口转发。让右侧的主机发起SSH隧道建立请求。本地端口转发客户端的端口是侦听在本地的，远程端口转发的端口是侦听在远端SSH服务端的。这里写的有点多，希望读者能明白。
用其它方法也能区分本地端口转发和远程端口转发：
本地端口转发：
SSH客户端和应用客户端位于防火墙的同一端
SSH服务端和应用服务端位于防火墙的另一端
远程端口转发：
SSH客户端、应用客户端分别位于防火墙的两端
SSH服务端、应用服务端分别位于防火墙的两端
总结一句话就是，侦听的端口都是开在应用客户端的。
ok，现在开始部署实验环境：
（这个实验环境有木有像学校内网的实验环境，我们学校有的服务器只能通过内网访问，把它搞懂了，不用什么内网穿透，打穿内网，直接手动挖隧道访问内网服务器，咳咳，说着玩的，这里只是讲知识，请勿用于非法用途）
和之前一样，左侧是内网环境，右侧是外网环境
配置方面的我就不多说了，就是把机器放在防火墙外，防火墙内的，前两篇文章都有，这里主要以知识点的演示为主
现在主机放好了，服务也启动起来了
kali的IP是192.168.225.29、XP的IP是192.168.225.63、bodhi的IP是1.1.1.45、win_2003的IP是1.1.1.23
ok，现在用bodhi建立SSH隧道，尝试连接XP的远程桌面服务
我这里建立了两条隧道，一条是访问win_server2003的80端口的，另一条隧道是访问远程桌面的，把kali的7003和7004上的流量分别转发到1.1.1.23的80和3389上
通过下图，可以看到，侦听的端口并没有在本地
现在看一下kali服务器端的端口，可以看到7003和7004端口在kali上侦听了，kali是SSH的服务端，侦听的端口不在bodhi本地，而是kali远端，所以这个是远程端口转发。
这里侦听的IP是127.0.0.1，而不是0.0.0.0，说明远程端口的情况下，无法作为网关使用，因此，在现在的情况下，XP是不能通过kali去访问内网的。
我有个大胆的想法（我写文章，写着写着就想到了），就是用前面的流量重定向，让XP访问kali的流量，由kali把流量妆发到本地的监听端口上，可以实现内网访问。再次让kali成为网关。
修改kali的rinetd的配置文件
然后启动服务。
成功访问到内网80端口
成功访问到内网服务器的3389，看来我的想法还是可行的。
现在通过kali去访问内网：
先验证一下隧道的可用性
验证远程桌面的可用性
成功连接到内网服务器
还可以在win_server2003上用nc获取shell和前面的两篇文章差不多，这里就不多说了
这种连接方式虽然在bodhi和kali过程中的流量是加密的，但是如果在内网环境的服务器和SSH客户端是不同的主机的话，它们之间的流量是可以抓包嗅探的。这种情况下通信的流量并不是全程都安全的。
流量重定向
实验环境（我用Cisco Packet Tracer画了一个简图）：
因为防火墙规则，内网主机不能直接访问win_service2003，现在通过kali做流量转发
我把用到的机器的名字也写上了
上面的配置上不了网，我忘了配置dns服务器IP，dns服务器的IP设置为1.1.1.1，没啥难度，填上就好了，这个就不截图了，现在内网机器能通过防火墙上网了，我的机器也基本配置好了，简述一下现在的环境：
xp在内网IP是1.1.1.22，monowall防火墙，kali和win_servoce2003在外网
配置monowall：
禁用默认规则：
现在访问不了外网了
再添加新的规则，只开放53端口
配置完成
在kali上用rinetd侦听53端口，然后让xp去访问kali的53端口
配置rinetd的配置文件，让访问kali53端口的流量都转发到win_service2003上
再在win_service2003上转发到远程桌面端口，再用nc获取一个xp的shell
配置win_service2003：
开启远程桌面
在win_service2003上装上IIS服务
安装过程中需要插入光盘
为了能够区分，我在默认首页上添加了IP
配置kali：
在kali上安装rinetd
安装：apt-get install rinetd
配置：/etc/rinetd.conf
bindadd bindport connectadd connectport
运行：rinetd
端口也在侦听了
现在基本配置完成了。
因为做了防火墙限制，所以xp是不能访问外网的。刚才所做的配置是重定向web流量，如下：
现在已经绕过防火墙来到外网了
远程桌面重定向：
把kali中rinetd的配置文件中的win_service2003的80端口改成3389远程桌面端口
然后重启rinetd
在XP上远程连接
NC重定向获得shell
先向xp和win_service2003中传两个nc
要获取xp这台内网主机的shell
先在win_service2003上用nc侦听本地端口
修改kali的配置文件，把流量转发到4444端口
进程ID已经变了，现在修改之后，重新启动rinetd
在这种情况下，内网主机和kali建立了连接，看不到和win_service2003建立的连接，在一定程度上隐藏了获得shell的主机，有一定的隐蔽性，但是这个是明文传输，可以通过抓包嗅探到传输的内容
SSH之本地端口转发
简述一下这个隧道的特点：
ssh支持双向通信隧道
将其它TCP端口的通信通过SSH链接转发
可以突破防火墙，用于FQ
ssh本地端口转发：
使效果类似于rinetd
将一本地端口与远程服务器建立隧道
ssh隧道会对传输的流量进行加密
特征：
本机侦听端口，访问转发到远程主机指定端口
实验环境1（内网主机是Linux）：
防火墙还是限制，只允许53端口的流量通过
我现在用bodhi_linux作为客户端，kali作为服务器端，win_service2003作为外网服务器（这台主机的首页面我修改过，在原有的基础上添加了一个IP）
现在用SSH本地端口转发流量，使内网环境的机器通过严格受限的防火墙建立隧道，访问外网win_service2003，通过这个隧道可以传shell、远程桌面等流量。
先设置一下kali的ssh的配置文件，允许远程连接
需要修改如下设置
修改成：
监听端口给成53，允许root远程登陆，密码身份验证开启
然后启动服务
可以看到服务已经启动起来了
配置bodhi_linux：
配置静态IP，使它的流量通过防火墙
emm，我在修改静态IP的时候，出了点小问题，就是设置完静态IP后，ping不通防火墙网关，不知道读者会不会遇到，我的解决办法是，把网卡down了，再设置静态IP就ok了
win_service2003配置：
emm，就不配置了，就上面的环境
在实验过程中，我又遇到一些问题，我顺便说一下，在用ssh连接kali时，发现如下情况：
后来想起我没设置网关（汗）：
把网关设置为1.1.1.1就可以了
说明流量通了
然后，开始实验：
这个命令我就不在这里详细解释了，怕到时候篇幅过长
看到下图，说明通道已经建立成功了，并且获得一个shell
然后，流向本地的7001端口的流量就会通过ssh隧道通过防火墙，访问到kali，通过kali访问到win_service2003服务器
如果kali本机上有服务，可以尝试一下访问kali上的服务
先启动kali的apache服务
kali本地服务页面，已经成功启动起来了，下面给出连接命令的两种写法：
通过这命令就能连接kali的服务，访问apache首页，命令已经开始侦听了，同时把任务放在后台进行
访问一下页面验证隧道的可用性
这个隧道成功建立
通过这个隧道可以、通过受限的网络环境访问远程桌面、远程获取shell等，之前的文章介绍过，这里就不重复说了，不过还有一个网关功能值得一说。
现在，我在内网再添加一台XP主机，让XP通过bodhi_linux建立的SSH隧道访问win_service2003和kali的apache页面
两台主机都在内网：
现在重新建立的隧道，已经建立好了
-g参数就是把本机的隧道作为一个网关来使用，在同一网段的主机都可以通过它访问到外网的主机
现在用内网的另一台主机去访问它的7001端口，应该会直接访问到win_service2003的80端口
成功访问
SSH之远程端口转发
如果遇到这种情况：
左侧主机在防火墙限制的情况下，除了53端口以外的端口都关闭了，同时防火墙基于协议的过滤，限制了左侧主机的22端口的出站流量，而没有限制22端口的入栈流量。左侧的主机无法通过SSH主动连接到右侧服务器。现在这种情况就可以做远程端口转发。让右侧的主机发起SSH隧道建立请求。本地端口转发客户端的端口是侦听在本地的，远程端口转发的端口是侦听在远端SSH服务端的。这里写的有点多，希望读者能明白。
用其它方法也能区分本地端口转发和远程端口转发：
本地端口转发：
SSH客户端和应用客户端位于防火墙的同一端
SSH服务端和应用服务端位于防火墙的另一端
远程端口转发：
SSH客户端、应用客户端分别位于防火墙的两端
SSH服务端、应用服务端分别位于防火墙的两端
总结一句话就是，侦听的端口都是开在应用客户端的。
ok，现在开始部署实验环境：
（这个实验环境有木有像学校内网的实验环境，我们学校有的服务器只能通过内网访问，把它搞懂了，不用什么内网穿透，打穿内网，直接手动挖隧道访问内网服务器，咳咳，说着玩的，这里只是讲知识，请勿用于非法用途）
和之前一样，左侧是内网环境，右侧是外网环境
配置方面的我就不多说了，就是把机器放在防火墙外，防火墙内的，前两篇文章都有，这里主要以知识点的演示为主
现在主机放好了，服务也启动起来了
kali的IP是192.168.225.29、XP的IP是192.168.225.63、bodhi的IP是1.1.1.45、win_2003的IP是1.1.1.23
ok，现在用bodhi建立SSH隧道，尝试连接XP的远程桌面服务
我这里建立了两条隧道，一条是访问win_server2003的80端口的，另一条隧道是访问远程桌面的，把kali的7003和7004上的流量分别转发到1.1.1.23的80和3389上
通过下图，可以看到，侦听的端口并没有在本地
现在看一下kali服务器端的端口，可以看到7003和7004端口在kali上侦听了，kali是SSH的服务端，侦听的端口不在bodhi本地，而是kali远端，所以这个是远程端口转发。
这里侦听的IP是127.0.0.1，而不是0.0.0.0，说明远程端口的情况下，无法作为网关使用，因此，在现在的情况下，XP是不能通过kali去访问内网的。
我有个大胆的想法（我写文章，写着写着就想到了），就是用前面的流量重定向，让XP访问kali的流量，由kali把流量妆发到本地的监听端口上，可以实现内网访问。再次让kali成为网关。
修改kali的rinetd的配置文件
然后启动服务。
成功访问到内网80端口
成功访问到内网服务器的3389，看来我的想法还是可行的。
现在通过kali去访问内网：
先验证一下隧道的可用性
验证远程桌面的可用性
成功连接到内网服务器
还可以在win_server2003上用nc获取shell和前面的两篇文章差不多，这里就不多说了
这种连接方式虽然在bodhi和kali过程中的流量是加密的，但是如果在内网环境的服务器和SSH客户端是不同的主机的话，它们之间的流量是可以抓包嗅探的。这种情况下通信的流量并不是全程都安全的。
SSH之动态端口转发
在本地、远程端口转发都需要固定应用服务器IP、port，但是这种情况比较少，比较普遍的情况如下：
应用端口繁多，逐个转发效率低
某些应用不固定端口
某些网站不支持IP直接访问
使用非受信网络上网时保护流量不被嗅探
本地侦听socks4/5代理端口：
由SSH server决定如何转发
作为FQ代理使用
配置客户端代理（浏览器）
使用proxychains支持无代理客户端
实验环境，还是上篇文章的，懒得改了。如下：
防火墙左边是内网环境，右边是外网，防火墙的配置我懒得改了，还是只开放53端口吧
现在让外网启动SSH服务端
之前的几篇文章都是用bodhi作为SSH客户端，这次我换成XP作为客户端
用XP和kali建立SSH隧道
启动SSH服务，侦听本地的53端口，允许任意用户连接
用XP作为客户端，建立动态端口隧道
已经在侦听此端口了，侦听的IP是0.0.0.0，说明这个是可以作为网关来使用的。
现在用bodhi通过XP和kali建立的动态隧道来访问互联网。
由于它并没有指定最终要访问的主机的IP和端口，因此称为动态端口转发，可以和我之前的文章进行对比。就能发现区别
因为这个版本的linux系统浏览器比较简陋，没有代理选项，所以我就用wget来验证网络的访问情况。看到上图，访问不了外网。现在使用XP搭建的SSH隧道试试，配置bodhi的代理链
说明隧道建立成功了
在XP本机验证隧道的可用性
现在使用搭建的SSH隧道
ok，成功访问到外网。说明隧道是可用的。
X协议转发
远程登陆Linux GUI运行图形化界面工具，这个有很多远程桌面的工具可以使用，包含但不限于下面的工具：
VNC
X Windows
但是如果出现防火墙限制访问时，这些工具多多少少会收到些影响，此时就可以用下列的方法：
基于SSH的X转发，这里，给了一个命令，其实就是ssh的-X参数。它的作用是，在远程连接时，可以运行远端服务器的图形化工具，把窗口开在本地，程序还是运行在远端的。
ssh -X user@1.1.1.1 -p 53
我就简单设置一个演示环境：
先在kali上把ssh服务启动
然后，在bodhi上配置内网环境，再建立ssh连接
目前已经获得了一个kali的shell，这个linux上是没有wireshark的，先试试运行wireshark
成功在本地运行，现在检查运行情况
可以看到本地并没有wireshark进程，现在去看kali上
有一个wireshark进程，ok。到这儿，我感觉我已经说的很明白了。
DNS协议隧道
之前的演示环境都是过滤53以外的端口。53端口上通常跑的是TCP和UDP协议
在此基础上，如果禁止了TCP出站的访问流量，SSH隧道、端口转发全部失效，此时，是否可以使用基于UDP协议来建立隧道呢？平时在用户上网时，客户端对域名发出查询请求，请求的流量都是使用UDP53端口。TCP53端口主要是对同一个域里面不同的域名服务器之间进行数据库同步，区域传输。其实DNS的工作原理适合用于实现隧道
在中小型公司里，没有自己的DNS服务器，通常是用公网上的DNS服务器解析IP，所以，它们不需要DNS服务器之间的数据同步等。安全感意识比较强的管理员就会把TCP禁止。
DNS工作原理：
DNS隧道原理：注册受自己控制的DNS记录
ok，现在我修改防火墙把TCP的流量禁止了。只允许UDP协议通过防火墙。
现在再尝试之前的SSH连接
可以看到，现在连ssh都连接不上了（我等了几分钟，超时断开了），更不用说建立ssh隧道了
现在是不是没办法建立隧道了？
虽然现在没有了TCP，但是还有UDP。可以利用UDP来建立隧道。DNS主要用的是UDP协议。所以这个隧道被称为DNS协议隧道。
简单说一下隧道原理：
在DNS解析的时候，在本地DNS解析是递归查询，在除本地以外的DNS服务器上是迭代查询，从顶级域名开始一级一级往下查询的。下级域名是由上级域名委派的。直到最终查询到要访问的域名。此时，如果说我们控制了一台DNS服务器，控制的DNS服务器是这个DNS解析中的一环。我们就能操控它。因为服务器是自己控制的，那么，就可以指定主机查询返回的内容。通过它返回的结果就能实现DNS隧道的效果。
先利用迭代查询查找到受我控制的二级域名服务器，再利用客户端查询传递建立隧道的指令。在这个过程中用来建立隧道的请求数据包裹在DNS查询的请求中的。中间过程的DNS服务器都是合法的，控制的只是最后的二级域名服务器。我这里用到的工具是C/S架构的。
由于A记录的长度是比较小的，所以，在这个工具上，用的是TXT记录。这样，客户端可修改的部分就比较长，就有更多的空间去存放建立DNS隧道的指令。（TXT主要是用来反垃圾邮件的）传输的建立隧道的指令也是加密传输的，而且每隔一段时间就会发类似心跳包的数据包，用于确定连接是否还存在。
实验环境一：
在DNS隧道的情况下，在防火墙看来，只是内网主机和服务商的DNS服务器通信，是不知道kali的存在的。在限制源IP、端口和目标IP、端口的情况下，可以尝试建立DNS隧道。
防火墙上面配置好了的。
ok，现在配置win_server2003
把它作为DNS服务器，需要安装DNS服务、创建区域jiangxian.com、指派二级域lin.jiangxian.com、NS记录指向、kali配置转发器。
安装DNS服务：
服务器电脑做成静态IP，因为如果是动态获取的话，下次IP变了，客户端就找不到服务器了。
IP没变，只是改成静态的了
DNS服务器也可以设置成本机，因为这个就是DNS服务器。
然后创建区域：
选DNS，我这里创建了jiangxian.com域
通常来说，这个服务器通常来说不受我们控制，需要它来委派，把解析相关的功能委派给kali，现在，先在上面创建一条主机记录，再在上面新建委派。就是创建子域。
然后新建委派
创建转发器（本地解析不了的就用公网上的DNS服务器解析）：
win_server2003配置完成了，让bodhi的DNS指向win_server2003，修改/etc/resolv.conf
修改好之后，用nslookup尝试解析一下：
先设置查询的DNS记录类型，设置为NS记录查询
我这里给了两条设置语句，效果一样的
可以看到解析的域名，解析到了正确的IP，也可以解析百度。说明转发器工作正常
配置kali上的dns2tcp：
/etc/dns2tcp.conf
.dns2tcprcd //如果是在当前用户的主目录下写这个配置文件，之后运行程序时就不用指定配置文件了，不然，运行时，需要指定配置文件。
客户端的端口不限，从隧道过来的端口到kali的53端口，再由kali把流量往指定的目标和端口发送
先在本地启动一个ssh服务
dns2tcp工具分为dns2tcpd服务器端和dns2tcpc客户端（kali默认集成，如果在win环境，需要去官网下载对应的exe程序）
然后启动dns2tcp服务端程序，回车执行
然后客户端执行连接指令
回车之后，隧道并没有建立，当有流量通过的时候，连接才会建立
现在触发连接
如果，大家从第一篇开始照着我写的做的话，会发现连接不上，因为之前实验把ssh侦听的端口改成53了，所以流量流到kali的22端口，此时的22端口并没有程序在侦听，就没有处理流到22端口的流量。导致ssh连接不上。有两种改法，改ssh的配置文件，或者改dns2tcp的配置文件，改一下端口就好了。
ok，现在隧道建立起来了，这条隧道，指定的服务是ssh
可以再建立几条：
连接到我的路由器管理页面，转发的流量都是在dns2tcp服务端配置的
再建立一条
连接远程桌面
在kali上，我把这个流量转到win_server2003上，这个远程桌面控制的主机是win_server2003.
输入登陆密码就能登陆了
这里的隧道是没有网关功能的，所以XP是用不了这个上网的
此时有两种办法：
1、可以用之前的流量重定向的rinetd进行流量重定向。从而实现类似网关功能的效果。
这里就不演示了，有问题可以在文章下评论，或者在公众号中私聊。
2、在DNS隧道中嵌套SSH动态端口转发，建立SSH隧道时使用-g参数，把SSH隧道开启网关功能：
现在在XP上使用代理上网：
OK，现在已经成功访问到互联网了
实验环境二：
在有内网DNS服务器的情况下
ICMP隧道
HTTP/HTTPS隧道
PPTP VPN
L2TP/IPSec VPN
OpenVPN（SSL VPN）
GRE隧道
IP隧道
NAT穿透
流量重定向实现负载均衡