前言

2022年了，隨著墻越來越高，以及部分運營商的墻中墻封鎖，不僅Steam社區(qū)無法正常訪問，就連商店也時不時抽風。
ASF的運行需要訪問Steam社區(qū)檢查游戲和掉卡情況，需要特殊手段才能訪問到steam社區(qū)茍活。
好在Steam社區(qū)只是普通的封鎖，并不是實質意義上的“墻”，實現(xiàn)訪問。
筆者根據自己的實際例子介紹阻斷方式和解決方法，以及自己在部署時用到的ASF本地反代和https安全部署，希望有遇到同樣問題的朋友可以有所幫助。
文章可能會有不嚴謹?shù)腻e誤，請大家積極指出，我也會盡量完善。

縮寫術語ASF（ArchiSteamFarm）

目前最主流的Steam掛卡程序，代碼完全開源，不必擔心留有后門，可以在多個平臺上運行，現(xiàn)已有中文WIKI。本文主要記錄在Ubuntu(Linux)服務器上的部署教程。但對于沒有用過ASF并不熟悉Nginx的萌新來說，還是建議在Windows上調試成功后再轉到云服務器上。

HTTP（Hyper Text Transfer Protocol）

超文本傳輸協(xié)議，日常瀏覽的各種網頁都是通過HTTP協(xié)議傳輸，但是它的傳輸過程沒有加密，不安全，所以被HTTPS替代。
目前市面上所說的支持HTTP一般是指HTTP和HTTPS功能都可以實現(xiàn)，而不是只支持HTTP。

TLS（Transport Layer Security）

安全傳輸層，它的前身是SSL，它實現(xiàn)了將報文加密后再交由TCP進行傳輸?shù)墓δ?。即HTTP + TLS = HTTPS

SNI（Server Name Indication）

服務器名稱指示，簡單來說，是用于在一臺服務器的相同端口上部署不同證書的方法。服務器根據收到請求中的SNI域名來處理相應的請求，如果SNI域名為空，會按照預先設置好的默認域名處理請求。

CDN（Content Delivery Network）

內容分發(fā)網絡，各個地區(qū)部署的服務器在一起形成的高速網絡拓撲，用戶在每個地區(qū)都能實現(xiàn)快速訪問。CDN通過SNI響應不同的網站，同時也保護根服務器的安全。

Nginx

主流的高性能開源HTTP反向代理工具，主要用于反向代理、負載均衡和動靜態(tài)資源分離。本文只用到了反向代理服務實現(xiàn)訪問Steam社區(qū)和加防自己的ASF。

反向代理

在根服務器前部署一臺外層服務器做為網關，用戶只能訪問到外層服務器，從而保護內網服務器不被暴露。做為網關，也可以對報文分析和修改。
代理服務器和根服務器部署在一臺主機上稱為本地反代。

1. ASF下載與安裝

1.1 ASF版本選擇

ASF有著Steam賬號的高度控制權，所以安全部署尤為重要。
為保證程序不被惡意篡改，請務必在作者倉庫上下載！
隨著ASF版本的不斷迭代，會修復許多安全漏洞，增強安全性，所以這里推薦使用最新穩(wěn)定版。
我在部署時使用的版本是5.2.3.7，本文的所有操作均已在這個版本試驗通過。
ASF在每個版本號下根據系統(tǒng)的不同又分為不同的文件，根據系統(tǒng)和CPU制造商來選擇正確的版本，也可以直接下載源碼編譯。

我的服務器是跑在Intel CPU上的Ubuntu，所以下載ASF-linux-x64.zip文件。

1.2 ASF下載

Linux上下載方式很多，例如wget指令。
wget https://github.com/JustArchiNET/ArchiSteamFarm/releases/download/5.2.3.7/ASF-linux-x64.zip
由于不可描述的原因，Github在大陸下載緩慢甚至無法下載。解決方法網上也有很多，可以自己在電腦上下載后再上傳到云服務器，也可以通過鏡像站下載，這里不再過多贅述。

