基於YARP實現的FastGithub

前言

最近開源的兩個項目,先是FastGithub,旨在解決訪問github抽風的問題。然後開發HttpMouse項目,基於yarp的http公網反向代理到內網的服務端與客戶端庫,在開發HttpMouse的這段時間裏,把YARP玩得徹底遛遛了,於是打算把YARP也用到FastGithub項目中,以徹底解決github抽風的問題。

原理

  • 修改本機的dns服務指向FastGithub自身
  • 解析匹配的域名爲FastGithub自身的ip
  • 請求不受污染的dns服務(dnscrypt-proxy)獲取域名的ip
  • 使用得到的ip進行無或有SNI的https反向代理

1.0.2版本的FastGithub,基於https測速來選擇github的最佳ip,但https連接時,在一些網絡環境下會表現爲“連接被重置”。在摸索出“一種https連接到github且連接不被重置”的辦法之後,決定讓FastGithub充當一個https反向代理服務器,用於接收瀏覽器的請求,然後把請求轉發給github,這裏又用上了YARP了。

實現

dns解析

FastGithub把自己實現一個dns服務器,當瀏覽器訪問github.com時,會向dns服務器解析github.com的ip,這時返回127.0.0.1。其實這個與修改host文件,讓github.com解析爲127.0.0.1效果是一樣的,只是dns的方式更靈活:FastGithub開啓,ip就爲127.0.0.1,關閉後ip自動從備用dns獲取。

https證書

FastGithub使用自頒發CA證書,爲github.com頒發證書,用於與瀏覽器客戶端的https請求與響應。證書的動態生成過程,與Filder是完全一樣的,而且都需要在用戶電腦將自頒發的CA安裝到信任根證書目錄。

無污染dns

dns協議由於沒有加密數據,又是無連接的udp,所以數據被僞造非常簡單,我們可以在本機運行dnscrypt-proxy,從dnscrypt-proxy解析域名的準確的ip,使用這個ip來做後續的請求轉發連接目標。

https請求轉發

使用“假證書”解密瀏覽器發給github的數據之後,將數據重新組裝爲github請求數據,發送到由dnscrypt-proxy解析到的ip的github服務器,同時把收到響應輸出給瀏覽器,這個過程使用YARP,YARP = asp.netcore + HttpClient。FastGithub與github之間的連接,不會受到tcp連接重置的問題。

與Filder比較

FastGithub與Filder的行爲非常相似,運行環境也相似,不同點在於Filder使用正向代理,配置系統或瀏覽器的代理服務器指向Filder,從而使請求數據經過Filder,而FastGithub是使用反向代理,配置系統的dns讓符合相關域名的解析爲本機ip,從而從而使請求數據經過FastGithub。

安全性說明

FastGithub生成自簽名CA證書,要求安裝到個人電腦上。但這個CA證書是FastGithub爲每臺不同計算機生成的,保存在CACert文件夾下的{計算機}.cer,就算是他人惡意將他自己生成好的CA證書打包捆綁再發型給別人,也因爲無法知道別人的計算機名而不會使用他生成的CA證書,從而確保用戶信任的這個CA證書不是他人生成的。

合法性說明

《國際聯網暫行規定》第六條規定:“計算機信息網絡直接進行國際聯網,必須使用郵電部國家公用電信網提供的國際出入口信道。任何單位和個人不得自行建立或者使用其他信道進行國際聯網。”

FastGithub本地代理使用的都是“公用電信網提供的國際出入口信道”,從國外的Github服務器到國內用戶電腦的流量,使用的是正常流量通道,其間未對流量進行任何額外加密(僅有網頁原有的TLS加密,用戶和代理人並不掌握該TLS密鑰,區別於VPN的流量加密),而FastGithub獲取到網頁數據之後發生的整個代理過程完全在國內,不再適用國際互聯網相關之規定。

源代碼與軟件發佈

源代碼

github上的FastGithub

軟件發佈

gitee上的FastGithub

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章