Mikrotik + ShadowSocks RSS + FinalSpeed/Socks?

chrisintaipei

chrisintaipei
個人積分：79分
文章編號：60836354

79分

樓主

2016-07-05 17:58

年初時本要弄 Mikrotik + metaRouter + OpenWrt + ShadowSocks (mikrotik + shadowsocks + 中國?) 但一直沒弄點點點

這幾天實在受不了了，準備開工，但這次想要改裝 ShadowSocks RSS (以下簡稱 SSR)。若有可能再加上 FinalSpeed / XSocks

考慮了幾個方案，想問看看已裝過的前輩會怎建議:

plan A
SSR, 照 breakwa11 的講法，SSR 的新功能 (我猜是指"tls1.2_ticket_auth" 伪装为tls ticket握手协议（强烈推荐），同时能抗重放攻击) 只有 Windows client ... 當下的想法是，那麼就裝個 Win7 在 ESXi 內吧

這邊的接法構想是，
1. Mikrotik (address list, mangle 要走通道的 packet 全轉到 ether3),
2. 然後 ether3 接到 ESXi 再接到 Win7.
3. 為了啟動 ICS (internet connection sharing) Win7 開兩個 NIC，一個是接 Mikrotik ether3。
4. Win7 內裝 SSR Windows client + ProxyCap，把 Mikrotik ether3 送過來的全經由 SSR Windows client 送出去
5. 若成功，再來研究 FinalSpeed / XSocks

以上有明顯的問題嗎?

plan B
後來發現好像 OpenWrt 也有 SSR client。那麼，若一開始是希望能快速上線，ESXi 內裝 OpenWrt 比較容易弄，還是買台 router 刷 OpenWrt?感覺刷機好像單純很多?家用的 Router 刷機跑 SS 或 SSR 穩定性不知道如何?有沒推薦的路由?聽說要選 mt7620 方案的?

這邊的接法構想是，
1. Mikrotik (address list, mangle 要走通道的 packet 全轉到 ether3),
2. 然後 ether3 接到 OpenWrt 的 LAN (期望所有的都轉出去)。
3. OpenWrt 的 WAN 再接回 Mikrotik
4. FinalSpeed / XSocks 可能就不能裝了?

有關 SSR vs SS，實際使用上不知道 SSR vs SS (ShadowSocks) 有差很多嗎? SS 現在與年初比起來有明顯被檔被干擾的問題嗎?若 SS 也還是很順，在想是不是就先很單純的把 SS 弄到會跑後再來考慮需不需要升級到 SSR。

2016-07-05 17:58 發佈

文章關鍵字 Mikrotik FinalSpeed/Socks ShadowSocks RSS

mandymak

mandymak
個人積分：11分
文章編號：60839346

11分

2樓

2016-07-05 23:16

chrisintaipei wrote:
年初時本要弄 Mikrotik...(恕刪)

我會擔心你 "Win7 內裝 SSR Windows client + ProxyCap，把 Mikrotik ether3 送過來的全經由 SSR Windows client 送出去" 這部分, 建議用openwrt會較易處理. 小妹我前兩天試架了ss, 可能因為我功力不足, 效果很糟糕. 反而我用iPhone試了一下經CN2 VPS中轉的OpenConnect VPN, 效果很不錯, 這也可以用openwrt處理.

chrisintaipei

chrisintaipei
個人積分：79分
文章編號：60840289

79分

樓主

2016-07-06 0:55

mandymak wrote:
我會擔心你 'Win7...(恕刪)

明天買一台 MT7620 的來刷看看~

chrisintaipei

chrisintaipei
個人積分：79分
文章編號：60844910

79分

樓主

2016-07-06 12:16

剛看到的

Breakwa11 是 ShadowSocks RSS 的作者

========

原ShadowSocks協議的TCP連接部分，使用非常簡單的協議，加密前是這樣子的：
地址類型(1byte)|地址(不定長)|端口(2byte)
其中，地址類型有三個可能取值：1，3，4，分別對應IPv4，Remote DNS，IPv6
地址的長度就按這個地址類型取值來決定，後面這些不詳細介紹了，不是關鍵的東西。

