打造自用的Meek中繼反射器

因meek技術救活了tor，美博園轉載幾篇關於meek的技術探討文章，供網友研究開發meek技術之用。

背景

Tor的Meek混淆外掛程式最近比較好用， 由於Amazon、GAE和Azure上都有現成的中繼裝置， 直接讓Tor啟用Meek連接即可。

不過博主喜歡折騰， 用現成的東西感覺不是那麼爽， 因此多方嘗試折騰出一個自用的Meek反射器， 不用每次走Amazon的渠道了。

Meek基本原理介紹

首先啟用了Meek的Tor鏈路是這樣的狀態：

本地Tor客戶端->本地Meek客戶端->伺服器端Meek->伺服器端Tor網橋

由本地的Meek客戶端將Tor的數據包封裝並發送到伺服器端的Meek， 伺服器端解析並將數據塞給伺服器端的Tor， 由伺服器端的Tor處理數據。

從本地Meek到伺服器端的Meek連接便是Meek技術的核心所在， 即所謂的｢Domain Fronting｣技術。

本地Meek客戶端->Google雲伺服器->GAE上的Meek伺服器

現有Meek網橋的簡單分析

(以下內容為博主個人猜想，可能有重大謬誤...)

博主研究了Meek-Server的代碼後發現， 需要在伺服器搭建Tor並配置為網橋之後， 再讓Meek-Server在Tor的前端接入Tor的流量。

那麼就奇怪了， 難道所有的雲伺服器端都是部署了Tor的中繼伺服器？

查看Meek-client的Git倉庫， 可以看到有多個版本的Server端部署代碼， 包括AppEngine、php甚至是nginx的配置。

博主懂得一點php， 所以斗膽觀摩了一下php的代碼， 發現內容上其實只是把接收到的數據包轉發給一個特定的地址。

再繼續觀摩AppEngine和nginx的配置， 發現它們的思路都是一樣的， 轉發到下面這個地址：

https://meek.XXXX.com:1234

於是博主猜測真正的情況是這樣的： 其實GAE、Azure和AWS上現有的Meek中繼都不是真正處理數據的伺服器， 它們只是起到一個反射器(reflector)的作用， 將收到的數據包轉發到真正的Meek伺服器上， 上述的地址就是真正的Meek伺服器。

個人反射器的搭建

搞定了原理之後， 就可以著手打造自己的Meek中繼反射器了。

其實方法很簡單， 照著倉庫里的README把東西部署上去即可。

例如php版本需要一個能執行CURL的php空間， 把代碼上傳到空間上， 記錄下URL， 就可以配置本地的torrc進行使用了。

這裡假設配置好之後Internet上訪問的URL是這個：

https://foo.com/bar.php

那麼在torrc里的配置應該是這樣的東西：

Bridge meek 0.0.2.0:1 url=https://foo.com/bar.php

這裡的更改讓Meek把數據包發送到以上的地址， 由伺服器端的php代碼（或者是nginx的反向代理）轉發請求到真正的Meek伺服器上。

沒有front是因為這裡不需要Meek的｢domain fronting｣技術， 本來這個地址就沒有被幹掉， 此外， 如果這個網域被幹掉的話， 那麼用這個網域搭建的任何東西也都沒什麼意義。

收益分析

基於自定義URL的Meek反射器可以提供比較穩定的連接， 畢竟不是大量使用的話不會受到干擾或者封禁。

另外就是樹大招風， 像Google這種整個玉米被搞死的情況Meek也是無能為力的。 對於自定義URL則風險比較小。

當然這麼做的一個壞處是把Meek用歪了， 廢掉了Domain Fronting技術， 只是純粹的做一個數據包的轉發。

管它呢， 技術還是要能夠實現功能最重要～