我們觀測到今日CU9929的丟包直觀表現非常嚴重, 但通過我們自己的實際組網實踐發現實際上非常可控. 以下為解決該問題的處理辦法.
We’ve monitored the recent severe lossy network of CU9929. But in fact such situation can be handled by some means. Below is our solution to such issue.
出網(組網)使用WSS加密, 合理篩選SNI, 並不要使用重點IP
Using WSS Encryption for outbound network with selected SNI domains, and do not use blacklisted IPs
據悉本年度大會後, 墻對重點IP做了嚴格的禁止. 近期您使用 DMIT/BandwagonHost 均會遭到封鎖. 此類問題唯一解決問題只有更換非重點關注ASN下的IP位址.
在組網時請盡量使用WSS或一般TLS加密, 在TLS加密SSL選擇時, 務必選擇CA證書的SSL作爲加密通訊. 如果您的資金不允許, 也請盡量使用由Let’s Encrypt頒發的證書.
嚴格注意不要使用下列特徵的SSL作爲通訊證書:
1. 頒發者為隧道工具 (例如 gost.run / orris Tunnel )
2. 超長頒發年限 (10/100年)
3. 如果一定要僞裝所謂”白名單”域名, 也請注意不要使用大衆域名. 大多數情況下, 你的廉價落地IP配不上你選擇的SNI.
使用合適的端口
Using Proper Ports
通常情況下, 我們發現用戶會在詭異的端口上進行WSS或其他基於TLS/SSL加密的端口. 這會大大增加被阻斷封鎖的概率. 在使用9929時, 我們建議您優先選擇 500-9999 端口區間進行監聽. 如果您的轉發工具允許, 請盡量使用port hopping (或者多端口監聽, 以避免因單一端口阻斷出現都不能用的情況).
如果您購買的是NAT機型或者無權使用低位端口, 則我們一并建議您不要使用9929.
目前我們備品使用了 ZeroForwarder Panel, 沒有遇到顯著的阻斷問題. USSDWAN-LAX 為全量采用該面板部署. (非廣告, 無aff, 如果不喜歡, 請關閉本標籤頁).