1.3 ASF安裝及使用

Linux使用unzip命令解壓zip文件。
筆者在當前目錄下新建了asf文件夾，并解壓到里面。
mkdir asf
unzip ASF-linux-x64.zip ./asf/
解壓后，運行ArchiSteamFarm文件即可。
如果顯示Permission denied或文件名為灰色，則需要執(zhí)行chmod +x ArchiSteamFarm獲取執(zhí)行權限。

如果顯示2022-03-16 15:29:39|ArchiSteamFarm-1377456|INFO|相關字段，說明ASF已經成功安裝。

2. Steam社區(qū)受屏蔽情況和理論解決方法（跳過也不影響）

起初，國內通過DNS污染以及HTTP報文關鍵字檢測來攔截訪問Steam社區(qū)內容。
在DNS污染下，瀏覽器訪問會出現(xiàn)ERR_CONNECTION_TIMED_OUT錯誤，因為DNS會被指向一個不可訪問的地址，訪問也就超時了。
解決方法就是在本地就做好解析，通過修改Hosts文件直連IP訪問。
但是這不是重點，現(xiàn)在的Steam社區(qū)也不是這么簡單的屏蔽方式。
2018年開始，Steam社區(qū)默認采用HTTPS鏈接，所有的瀏覽內容都會被加密，報文關鍵字檢測的方法也就失效了。
隨后出現(xiàn)了更深層次的審查方法，也就是要詳細介紹的SNI檢測。

2.1 SNI

正常情況下，TLS握手需要經歷以下幾個階段。

在Client Hello階段，由于雙方還未協(xié)商好加密方式，報文仍然是明文狀態(tài)，其中Extension字段包含了SNI信息，也就包含了當前正在訪問的域名steamcommunity.com，可以抓包獲取到。

正常情況下，服務端根據這個域名發(fā)送相應的域名證書，進行接下來的握手步驟，在協(xié)商完后開始使用加密通信。
但是，SNI已經暴漏，審查機構會對當中的域名進行檢測和阻斷，也就是TCP重置攻擊，通過對雙方瘋狂發(fā)送RST報文使連接重置，如果是瀏覽器訪問就會出現(xiàn)ERR_CONNECTION_RESET錯誤。
看完了可能會困惑，為什么要有SNI這個東西存在，握手過程沒有它不也沒有影響嗎？
是的，在以前，每個服務器只會綁定一個域名，SNI完全沒有存在的必要，訪問某個服務器也一定只訪問這個域名。
但是隨著CDN的迅速發(fā)展，大多數(shù)網站為了提升響應速度和安全等級，都會將服務交給CDN托管，也就是說每個CDN服務器都會為多家網站提供服務，例如Steam就將業(yè)務部署在CDN服務商Akamai上。
CDN服務器會根據用戶要訪問的域名提供相應的內容，也就是識別SNI中的域名返回相應的頁面。所以SNI對于現(xiàn)在的互聯(lián)網環(huán)境已經不可或缺了。

2.2 那么有什么辦法可以解決呢？

答案很碰巧，就是在Client Hello階段不攜帶SNI或者攜帶無效的SNI，隱藏真實的連接網站來規(guī)避互聯(lián)網審查。
當CDN檢測到無效的SNI，會返回一張默認證書以便能夠繼續(xù)連接。碰巧的是，Akamai所返回的默認證書就是Steam的泛域名證書（畢竟Steam是最大的客戶）。
這種技術叫做域前置，截至目前對Steam、Pixiv、Github等大型網站都有效。
下面就來介紹具體的實施過程。

3. 配置Nginx本地反向代理連接Steam社區(qū)（國外云服務器跳過）

好在這種阻斷方式只是普通的封鎖，并不是實質意義上的“墻”，可以通過本地反向代理繞過審查。
Windows端可以通過steamcommunity 302輕松解決（羽翼城大佬YYDS）。
Linux端可以參考他的文章 steamcommunity 302 V2(steam118錯誤修復工具) v12.1.25 綠色免費版
鑒于Nginx是主流以及它還跑有其他服務，這里根據大佬的思路在Nginx上實現(xiàn)。

