拿 WireGuard 當作 SOCKS5 Proxy 的用戶端

pufferffish/wireproxyHacker News 上看到「Wireproxy: WireGuard client that exposes itself as a HTTP/SOCKS5 proxy (github.com/pufferffish)」這個有趣的東西,GitHub 上的專案頁在 pufferffish/wireproxy 這邊:

A wireguard client that exposes itself as a socks5/http proxy or tunnels.

不需要連上完整版本的 WireGuard VPN,而是透過 proxy 協定讓使用者可以使用,這樣配合瀏覽器的工具 (像是 SwitchyOmega) 可以很方便的設定各種變化,像是針對日本限定的網站走日本的 VPS instance 出去。

另外值得一提的是,這是一個 userland 而且不需要 root 權限的實作;這點蠻容易可以理解的,只是聽一個 TCP port 然後用 WireGuard protocol 跟遠端溝通,的確是不需要 root 權限。

另外在 Hacker News 的留言裡面還看到了 aramperes/onetun 這個工具,看起來是 server 端的實作,支援 TCP 與 UDP:

A cross-platform, user-space WireGuard port-forwarder that requires no root-access or system network configurations.

這兩個看起來剛好可以搭在一起...?

測 IPv4 NAT VPS,以及架設 HTTPS Proxy

因為 AWS 開始收 Public IPv4 address 費用的關係 (而且頗貴,參考「AWS 將開始收取 IPv4 的 Public IP 費用」),我把其中一台主機改成只有 IPv6 address 後遇到不少問題 (在「把 AWS 上的 EC2 instance 改成 IPv6-only」這邊)。

由於有 proxy 的需求,剛好找機會玩一下 IPv4 NAT VPS... 這種 VPS 最基本的大概就是會給一個 IPv4 address 上 non-standard port 當作 SSH port,讓你可以連進去管理;另外通常會給 port forwarding 的功能,而且是固定不能換的,讓你可以開一些 port 出來用。

我的用途是 IPv6 address 的 proxy,所以要找有給固定的 IPv6 address 的,另外希望跑在日本,這樣其他用途也比較方便。

過年期間翻了一下找到 NAT VPS,有 256MB 跑個 proxy 類的應用應該還 OK,實際上是 256MB RAM + 64MB swap 的 OpenVZ 類環境,kernel 有到 5.2.0 還算堪用,上面可以選 Ubuntu 22.04 安裝。

費用的部分 US$7/year 還行,網路上是有看到 128MB RAM 的 機器,但這樣連裝東西都綁手綁腳的,太容易 OOM。

(剛拿到機器的時候還試著裝 Percona Server for MySQL,結果就 OOM 跑不完 setup 的流程,看起來得自己改設定混過去,但只是想確認 256MB RAM + 64MB swap 可以弄到什麼程度,就反安裝了...)

在上面把想測的東西測試完後,實際的 proxy 設定比較簡單... 先設定一個只有 IPv6 address 的 domain 申請 Let's Encrypt 的 SSL certificate,然後掛給 Squid 用。

然後在 IPv6-only 的機器上用 curl -v --proxy https://username:password@proxy-jp.example.com:12345/ https://home.gslin.org/robots.txt 確認沒問題後就可以把服務都掛過去。

有些服務會吃環境變數 HTTP_PROXYHTTPS_PROXY,有些是在設定檔內設定,基本上都是照著文件設就可以了。

我遇到的 application & library 都可以吃 HTTPS Proxy 協定,就沒什麼大問題... 如果有遇到不行的,也可以考慮在 Squid 裡面直接放行特定的 IPv6 address。

捷克政府宣布 2032/06/06 政府網站將停用 IPv4 服務

看到「Czech republic sets IPv4 end date (konecipv4.cz)」這篇,捷克政府公告了政府網站將在 2032/06/06 停用 IPv4 服務:「Czech republic sets IPv4 end date」。

On 17 January 2024, the Government of the Czech Republic approved the material "Restarting the implementation of DNSSEC and IPv6 technologies in the state administration". On the basis of this decision, the Czech state administration will stop providing its services over IPv4 on 6 June 2032. Thus, the Czech Republic knows its IPv4 shutdown date.

剛好昨天在試著將手上 AWSEC2 instance 拔掉 IPv4 address (因為 2024/02/01 開始收費,參考先前寫的「AWS 將開始收取 IPv4 的 Public IP 費用」),結果還是遇到相依服務還沒有上 IPv6 endpoint 的問題,如果要轉移的話得開 DNS64NAT64,但因為目前就只有兩台小機器在 AWS 上,在上面租 NAT64 或是自己架 NAT64 的費用反而比付 IPv4 address 的費用還貴,就先暫時丟著了。

