如果遇到這種情況：
左側主機在防火牆限制的情況下，除了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穿透
流量重定向實現負載均衡