將Steam社區(qū)等域名添加到Hosts文件中并指向localhost，這里的localhost僅做為一個本地安全跳板，供Nginx正常監(jiān)聽的同時又能防止流量外泄。Nginx將監(jiān)聽到的數(shù)據中的SNI信息去除，再送向CDN的IP，使用IP而不使用域名是為了防止DNS污染，既實現(xiàn)完整通信又不被互聯(lián)網審查到。

3.1 配置Host

將訪問困難的域名添加到Hosts文件中，配置如下：

127.0.0.1 steamcommunity.com
127.0.0.1 www.steamcommunity.com
127.0.0.1 store.steampowered.com
127.0.0.1 api.steampowered.com

一些云服務器在每次重啟后會恢復默認Hosts，服務器提供商不同解決辦法也不同，具體操作請自行百度。
下面的Nginx配置也會用到這些域名。

3.2 生成并安裝證書

整個通信過程必須使用HTTPS加密協(xié)議，一是為了避免審查機構的報文關鍵字檢測，二是Steam禁止明文HTTP訪問，會自動跳轉到HTTPS訪問。
作為本地反代服務器，Nginx將監(jiān)聽的報文頭處理后再發(fā)送給CDN，但是此時的Nginx服務器在宿主機看來是“不可信”的，除非強制讓其可信，也就是在主機安裝CA根證書，同時HTTPS反代也需要部署中間證書。

網上的許多教程都是用命令生成的證書，步驟比較復雜。不會操作的可以運行steamcommunity 302自動生成證書，上傳到服務器。
302工具第一次使用后會在根目錄生成一堆證書和密鑰。

只需要將steamcommunity.crt、steamcommunity.key和steamcommunityCA.pem三個文件上傳到服務器。

三個文件的作用

steamcommunityCA.pem：通過Openssl（302工具內置了Openssl）自簽的CA根證書。只有在服務器中添加并信任根證書，它所簽發(fā)的二級證書才會被信任。
steamcommunity.crt和steamcommunity.key：上述CA根證書簽發(fā)的二級證書，Nginx在反代時使用該證書和私鑰對流量進行加密。只有服務器信任了CA根證書，用二級證書加密的流量才會被視為安全。

將steamcommunity.crt和steamcommunity.key放在任意一個能讀取到的路徑就好。例如放在/etc/nginx/ca-certificates/下方便管理，在Nginx配置文件中也方便填寫相對路徑。
不同的系統(tǒng)，安裝CA證書的方法也不同。
例如在Ubuntu中，將steamcommunityCA.pem命名為steamcommunityCA.crt扔進/usr/local/share/ca-certificates/，然后執(zhí)行update-ca-certificates安裝。

3.3 配置Nginx參數(shù)

Nginx的配置文件位于/etc/nginx/nginx.conf，這里給出基本配置：

server {# 部署一個虛擬主機
        listen localhost:443 ssl;# 監(jiān)聽localhost的443端口
        server_name steamcommunity.com;# 添加要監(jiān)聽的域名，與Hosts文件里的域名一致
        server_name www.steamcommunity.com;
        server_name store.steampowered.com;
        server_name api.steampowered.com;
        ssl_certificate ca-certificates/steamcommunity.crt;# 設置證書，這里使用了相對路徑，絕對路徑也行
        ssl_certificate_key ca-certificates/steamcommunity.key;# 設置與證書匹配的密鑰，同上
        location / {# 當監(jiān)聽的端口檢測到通往上述域名的流量時，執(zhí)行下列操作
                proxy_pass https://223.119.248.24/;# 將流量送往223.119.248.24主機，理論上任何一個Akamai服務器IP都可以
                proxy_set_header Host $http_host;# 務必要加上，否則會報錯URL非法
        }
}

做完后記得讓Nginx重新讀取配置，也就是找到Nginx的主程序然后nginx -reload。