我這邊遇到的問題是 api.slack.com 目前只有 IPv4 address,這邊因為是走 HTTPS,也許可以靠其他在有 IPv6 address 的 VPS 上的 proxy server 解決 (我剛好有租一些 VPS instance),這幾天再來看看怎麼弄...

穿越 Firewall 的作法

先看到「SSH over HTTPS (trofi.github.io)」這篇,原文「SSH over HTTPS」講怎麼利用 HTTPS 加上 CONNECT 指令穿過去。

作者有先介紹背景,他需要在醫院待個幾天,而醫院有免費的 WiFi 可以上網,但限制很多,基本上 TCP 的部分只有 80/tcp 與 443/tcp 會通,另外他有行動網路可以用 (但應該不是吃到飽的?),可以當作在現場直接設定 bypass 機制的工具:

I planned to spend 1-2 days in the hospital and did not plan to use the laptop.But now I am stuck here for the past two weeks and would like to tinker on small stuff remotely. The hospital has free Wi-fi access.

The caveat is that hospital blocks most connection types. It allows you only to do HTTP (TCP port 80) and HTTPS (TCP port 443) connections for most hosts. DNS (UDP port 53) and DoT (TCP port 853) seem to work as well at least for well-known DNS providers.

But SSH (TCP port 22 or most other custom ports) is blocked completely.

I wondered how hard would it be to pass SSH through HTTP or HTTPS. I had a GSM fallback so I could reconfigure remote server and try various solutions.

作者的方法就是在 TLS/SSL connection 上面跑 SSH,以前幹過,但就如同 comment 裡面提到的,Cisco 的 AnyConnect (主要是用 open-source client 的 OpenConnect 以及 open-source server 的 ocserv) 比較彈性,而且 AnyConnect 的協定會自動嘗試 UDP-based 的 DTLS,傳輸效率會比 TCP-based 的協定好,另外在 iOS 上可以直接裝 app store 裡面 Cisco 官方的 client 來用。

但從作者的其他文章看起來應該也是熟門熟路了,會這樣做應該是手上有 HTTPS 的 apache server 可以設定來用。

另外作者雖然沒寫出來,但想法應該是有 SSH 就可以在 command line 透過 -D 生出 SOCKS 服務當 proxy 讓其他程式使用,常見的應用程式大多都支援。

應該就是臨時要在醫院裡面待個一兩天時的暫時性方案,如果常態會遇到的話應該是會架 ocserv 來繞...

Trino Gateway

先前一直有在追蹤 TrinoHA 方案:「High Availability #391」,昨天看到有人更新消息,提到 Trino Gateway 這個專案,以及九月底的時候的公告:「Trino Gateway has arrived」。

主要是從 Presto Gateway 整理出來的:

The release is the result of many, many months of effort to move the legacy Presto Gateway to Trino, start a refactor of the project, and add numerous new features.

原始的 Presto Gateway 專案上面也已經標示後續請大家去看 Trino Gateway:

NOTE: This is a legacy version of Trino Gateway. Please refer to https://github.com/trinodb/trino-gateway for active development and updates moving forward.

然後 Release notes 這邊可以看到前幾天又出一個新版了,看起來是有能量在專案上的。

從「Design」這頁可以看到軟體本身分成 BaseApp、ProxyServer 與 Gateway 三個部分,架構面上可以看得出來是 Proxy 架構。

從「References」這頁可以看到一些組織使用前身 Presto Gateway 的心得:

目前應該會需要一些時間,把積在 backlog 的功能開發出來。之後如果還有遇到 Trino 的話可以拿出來重新研究發展到什麼地方...

用 bubblewrap (bwrap) 針對特定程式抽換 /etc/resolv.conf

我家裡的桌機有兩個有線網路,一個是 HiNet 光世代,另外一個是社區網路 (其實出去也是光世代),像是這篇提到的架構 (只是當時還住在後山埤,另外那條是北都的第四台網路):「Ubuntu 下面搞 Multi-home 架構」。

我在上面那篇提到要怎麼以 source ip address 來決定 routing,然後我就可以跑 Squid,並且在 Squid 上面指定 source ip 來達到目標。

後來有做了一些改變,最主要是換成 microsocks

一個原因個是 Squid 比較「重」(heavy),microsocks 比較清量;第二個是 Squid 走的 CONNECT 支援的程式比較少,SOCKS 支援度高一些。

不過當 HiNet 線路有問題的時候,會發現 DNS 的查詢失敗,主要的原因是 microsocks 會讀 /etc/resolv.conf 的資料,裡面是 168.95.192.1168.95.1.1,而且 microsocks 呼叫的 getaddrinfo() 沒有 IP binding,還是會試著走原來的線路出去。

所以這邊就得想辦法把 /etc/resolv.conf 換成我們自己加工的版本,這邊我用了 bubblewrap 來做:

