匿名網絡通信(洋蔥路由&大蒜路由)原理

     1、（1）做網絡攻防，都希望能隱藏自己的真實ip地址，讓對方無法精准定位找到自己。最常見的方式就是代理，圖示如下：   

      

      client原本是直接訪問server的，但又不想暴露自己的真實ip，此時可以找個代理服務器轉發流量。站在server角度，訪問都來自proxy，不是client；站在client角度，所有的信息都來自proxy（目前很多FQ就是這么干的：買個海外的雲主機，裝個socket代理軟件轉發國內的流量）；

      這樣就能隱藏自己真實的IP了么？ too yong！ 正常情況下，server是有日志的，肯定記錄了proxy的ip地址（如果server在國內，運營商也有相應的記錄）；同時國內的運營商也有client的訪問記錄，兩邊的數據放專業的大數據實時數倉，一條select xxx from xxx as A join select xxx from xxx as B where A.descIP=B.SourceIP，分分鍾查出client的真實IP（千萬別小看了運營商和JC叔叔的IT設施，他們背后都有非常專業的IT團隊支持的！）這種情況下想要通過proxy來隱藏自己真實的IP是不行的！

     （2）既然一個proxy不行，那2個了？ 

        

       在海外（注意：一定要是海外的節點，國內的運營商是拿不到這些節點進出流量數據的）找兩個代理服務器，通過上述2層代理的方式訪問。

•       client->proxy1：國內運營商知道client給proxy1發數據了
•       proxy1->proxy2：由於兩個節點都在海外，正常情況下，國內運營商是不知道這層代理關系的
•       proxy2->server：正常情況下，server有日志記錄；如果server在國內，國內的運營商也有記錄

       最關鍵的是proxy1->proxy2了：國內運營商拿不到這兩個海外節點的數據，不好追查。 既然兩個proxy已經不好追查了，那么繼續增加proxy節點到3個了？—— tor就是這么干的！

      （3）tor從1995年問世，至今快30年了，各種資料google一下能查到一大把，我這里簡單介紹一下核心的原理，以下是tor官網的截圖：Alice要訪問Jane，並不是直接連接Jane，而是通過了3個代理！那么問題來了，Alice是怎么找到這些代理的了？ alice和代理、代理之間、代理到Jane之間的通信數據萬一被截獲了怎么辦了？

         

•      tor開源了，官網的源碼下載地址：https://www.torproject.org/zh-CN/download/tor/   （需要FQ）
•      使用tor瀏覽器訪問網頁，除了走正常的http/https協議的流程外，tor還需要先訪問目錄服務器，從目錄服務器拿到中繼服務器的地址和公鑰（這是tor的致命問題之一：目錄服務器的數量有限，一旦屏蔽目錄服務器，tor瀏覽器就用不了了；據說防火牆有專人盯着目錄服務器，一旦發現新增立即加入屏蔽的黑名單；后來tor又提供網橋中繼，但還是被防火牆盯上了........）  ; src/app/config/ 這里面存放了主備用目錄服務器的ip地址、端口和id，格式如下：全部都屏蔽還是很容易的......   
• 

         

•      再通過中繼服務器層層加密並轉發流量。為了更好地闡述建立加密通信鏈路的原理，這里簡單介紹一下加解密的種類：

             （1）對稱加密：加密密鑰和解密密鑰是一樣的，優點是加解密速度相對非對稱加密快一些，但密鑰一定要保管好；代表算法是AES；

             （2）非對稱加密：加解密密鑰不同，分公鑰和私鑰；公鑰加密后只能用私鑰解密。同理，私鑰加密后只能公鑰解密；公鑰之間、私鑰之間是無法互相解密的；利用這個原理，一般對外公開公鑰，自己保留私鑰，然后雙方互相通信。常用於數字簽名，比如https協議的證書驗證；代表算法是橢圓曲線（比特幣加密用的就是這種）、RSA；

•      建立通信鏈路的過程（本質上是拿到中繼節點的公鑰，用於后續通信時加密數據包）:   

1. 客戶端與目錄服務器建立鏈接，並從目錄服務器中選取一個時延最低的服務器作為第一個中繼服務器/OR1；
2. 客戶端向OR1發送一個請求建鏈請求，OR1驗證完客戶端的合法性后生成一對密鑰（公鑰pubkey_OR1_Client、私鑰prikey_OR1_Client）,然后將公鑰pubkey_OR1_Client發回給客戶端（至此，客戶端成功的建立了其與OR1的通信鏈路）；
3. 客戶端又從目錄服務器中選擇一個時延最低的中繼服務器OR2，並向OR1發送一個數據包：使用pubkey_OR1_Client加密OR2的地址；
4. OR1收到數據包后使用prikey_OR1_Client解開數據包，發現是一個讓其自身與另外一個服務器OR2建立鏈接的請求，那么OR1重復步驟2與OR2建立鏈接，並將OR2返回的OR1與OR2鏈路的公鑰pubkey_OR1_OR2返回給客戶端；
5. 客戶端重復步驟3、4，建立OR2與OR3之間的通信鏈路，並接收到OR2與OR3之間鏈路的公鑰pubkey_OR2_OR3；
6. 至此，客戶端與3個中繼服務器之間的鏈路/circuit已經成功建立，客戶端擁有3把公鑰：pubkey_Client_OR1、pubkey_OR1_OR2、pubkey_OR2_OR3。