問：為什么要監(jiān)聽443端口？
答：因為ASF使用Https協(xié)議請求Steam獲取數(shù)據，也就是日常瀏覽網頁的方式。Https協(xié)議默認通過443端口傳輸，所以proxy_pass https://223.119.248.24/;可以不加443。
問：如果不配置證書或證書不可信會怎樣？
答：如果在是瀏覽器訪問，會提示連接不安全，但仍可以訪問。如果是ASF或Steam客戶端會默認禁止SSL證書無效的連接。

4. ASF配置

所有配置文件都存放在ASF根目錄下的config文件夾。
如果目錄為空（初次安裝），ASF會走默認配置；如果有配置文件，ASF會優(yōu)先走文件里的配置，文件里沒有寫到的就走默認配置。
大多數(shù)配置文件都可以直接文本編輯或者通過ASF-ui修改，還可以用官方編寫的ASF配置文件生成器修改后上傳。
在官方Wiki上能找到所有的中文教程，這里只說下基本配置。

4.1 ASF.json配置

ASF.json存放ASF的全局配置，主要是程序上的配置，基本格式如下：

{
  "Headless": true,
  "IPCPassword": "網頁登入密碼",
  "SteamOwnerID": Steam帳號64位ID
}

請務必設置IPC密碼（IPCPassword），因為它是ASF的最后一道防線！

4.2 IPC.config配置

IPC包括了各種ASF-api和ASF-ui界面，前者用于插件和界面的二次開發(fā)；后者是ASF自帶的操作界面，默認部署在localhost:1242端口上，通過瀏覽器就能訪問。
IPC.config存放HTTP服務端的相關配置（就是ASF操作界面的IP、端口、證書相關配置），配置如下：

{
    "Kestrel": {
        "Endpoints": {
            "example-http4": {
                "Url": "http://127.0.0.1:1242"
            },
            "example-http6": {
                "Url": "http://[::1]:1242"
            },
            "example-https4": {
                "Url": "https://127.0.0.1:1242",
                "Certificate": {
                    "Path": "/path/to/certificate.pfx",
                    "Password": "passwordToPfxFileAbove"
                }
            },
            "example-https6": {
                "Url": "https://[::1]:1242",
                "Certificate": {
                    "Path": "/path/to/certificate.pfx",
                    "Password": "passwordToPfxFileAbove"
                }
            }
        }
    }
}

IPv6尚未普及，一般使用IPv4部署ASF。

5. ASF 安全部署方案

平常在電腦上安裝ASF，ASF-ui默認監(jiān)聽localhost:1242端口，考慮到僅在本地訪問所以Http通信足矣。但如果是部署在服務器上，ASF-ui就要暴露在公網上被我們所訪問。在公網上不能保證自己的IP不被監(jiān)聽，如果繼續(xù)使用Http通信，流量中的明文密碼將會泄漏。
因此，我們要將明文流量通過TLS加密，也就是使用Https協(xié)議，這樣即使被別有用心的人監(jiān)聽到也只是加密的數(shù)據，對方無法解密，也就確保了密碼相對安全。
ASF自身支持以Https方式啟動ui，也可以使用Nginx本地反代Http協(xié)議下的ASF。

不管哪種方式，都需要申請ssl證書才能啟用HTTPS。而申請ssl證書需要一個合法域名。國內幾乎申請不到免費的域名，免費方案下只能從外網免費申請了，我用的是Freenom申請了一年的.ml后綴域名。
得到域名擁有權后再到國內云服務商上申請國內解析權，這樣解析速度就和國內購買的域名一樣了。

至于ssl證書申請，可以使用各大云免費申請一年，提交申請后半小時內就能下來。
如果域名備案了，就可以放心使用443端口，否則就會被互聯(lián)網審查機構攔截阻斷。畢竟ASF一般都是私用，選擇默認1242端口就好。使用其他自定義端口沒有實際增加安全性，但可以避免過于明顯的掃描。