/usr/bin/bwrap --unshare-all --share-net --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind ~/microsocks/resolv.conf /etc/resolv.conf /usr/sbin/microsocks -i 0.0.0.0 -p 11080 -b 192.168.2.123

先把所有東西都隔開 (--unshare-all),再把網路開通 (--share-net),接著把 /usr/lib 以及 /lib64 掛上來 (因為 microsocks 需要這些 library),然後 /etc 下的東西只掛了一個自己建的 /etc/resolv.conf 上來,裡面指到 router 上 (我的 router 有 DNS proxy):

nameserver 192.168.2.254

這邊因為是 subnet traffic,自動選定的 source ip 會是本機 192.168.2.x 的 IP,就剛好避開這個問題,這樣無論 HiNet 線路的情況都不會影響到 microsocks 了。

這邊有個小插曲,因為追問題所以用 strace 看了半天才發現一開始我用 bubblewrap 時是這樣寫:

/usr/bin/bwrap --bind / / --bind ~/microsocks/resolv.conf /etc/resolv.conf /usr/sbin/microsocks -i 0.0.0.0 -p 11080 -b 192.168.2.123

結果發現 microsocks 第一次讀 /etc/resolv.conf 的時候的確是讀到 ~/microsocks/resolv.conf,但網路斷掉後 (/etc/resolv.conf 會被改動) 他會讀到原始的 /etc/resolv.conf (i.e. 沒有被替換掉),判讀 strace log 到這邊的時候差點罵出來... @_@

沒有往下追的太細,但猜測可能是 --bind / /--bind ~/microsocks/resolv.conf /etc/resolv.conf 有處理上的衝突?總之我後來改成 --unshare-all,再把要掛的東西掛上去,就沒這個問題了...

ISP 偽造出合法的 SSL certificate,對放在德國的 xmpp.ru 進行 MITM 監聽

標題有點複雜,先講一下 http-01 認證,這是目前 Let's Encrypt 上最常被使用的認證方式,是透過 HTTP 協定完成認證,你只要能回答 http://www.example.com/.well-known/acme-challenge/XXX 的內容就能過。

一般來說,這個 HTTP 位置只有這台伺服器的 owner 才有辦法提供,也就能確保不是任何人都可以申請。

但因為這邊走的是 HTTP,對於 ISP 這種比較特別的身分來說,他可以從中架設 HTTP 的 MITM Proxy 做到這件事情。

而有了合法的 SSL certificate 之後,中間的 MITM Proxy 就不只能聽 HTTP 了,還可以聽 HTTPS 的內容 (甚至修改內容)。

這次發生的事情就是在德國的 LinodeHetzner 機房內的服務,俄羅斯最大的 XMPP 服務 xmpp.ru 被搞出這件事情 (XMPP 是一個開放協定,不熟的話可以想像成類似 Line 或是 Telegram 的服務,但 XMPP 是開放協定,可以用自己喜歡的軟體連上):「Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service」。

他們在 Hetzner 的伺服器上有發現 network offline 的訊號:

[Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down
[Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

而在這個 network offline 的時間不久後 Let's Encrypt 發出了 xmpp.ru 與 jabber.ru 的 SSL certificate (crt.sh 上可以查到,在 99976947049997621208):

18 July 2023 issuing time is about the same when Hetzner server has lost network link for several seconds.

這些徵兆符合改接到 MITM Proxy 上的行為。

這次的事情很大條,因為這些伺服器是在德國,不是在俄羅斯... 事情才剛開始被報導出來,後續得繼續追蹤,而且應該也會促成新的機制被引入?

Tailscale Funnel 公開測試

去年 11 月的時候寫過 Tailscale Funnel 的消息:「Tailscale 也推出類似 Cloudflare Tunnel 的產品,Tailscale Funnel」,剛剛則是宣佈公開測試:「Tailscale Funnel now available in beta」。

測了一下,設定不算太難,但有些步驟要做:

  • 在網頁上先允許 Access Controls 內的 Funnel。
  • 然後允許 DNS 內的 HTTPS Certificates。
  • 剩下就是照著文件跑,在本地跑對應的指令。

他的想法是把 *.ts.net 這個網域拿出來 internet 上面用,但他希望 Let's Encrypt 簽的 SSL key 應該要放在本地端,而不是讓 Tailscale 看到內容。

但同樣也考慮到使用者的體驗,Tailscale 不需要使用者自己處理 SSL certificate 一堆事情,而是實做在 tailscaled 這隻程式裡面,讓本地端的程式還是走 HTTP 而非 HTTPS。

對應的,使用者如果想要取得對應的 key 與 cert,也可以透過 tailscale cert 指令取得。

測了一下位置,HiNet 的使用者會透過東京的節點轉進來,拿來跑測試開發機應該是夠用。

以他的用法來說,跟 Cloudflare Funnel 的定位不太一樣,反倒是擠壓 ngrok 這類服務。

Etsy 使用 Vitess 的過程

Etsy 寫了三偏關於使用 Vitess 解決資料庫效能問題的文章:「Scaling Etsy Payments with Vitess: Part 1 – The Data Model」、「Scaling Etsy Payments with Vitess: Part 2 – The “Seamless” Migration」、「Scaling Etsy Payments with Vitess: Part 3 – Reducing Cutover Risk」。

Vitess 是 YouTube 團隊開發出來的東西,試著透過一層 proxy 解決後端 MySQL 資料庫在 sharding 後查詢邏輯的問題。

有一些地方的資訊整理出來:

首先是現代暴力解的能耐,從維基百科可以查到 Etsy 在 2015 年就上市了,但到了 2020 年年底撞到 vertically scaling 的天花板 (這邊是指 GCP 的上限),可以看到現在的暴力法可以撐超久... 如果再多考慮到實體機房的話應該可以找到更大台的機器。

第二個是 Etsy 在 2020 年年底開始從資料庫搬資料,一路到 2022 年五月,算起來差不多搬了一年半,總共轉移了 4 個 database 到 Vitess 的 cluster 上,共 23 張表格與 40B rows。

第三個是利用 Vindexes 這個技術降低 sharding 時所帶來的限制。這個之前沒研究過:

A Vindex provides a way to map a column value to a keyspace ID.

從「Older Version Docs」這邊翻舊版的文件,發現 5.0+ 都有,再往 GitHub 上面的資料翻,看起來從 2016 年的版本就有了,不過當時看起來還一直在擴充:「Vitess v2.0.0-rc.1」。

回來看現在的功能,有 primary vindex 的設計:

The Primary Vindex for a table is analogous to a database primary key. Every sharded table must have one defined. A Primary Vindex must be unique: given an input value, it must produce a single keyspace ID.

然後是 secondary vindex(es) 的設計,指到 keyspace id(s),然後這個資訊會被用在 routing 上:

Secondary Vindexes are additional vindexes against other columns of a table offering optimizations for WHERE clauses that do not use the Primary Vindex. Secondary Vindexes return a single or a limited set of keyspace IDs which will allow VTGate to only target shards where the relevant data is present. In the absence of a Secondary Vindex, VTGate would have to send the query to all shards (called a scatter query).

It is important to note that Secondary Vindexes are only used for making routing decisions. The underlying database shards will most likely need traditional indexes on those same columns, to allow efficient retrieval from the table on the underlying MySQL instances.

然後是 functional vindex 與 lookup vindex,前者用演算法定義 keyspace id,後者讓你查:

A Functional Vindex is a vindex where the column value to keyspace ID mapping is pre-established, typically through an algorithmic function. In contrast, a Lookup Vindex is a vindex that provides the ability to create an association between a value and a keyspace ID, and recall it later when needed. Lookup Vindexes are sometimes also informally referred to as cross-shard indexes.

然後 lookup vindex 還有對 consistent hashing 的支援:

Consistent lookup vindexes use an alternate approach that makes use of careful locking and transaction sequences to guarantee consistency without using 2PC. This gives the best of both worlds, with the benefit of a consistent cross-shard vindex without paying the price of 2PC. To read more about what makes a consistent lookup vindex different from a standard lookup vindex read our consistent lookup vindexes design documentation.

這樣整體看起來,Vitess 把所有常見的 sharding 方式都包進去了,如果以後真的遇到這個量的話,也不需要自己在 application 或是 library 做一堆事情了...

Tailscale 也推出類似 Cloudflare Tunnel 的產品,Tailscale Funnel

Tailscale 也推出了類似 Cloudflare Tunnel 的產品,叫做 Tailscale Funnel:「Introducing Tailscale Funnel」。

都是透過 server 本身主動連到 Cloudflare 或是 Tailscale 的伺服器上,接著外部的 request 就可以繞進來了。

不過 Tailscale Funnel 的定位跟 Cloudflare Tunnel 有些差異,看起來 Tailscale Funnel 比較偏向給 dev/stage 環境的用法,Cloudflare Tunnel 像是要跑在 production 的設計?

目前是 alpha 階段,有些限制,像是目前能開的 port:

The ports you can specify to expose your servers on are currently to 443, 8443 and 10000.

另外從技術面上看起來一定得用 TLS 連線,因為他得透過 TLS 的 SNI 資訊來決定是誰:

We can only see the source IP and port, the SNI name, and the number of bytes passing through.

對於已經有用 Tailscale 的使用者來說好像可以玩看看,但另外一點是 Cloudflare 的機房密度很高,這點可能是 Tailscale 也要想一下的問題?