•      通信鏈路建立了，接下來該發數據了，數據加密的過程如下：

1. 客戶端將要發送的數據（data）經過3層加密包裹：*第一層：使用pubkey_OR2_OR3加密data：pubkey_OR2_OR3(data)；*第二層：使用pubkey_OR1_OR2加密第一層加密后的數據：pubkey_OR1_OR2(pubkey_OR2_OR3(data))；*第三層：使用pubkey_Client_OR1加密第二層機密后的數據：pubkey_Client_OR1(pubkey_OR1_OR2(pubkey_OR2_OR3(data)))；
2. OR1收到客戶端發來的數據后使用其與Client鏈路的私鑰prikey_Client_OR1解開數據包，發現數據包是發往OR2的，那么OR1就將解開后的數據包發送給OR2；
3. OR2收到OR1發來的數據包重復OR1的步驟：將接收的數據包解開發往OR3；
4. OR3收到數據包后，使用prikey_OR2_OR3解開數據包，這個時候的數據包是客戶端要發往目的服務器的真實數據包data。此時，OR3就將data路由給目標服務器。
5. 這就是洋蔥名稱的來源：數據被公鑰層層加密發送。每個中繼節點收到數據后都用自己保存的私鑰層層解密，直到看到最終的目的數據包；

     2、洋蔥效果：

   （1）洋蔥連接的日志：先去directory找relay descriptor，再build a circuit！