而加密的時候，會根據不同的加密算法，在前面添加一些隨機字節，再進行加密，以使得即使發送相同的數據，加密的結果也不會相同。但是，同一個加密算法下，前面添加的隨機字節的長度是固定的，而最常用的加密算法只有rc4-md5和aes系列（aes-128-cf8和aes-256-cfb等等），而非常的不巧，這些加密算法在使用的時候前面均添加16字節，於是前文所說的表示地址類型的那個字節的位置是完全固定的（在第17字節上）。

服務端為了判斷數據是否有效，判斷的依據就是表示地址類型的那個字節，看它是不是在那三個可能取值，如果不是，立即斷開連接，如果是，就嘗試解析後面的地址和端口進行連接。

基本的原理介紹完了，以下介紹如何進行主動探測。
因為SS判斷數據的合法性，僅僅依據表示地址類型的那個字節，與此同時，根據信息論，對加密後的數據解密的時候，同一個位置上的數據如果窮舉全部256個編碼，那麼能正好一一對應解密後的全部256個原碼，這與密碼長度還是用什麼加密算法完全無關。那麼，可以通過暴力嘗試全部256種可能，找出服務器是否有三種情況下沒有立即關閉連接，從而成功判斷出這個端口開放的是SS服務。成功判斷出這是SS服務器為了什麼呢？聰明的你應該明白，在這之後你的IP或者你的服務器IP其中一方會落入黑名單。
PS.因為chacha20填充的長度是8字節，和其它加密用的長度並不一樣，於是你會發現用chacha20的往往比其它加密算法穩定，只是因為這個長度較少被用於探測。

關鍵的問題就是，只需要窮舉256種可能，成本太低了，太不安全了。也許clowwindy也意識到這個問題，他在issue中提出到考慮讓服務端發現連接的數據不正確的時候，把數據重定向到一個正常的http網站，讓其行為看起來比較一致從而不好分辨。但是這個修改還沒有完成，為什麼clowwindy會被請喝茶？因為如果不阻止，那麼加入這個特性後會讓ss封鎖起來困難很多，所以請喝茶，阻止更新，然後才方便對其實施大規模封殺（畢竟按照新的特性重新寫探測代碼很麻煩不是）。在我知道clowwindy被請喝茶那天，我已經明白根本不是因為ss不好封殺，而是阻止更新然後去封殺，這個弱點已經被掌握並正在被運用，大規模封殺那天會到來得很快。

但是，那個改進依然不安全，還是只要窮舉256種可能，看一看是不是有253種情況是http/https協議就行了，所以我沒有考慮這麼做（不過我想得還是粗糙，這點其實是猜的，有誤請指出）。如果是多用戶服務器，就更簡單了，直接端口掃瞄，看看開放的接口是不是大部分都是http（甚至全都指向同一地方）就行了，總之這種做法特徵明顯。

我感覺上，這個如果不從協議上去解決，還是很難避免被封殺，於是在原來的SS協議頭，添加了一個包裝，在這裡複製一下這個包裝的結構說明：
標誌版本號(1byte)|首包總長度(2byte)|隨機填充長度(1byte)|隨機填充數據|原ss首數據包|CRC32(4byte)
起關鍵作用的，就是末尾的CRC32，前面的數據包不管你如何去猜測，有了CRC32作為整個數據包的校驗，窮舉成本提升到至少256的5次方，即需要嘗試10^12次，或1T次，產生的數據量將達到幾十T，這樣子去暴力破解還不如直接DDOS的成本低。另外，為啥CRC32放最末尾？一是為了方便校驗，二是根據加密的特性，前面的數據只要改了一個，就會導致後面的數據完全不一樣，這樣只要前面的數據一動，後面所有的值就都錯了，讓CRC32校驗充分發揮作用。
另外還有一個關鍵的地方就是隨機填充不定長度的數據。現在其實除了新的Windows C#版客戶端，其它平台基本沒有把握手包和第一個數據包連起來發送，這樣會導致SS客戶端發送的第一個數據包的長度，在很多情況下是固定的，從而成為被檢測的依據。就算實現了連同第一個數據包一起發送，但某些協議的連接並不會立即產生第一個數據包，而是先等待服務端的回應（比如 SSH），於是依然存在定長的問題（會精確等於16+1+4+2=23字節，只要統計發現你的IP經常產生23字節的TCP首包便可封殺）。為方便其它平台以最少的代碼實現，直接在協議頭部加入這個隨機填充長度，以彌補ss在加密時總是產生定長數據包的問題。

