• 從地端 Redis server / Redis cluster 遷移到 雲端 ElastiCache 的四種方式

    通常redis 是用來做cache ,但是隨著各種應用野蠻而自由的發展,或者說濫用,redis 現在已經快要變成一個存儲everything 的database,比如wordpress 的object-cache plugin 就會把所有的posts 都丟進去,很多的遊戲廠商則有頻繁刷新的board/score ,以及各種遊戲人物的屬性。

    對雲端平台而言,以AWS 為例,從地端遷移redis 大概有這樣四種方式:

    1. rdb 文件從地端server dump 出來,上傳到S3,然後再從ElastiCache 服務來調用S3 上的rdb 文件進行恢復。
    2. ElastiCache 提供了在線遷移的方式,雖然官方文件上說支持在EC2 上架設的redis server,但實際上,只要你的網速夠快,你的redis 在哪裡都沒所謂,只要是自建的redis server 都可以,或者是支持CONFIG/SYNC/PSYNC/SLAVEOF 命令的第三方服務商。
    3. RIOT 是redis 官方推出的工具,大概是遷移需求實在是呼聲太高,而總是使用第三方的工具來遷移,似乎顯得redis 官方不作為。
    4. 開源的 redis-shake ,在實時同步方面被廣泛採用。這個工具需要調用源端的 sync/psync 命令,而這些命令在AWS/Azure/GCP 中都是被禁用的,如果源在雲端,則需要開立技術支持工單來啟用他們之後,才可以使用redis-shake。
    這一篇很長,Read more
  • AWS VPC 网络中基于 keepalived 的主备切换

    雲端並沒有什麼場景一定需要用keepalived,只不過是一些傳統企業地端思維揮之不去,當然,ELB 要花錢,省錢也是重要的因素,特別是業務沒有那麼重要,卻就是需要HA。

    但是,AWS VPC 並不支持VRRP multicast,這讓很多在地端運行的商業 Firewall/LB 廠商上雲之後都要做修改,比如F5/Radware/A10/深信服 等等,然而,並沒有官方文件說明AWS VPC 支持或是不支持,官方blog 文章在某種程度上可以視作你可以自己做,但是我們不會為你進行官方的技術支持,可就是有人看不懂。

    當然,官方blog 語焉不詳也是一個問題,SA們寫出許多不在官方支持範圍內但又可以在AWS 平台上運行的blog,但他們又沒有講得很清楚,你不去理解blog 而是完全照著去做,是會失敗的。

    這一篇很長,Read more
  • 中小企業如何出海-從中國境內流暢的訪問美國網路

    眾所周知中國的經濟依賴於基建和外貿,比如修到圖博的高鐵和出口到NewYork 醜陋的Labubu。

    在這期間眾多的中小企業在Amazon,Tiktok 上開店,如何從中國境內流暢的訪問美國網路,就成為一個很重要的課題。

    這些開店多年的商戶,有如下的選擇:

    1)使用所謂的“電信海外加速寬帶”,使用CN2,擁有出海的優勢。但是,这个服务只在少数的地区提供,例如上海。
    2)直接使用相對昂貴的香港運營商漫遊來更新商品清單以及使用WhatsApp 和海外的分銷商聯繫。
    3)使用一些公司提供的國際加速SD-WAN,我一直不清楚他們的運營模式,應該是有後台才對。他們會部署一台設備在本地,並進行流量分流( 是不是聽起來就很像openwrt 裝個plugin )。
    4)自建openvpn,這就是我今天想要說的坑。

    在擁有shadowsocks/v2ray/wireguard/ipsec 的今天,幾乎沒有人會使用openvpn 來做這件事情,因為大概十年前他就不能穿越GFW了,但是,總是有一些曾經在中國境內大規模部署openvpn 的客戶,以為可以順利的穿越GFW。

    畢竟,當你在10個省份的辦事處都部署了免費的openvpn 並且已經運行了數年之久,和那些買了深信服SSL-VPN 設備的公司比起來你為公司省下了不止一百萬人民幣的費用,你絕對不會以為你的配置有問題。

    或許,這些客戶的想法是:“我使用的是正規的openvpn ,又不是翻牆工具,怎麼會有問題呢。”

    問題不在於你使用的工具是不是正規,問題在於他可以達成什麼樣的目的。

    吶,一個問題供思考,openvpn 的官方網站 https://openvpn.net/ 在中國可以訪問嗎?

    大概是從2021年起,限流成為GFW 使用的最重要手段,我想這代表著GFW 的數據處理能力上了一個新台階,因為比起來,似乎發送一個RST 更簡單,更省資源才對吧?

    現在,GFW 通常會將第一次建立連接的加密流量 進行極端限流,然後當你發現慢慢的,沒速度了,斷開嘗試第二次連接的時候,你就會發現無法建立連接,無論你是從中國境內向境外發起連接,還是從中國境外向境內發起連接,WireGuard 也會遇到相同的情形,而IPSec 則是驗證失敗,即使密鑰和加密算法沒有問題,雖然有人認為是GFW 識別出了他們的協議特徵,但是識別特徵是一個很耗費資源的事情,而對不能快速識別的加密流量進行限流,則是一個通用的方式,無論是shadowsocks/v2ray/wireguard/ipsec 還是openvpn。

    這個問題我在大約十年前使用openvpn 的時候就已經發現,一度讓我懷疑我的智商,因為那個時候shadowsocks 還沒有經過歷史的考驗,我並不相信任何一個新的工具,我預估所有新出現的工具都是有後門和風險的。

    在第一次遇到這個問題的時候,你沒有辦法將他和GFW 聯繫起來,但那個時候對於openvpn 是直接進行阻斷,會收到RST ,和現在的表現很像但又略有不同,看起來像是openvpn 建立連接的時候送出的證書被檢測到,理論上來說是可以看到證書內容的,但隨機化證書的內容並不能改善這個情況。

    然而,如同一些研究⬇︎人員指出的,GFW 對流量的檢測和阻斷並不是廣泛針對所有的境外IP地址,而是一些熱門的雲服務商,例如AWS,Azure,GCP,Linode,DigitalOcean,Vultr 等等。

    當然,還是有很多方法是可以穿越GFW 的,

    比如v2ray+websocket+tls+CDN,取決於你到CDN 的速度。

    比如ipsec+GRE,能用就是慢了點。

    比如還有一些我沒試過的方法,我想其中應該也是有可用的方案:https://guide.v2fly.org/advanced/advanced.html

    只不過大多數人都只會使用一鍵安裝包。

    其實最簡單的方式是,你只要使用一些不熱門的雲服務就可以了,只要足夠冷門,上面的協議都可以使用。

    至於一直提供CN2 線路的搬瓦工 https://bandwagonhost.com/ , 擁有優秀的美中跨境能力,讓人不得不懷疑他背後的資本組成,特別是在美國註銷中國電信美洲公司和中國聯通美洲公司在美國的運營執照之后。

    當然,GFW 的一切行為都是黑箱,我們都只能猜測到底發生了什麼。

    對於大公司來說,直接使用跨境專線,通過中國電信和中國聯通的正規路徑出海,也是一個不錯的選擇,貴是貴了點。


    參考文件:中國的防火長城是如何檢測和封鎖完全加密流量的 – https://gfw.report/publications/usenixsecurity23/zh/