2/19/21, 06:32:15.640 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/19/21, 06:32:15.640 [NOTICE] Switching to guard context "bridges" (was using "default")
2/19/21, 06:32:15.640 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/19/21, 06:32:15.640 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2/19/21, 06:32:15.640 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2/19/21, 06:32:15.640 [NOTICE] Opened Socks listener on 127.0.0.1:9150
2/19/21, 06:32:15.640 [NOTICE] Renaming old configuration file to "D:\Program Files (x86)\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.1"
2/19/21, 06:32:15.453 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
2/19/21, 06:32:15.454 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
2/19/21, 06:32:16.507 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
2/19/21, 06:32:16.901 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
2/19/21, 06:32:17.270 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done
2/19/21, 06:32:17.270 [NOTICE] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
2/19/21, 06:32:17.639 [NOTICE] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
2/19/21, 06:32:18.700 [NOTICE] Bridge 'bridge' has both an IPv4 and an IPv6 address.  Will prefer using its IPv4 address (212.12.48.75:8443) based on the configured Bridge address.
2/19/21, 06:32:18.700 [NOTICE] new bridge descriptor 'bridge' (fresh): $11A09CD2766DE5D2625408A92781CA5E65ACFC7E~bridge at 212.12.48.75 and [2a00:14b0:4200:3000:75::1]
2/19/21, 06:32:18.100 [NOTICE] Bridge 'hnapel4tor' has both an IPv4 and an IPv6 address.  Will prefer using its IPv4 address (51.75.74.245:8356) based on the configured Bridge address.
2/19/21, 06:32:18.100 [NOTICE] new bridge descriptor 'hnapel4tor' (fresh): $18C27C9850967FD4BF4188963C1AEBEC40807823~hnapel4tor at 51.75.74.245 and [2001:41d0:701:1100::285d]
2/19/21, 06:32:18.406 [NOTICE] Ignoring directory request, since no bridge nodes are available yet.
2/19/21, 06:32:19.406 [NOTICE] Ignoring directory request, since no bridge nodes are available yet.
2/19/21, 06:32:21.407 [NOTICE] Ignoring directory request, since no bridge nodes are available yet.
2/19/21, 06:32:23.850 [NOTICE] new bridge descriptor 'PickANickname' (fresh): $6FBA3EB375D3849B61996B614EE26441D5AC4C1A~PickANickname at 217.102.166.147
2/19/21, 06:32:24.774 [NOTICE] Bootstrapped 30% (loading_status): Loading networkstatus consensus
2/19/21, 06:32:31.783 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
2/19/21, 06:32:32.156 [NOTICE] Bootstrapped 40% (loading_keys): Loading authority key certs
2/19/21, 06:32:32.798 [NOTICE] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
2/19/21, 06:32:32.798 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
2/19/21, 06:32:32.799 [NOTICE] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6655, and can only build 0% of likely paths. (We have 100% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
2/19/21, 06:32:33.237 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
2/19/21, 06:32:34.219 [NOTICE] The current consensus contains exit nodes. Tor can build exit and internal paths.
2/19/21, 06:32:36.799 [NOTICE] Bootstrapped 56% (loading_descriptors): Loading relay descriptors
2/19/21, 06:33:59.136 [WARN] Proxy Client: unable to connect to 217.102.166.147:19202 ("general SOCKS server failure")
2/19/21, 06:34:35.779 [NOTICE] Bootstrapped 61% (loading_descriptors): Loading relay descriptors

   （2）本人肉身在國內，用chrome訪問ip138查到自己的ip地址；同樣用洋蔥訪問（需要FQ），查到另一個ip地址：135.148.33.80，顯示在米國俄亥俄州；

     

    洋蔥自己給出的中轉鏈路: 本機通過網橋中轉到德國某中繼節點，然后再訪問ip138，但ip138顯示的是美國地址，這是怎么回事了？

   

   訪問google，又顯示ip在荷蘭:

  

   不但支持IPV4的地址代理，還提供IPV6地址的代理：

   

  洋蔥還支持使用新的線路：這次中繼是通過立陶宛和美國了，不再經過德國！

   

   訪問不同站點，自動使用不同的鏈路：

   

    （3）用process hacker查看，發現tor其實是基於firefox做的，自己增加了tor.exe和obfs4proxy.exe，分別用於和firefox通信、尋找網橋、建立通信鏈路等，並且都由firefox啟動；

      

      同樣在netword這里能查到遠程端口：

      

      從tor進程的remorte address和remote portal看，剛好是本機的firefox進程和端口，由此可以推斷: tor的主要功能之一是把流量轉發給firfox，再通過firefox發出去！

      

      接下來在wireshark抓包，看看tor和obfs4proxy這兩個進程在這些端口到底對外發了啥數據！

     （4）先用tor隨便打開一個網頁，比如ip138（這里多說一句：長時間用同一條鏈路，也容易通過類似超級ping的工具猜出真實的ip地址，所以tor會不定時更換鏈路），如下：

        

       同時抓包：發現抓到的大都是本機和網橋obfs4之間的通信。從源端口看，對應的進程是obfs4proxy，印證了之前的猜想: 都是obfs4proxy.exe和網橋之間發數據！發送的數據放Data字段，都是加密的！

       

       分析數據包的時候，發現另一個ip地址：212.12.48.75; 這個地址並未在瀏覽器的tor鏈路中展示出來，但根據雙方互相通信數據包的特征很容易能看出來：212.12.48.75就是osbf！

      

     比較明顯的特征如下：

•     TCP前面3次握手后建立連接
•     然后發送4個數據包，每個包的格式、長度完全一樣

     這也是tor的弱點之一： 瀏覽器和osbf之間的通信格式是固定的，很容易通過機器學習的模型、甚至是人為預設的規則檢測到（江湖傳聞防火牆也會根據部分數據包的特征識別這個包是不是FQ的）！

     3、大蒜路由I2P

     tor是匿名通信的鼻祖，但還是有比較明顯的缺陷：（1）上面提到的目錄服務器。一旦被防火牆ban，tor瀏覽器分分鍾失效   （2）一旦建立通信連接，雙方用這條線路互相傳數據；使用時間稍微長一點的話，有一定的概率被猜到； 為了解決這些痛點，大蒜路由孕育而生！

     I2P使用 Kad 算法（用過電驢或電騾的網友應該聽說過）來獲取網絡節點的信息，將傳輸的原始數據拆散為加密數據包通過多條隧道交叉疏散傳遞，其優勢如下：

•      不需要目錄服務器，不用擔心被防火牆“卡脖子”
•      Kad算法拿到的節點信息只是整個 I2P 網絡的一小部分
•      每一台運行 I2P 的主機都可以成為中繼，幫別人轉發數據（類似於 P2P 下載）。防火牆不太可能會將所有的I2P節點都加入黑名單ban掉！
•     上傳與下載（也就是雙方互相通信）的隧道相互獨立而且兩個方向上的隧道數量都可能>1；如下圖所示：比如A到E走藍色隧道，E到A走紅色隧道，並且隧道還有可能不止1條，增加了追蹤的難度！

          

 

 

參考：

1、匿名網絡概述：https://juejin.cn/post/6844903462224953351#heading-23

2、tor原理詳解：https://zhuanlan.zhihu.com/p/32445479

3、詳解Tor Bridge及Pluggable Transport（Part 1）：https://www.anquanke.com/post/id/194480