一定要記得在服務器上放行相應端口！

下面簡述幾種常見的安全部署方案：

5.1 本機運行 ASF（僅Http）

如果只部署在localhost，除非本機被攻破，否則ASF是安全的。
IPC.config配置如下：

{
        "Kestrel": {
                "Endpoints": {
                        "example-http4": {
                                "Url": "http://localhost:自定義端口"
                        }
                }
        }
}

5.2 公網運行 ASF（僅Https）

這種情況下，ASF將暴露到整個網絡，必須配置SSL證書+Https協(xié)議，否則在數(shù)據傳輸過程中IPC密碼將以明文顯示，有被監(jiān)聽走的風險。
在申請的證書中下載pfx格式證書，然后在IPC.config中添加pfx證書和相應的私鑰字符串。
IPC.config配置如下：

{
        "Kestrel": {
                "Endpoints": {
                        "example-https4": {
                                "Url": "https://自定義域名或IP:端口",
                                "Certificate": {
                                        "Path": "config/我的域名證書.pfx",
                                        "Password": "pfx證書附帶的私鑰"
                                }
                        }
                }
        }
}

如果使用相對路徑，以ASF主程序的同級目錄為當前路徑。

5.3 公網運行 ASF（Http + Nginx Https反代）

此時的IPC.config配置可以默認，默認了話就是監(jiān)聽本地1242端口，然后通過Nginx監(jiān)聽公網443端口。
nginx.conf配置如下：

server {
        listen 443 ssl;# 監(jiān)聽443端口，這里就包括了公網訪問進來的端口
        server_name www.我的域名.com;#添加要監(jiān)聽的域名，也就是申請的域名
        ssl_certificate /etc/nginx/ca-certificates/我的域名SSL證書.crt;# 添加crt證書路徑，絕對路徑也可
        ssl_certificate_key ca-certificates/我的域名SSL證書.key;# 同上
        location / {# 當監(jiān)聽到上述域名的流量時，執(zhí)行下列操作
                proxy_pass https://localhost:1242/;# 將流量送往ASF監(jiān)聽的端口，默認是localhost:1242
                # 使用下列的配置，ASF能正確檢測到發(fā)送請求用戶的IP地址
                # 使ASF能夠封禁真正的攻擊者而非Nginx反代服務器
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Host $host:$server_port;
                proxy_set_header X-Forwarded-Host $host:$server_port;
                proxy_set_header X-Forwarded-Server $host;
                proxy_set_header X-Real-IP $remote_addr;
        }
}

若訪問頁面出現(xiàn)502 Bad Gateway，說明Nginx反代正常，但未監(jiān)聽到ASF流量，請檢查IPC是否開啟以及l(fā)ocation匹配是否正確。

6. 結束語

這篇文章也是我查了很多資料后才寫出來的，為了講清楚從SNI檢測到屏蔽手段也是把各種協(xié)議都復習了一遍，甚至還通過抓包來證明自己的理解，如果有錯誤希望大佬們指出。
最后，希望這篇文章能幫助到需要的人。

參考文章

1. Linux/Macos環(huán)境下使用 steamcommunity 302 教程
2. ArchiSteamFarm wiki
3. 云服務器ASF掛卡——steamcommunity社區(qū)本地反代
4. 在手機上訪問discord和pixiv的正確姿勢
5. 淺談asf ipc于服務器部署之安全方案
6. 針對庫存被盜帖，討論 ASF 部署的安全性
7. ASF IPC網頁管理界面Nginx反代教程（帶Https）
8. 從 pixiv 免代理直連看 SNI 阻斷及其繞過方法——域前置
9. 自簽CA對Steam社區(qū)進行反代
10. HTTPS 之 SSL/TLS 握手協(xié)議（Handshake Protocol）全過程解析
11. How does a TCP Reset Attack work?

到此這篇關于從Steam社區(qū)屏蔽分析繞過方法及ASF安全部署的文章就介紹到這了,更多相關Steam社區(qū)屏蔽內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論