這個解決方案能極大增加主動探測的難度以及首包長度檢測的難度（非首包長度目前沒有混淆，儘管還是可以通過非首包長度進行猜測，但畢竟需要的計算資源較大，這樣調整後的SS還是能存活較長的時間的），但不想對SS協議做太大的改動從而造成各平台實現的修改困難（在Python或C#上增加支持這個協議才10行代碼不到），SS之所以能實現如此多的平台，正是因為其協議簡單，容易實現，所以我決定使用比較簡單的協議來解決以上問題。

如果以上協議你還發現存在弱點，請留言告訴我，大家一起討論——by Breakwa11

weiyu99

weiyu99
個人積分：57分
文章編號：60852415

57分

5樓

2016-07-06 23:22

chrisintaipei wrote:
年初時本要弄 Mikrotik...(恕刪)

直接找一台夠力的 router 刷 openwrt 跑 ss 當一級路由然後接mikrotik 當二級路由不是比較簡單？

chrisintaipei

chrisintaipei
個人積分：79分
文章編號：61115771

79分

樓主

2016-07-29 15:31

weiyu99 wrote:
直接找一台夠力的 router 刷 openwrt 跑 ss 當一級路由然後接mikrotik 當二級路由不是比較簡單？

今天終於開始導入 SSR 了~ 碰到了幾個問題，也發現看來 Weiyu 講的沒錯，mikrotik 必須要當二級路由不然變的好複雜。。。

我是找了個有提供 SSR 的服務商，CN2 線路有走香港及日本的。他們建議我走香港。上海到台灣約 50ms 蠻不錯的。速度，fast.com 30M 出頭，speedtest 約 14M/25M。費用是 RMB 300 一季。安裝費 RMB 80。他們說這個是限時特價。香港出口是 Alibaba。

我的 SSR 是 Asus AC56U 洋垃圾版本，差不多 RMB 400。

線路的穩定性。。。因為只有 TCP 走 SSR，還在想怎測試較容易。現在準備再弄一台 Mikrotik 然後跑上海 SSTP -> SSR -> 台灣 SSTP server。這樣應該就能全網路都走 SSR 出去了。

服務商特別強調一件事(不是第一次聽到)，要禁用 360 brwoser。據說 360 與 GFW 有合作，會提供訊息讓 GFW 鎖 IP。我之前台灣 IP 被鎖可能就是因為辦公室有人用 360 上網吧(那時確定是有人有使用 360 browser，只是不知道被鎖有可能是 360 害的)。

=====

如果我们发现您在使用360浏览器连接 xxxxx 加速网络，第一次我们会邮件通知提醒您，第二次我们则会根据用户协议暂停或删除您的帐号。

mandymak

mandymak
個人積分：11分
文章編號：61116967

11分

7樓

2016-07-29 17:02

chrisintaipei wrote:
今天終於開始導入 SSR...(恕刪)

當然是限時特價啦! 你自己去看看阿里雲國際版 (利申:在用).

另外小妹我有在用QQ和360等一堆, 沒有出現你服務商所說的情況.

所以有點覺得服務商有點在欺騙你.

chrisintaipei

chrisintaipei
個人積分：79分
文章編號：61117214

79分

樓主

2016-07-29 17:23

mandymak wrote:
所以有點覺得服務商有點在欺騙你

也許是騙我吧，但我原本就已禁止辦公室使用 360 的東西，所以多個理由強力要求不準使用~

在研究怎在 Mikrotik 上做 DNS redirection... 要鎖應該是在 mangle 的 content 上只要看到 360.com 或 360.cn 就擋掉吧?content 應該是指 URL 的一部份?