Category: P2P

處理 rTorrent 會卡頓的問題

用 rTorrent 算是很久了，在 CLI 下的 BitTorrent client。

但 rTorrent 一直有卡頓的問題，這個週末決定還是找一下怎麼解，而在 Reddit 上面可以看到討論：「Rtorrent stalling / freezing caused by bad tracker? I fixed my problem but I'm a bit puzzled.」，其中就有提到是 libtorrent 因為 DNS 查詢 blocking 的問題。

不過這邊有些人已經提出了解法，其中一個是使用 libudns 達成 async DNS query 來解決這個問題，這個 branch 有進到官方的 git repository 裡面 (但沒有被 merge 到 master 上)：「rakshasa/libtorrent at slingamn-udns.10」。

看了一下雖然最後 commit 是 2019 年，但其實不算太舊，因為 master 從 2019 年到現在 2023 年也沒幾個 commit，不過直接用 slingamn-udns.10 的 libtorrent 搭最新版的 rtorrent 是編不起來的，主要是因為 IPv6 的支援改變了一些程式的 API 介面。

最後一個可以搭 rtorrent 的版本是 2021 年六月的 582e4e40256b43d3e5322168f1e1ed71ca70ab64，也已經比目前最近的正式 release 0.9.8 (2019/07/19) 還新。

把這些組合弄起來後跑了幾個小時，看起來順不少，暫時沒有遇到卡住的問題了...

Tor 的 Rust 計畫 Arti 推進到 1.0.0 版

在「Arti 1.0.0 is released: Our Rust Tor implementation is ready for production use.」這邊看到 Tor 的 Rust 計畫進入了 1.0.0 版。

不過每次編 Rust 的東西都會發現 Rust 版本不夠新，這次也不例外，就不知道是 Rust community 的特性還是真的太少用 Rust...

    Updating crates.io index
  Downloaded arti v1.0.0
error: failed to parse manifest at `/home/gslin/.cargo/registry/src/github.com-1ecc6299db9ec823/arti-1.0.0/Cargo.toml`

Caused by:
  feature `edition2021` is required

  this Cargo does not support nightly features, but if you
  switch to nightly channel you can add
  `cargo-features = ["edition2021"]` to enable this feature

用 rustup update 更新後就能編了，然後跑起來看起來沒什麼問題：

$ arti proxy -p 9150
2022-09-03T17:13:30.234032Z  INFO arti: Starting Arti 1.0.0 in SOCKS proxy mode on port 9150...
2022-09-03T17:13:30.238606Z  INFO tor_circmgr: We now own the lock on our state files.
2022-09-03T17:13:30.238652Z  INFO tor_dirmgr: Didn't get usable directory from cache.
2022-09-03T17:13:30.238674Z  INFO arti::socks: Listening on 127.0.0.1:9150.
2022-09-03T17:13:30.238686Z  INFO arti::socks: Listening on [::1]:9150.
2022-09-03T17:13:30.238713Z  INFO tor_dirmgr::bootstrap: 1: Looking for a consensus.
2022-09-03T17:13:33.833304Z  INFO tor_dirmgr::bootstrap: 1: Downloading certificates for consensus (we are missing 9/9).
2022-09-03T17:13:34.335754Z  INFO tor_dirmgr::bootstrap: 1: Downloading microdescriptors (we are missing 6629).
2022-09-03T17:13:41.041683Z  INFO tor_dirmgr::state: The current consensus is fresh until 2022-09-03 17:00:00.0 +00:00:00, and valid until 2022-09-03 19:00:00.0 +00:00:00. I've picked 2022-09-03 18:35:38.290798754 +00:00:00 as the earliest time to replace it.
2022-09-03T17:13:41.061978Z  INFO tor_dirmgr: Marked consensus usable.
2022-09-03T17:13:41.065536Z  INFO tor_dirmgr: Directory is complete.
2022-09-03T17:13:41.065557Z  INFO tor_dirmgr: We have enough information to build circuits.
2022-09-03T17:13:41.065564Z  INFO arti: Sufficiently bootstrapped; system SOCKS now functional.

用 curl 測試也的確是 Tor 的 exit node 了：

$ curl -i --socks5 127.0.0.1:9150 https://httpbin.org/ip
HTTP/2 200 
date: Sat, 03 Sep 2022 17:21:20 GMT
content-type: application/json
content-length: 32
server: gunicorn/19.9.0
access-control-allow-origin: *
access-control-allow-credentials: true

{
  "origin": "85.93.218.204"
}

$ host 85.93.218.204
204.218.93.85.in-addr.arpa domain name pointer tor.localhost.lu.

看起來 client 的功能能用了...

Tor 0.4.7.7 支援 congestion control

Tor 首度在協定內支援了 congestion control：「Congestion Control Arrives in Tor 0.4.7-stable!」。

這個新功能會帶來效能的提昇：

Tor has released 0.4.7.7, the first stable Tor release with support for congestion control. Congestion control will eliminate the speed limit of current Tor, as well as reduce latency by minimizing queue lengths at relays. It will result in significant performance improvements in Tor, as well as increased utilization of our network capacity.

之所以沒有辦法直接利用 packet loss 的方式讓 TCP network stack 直接判斷 congestion control，是因為這樣會產生 side channel：

Crucially, we rejected mechanisms to provide congestion control by allowing packet drops, due to the ability to introduce end-to-end side channels in the packet drop pattern.

所以 Tor 得自己實做 congestion control 演算法，選擇的演算法是結合了 Vegas 的 Tor-Vegas，可以看到在實驗中，德國與香港的 exit node 效率大幅提昇：

另外也因為 0.4.7.7 也出來一個禮拜了，也可以看到 Advertised Bandwidth (算是 Tor network 觀察到的 bandwidth) 開始成長：

另外一個重要的點是 UDP 的支援計畫，看起來在這次改善後也比較有可行性了：

The astute reader will note that we rejected datagram transports. However, this does not mean that Tor will never carry UDP traffic. On the contrary, congestion control deployment means that queue delay and latency will be much more stable and predictable. This will enable us to carry UDP without packet drops in the network, and only drop UDP at the edges, when the congestion window becomes full. We are hopeful that this new behavior will match what existing UDP protocols expect, allowing their use over Tor.

把 SQLite 的 VFS 掛上 WebTorrent 的 PoC Demo

在 Hacker News Daily 上看到「Static torrent website with peer-to-peer queries over BitTorrent on 2M records (boredcaveman.xyz)」這個討論，作者試著在網頁上跑 SQLite + VFS + WebTorrent。

這好像是這陣子一連串的 combo 技累積出來的東西：

  • 首先當然是把 SQLite 丟到網頁上跑的「sql.js」，這個專案比較久了，2019 年有第一個 release；
  • 然後最近有人透過 HTTP Range (Byte serving) 實做 SQLite VFS 的「sql.js-httpvfs」，這樣就不需要一次下載整包 SQLite；

接下來就是文章作者把 HTTP Range 換掉，改用 BitTorrent 的 pieces 來處理，在網頁端的話就順勢拿 WebTorrent 來用，對於很熱門的網站來說還蠻有趣的設計，但也可以預期網頁的反應速度應該不會太快，偏 PoC...

使用 Tor 的 .onion 位置，而非透過 Exit Node 存取網站的好處

在「Twitter 的 Tor Onion 位置」與「BBC 這次拿出短波廣播...」這兩篇我都有在懷疑為什麼要提供 Tor 的 .onion 位置，不是直接透過 exit node 連出去就好了嗎，結果今天看到「Why offer an Onion Address rather than just encourage browsing-over-Tor?」這篇在解釋。

對使用者來說，用 .onion 的好處是隱私性會更好，因為 exit node 本身不一定安全，必須透過 HTTPS 保護才有基本的防護，而且就算用了 HTTPS 還是可以從 HTTPS 的 handshake 得到不少資訊。

對網路本身來說，exit node 算是稀缺資源，大多數人可以架 Tor 的 relay node，但沒辦法做 exit node，因為 exit node 的特性會導致常常收到各種警告。因此能用 .onion 位置存取，也會降低對 exit node 的壓力。

另外 CA/Browser 在 2020 的時候就允許發出 .onion 憑證：「讓 Tor 的 .onion 支援 HTTPS」，看起來應該也是多一層保護...

qBittorrent 支援 BitTorrent v2

在「Thursday January 06th 2022 - qBittorrent v4.4.0 release」這邊可以看到 qBittorrent v4.4.0 支援 BitTorrent v2 (BEP 52) 了：

FEATURE: Support for v2 torrents along with libtorrent 2.0.x support (glassez, Chocobo1)

先前在「libtorrent 宣佈支援 BitTorrent v2」這邊有提到過 libtorrent 要支援 BitTorrent v2 的消息，而 qBittorrent 算是 libtorrent 的使用大戶，支援 BitTorrent v2 後會讓 BitTorrent v2 的使用率增加不少。

用了一年多才出現一個比較大的 client 跳進去支援，看起來大家的動力的確不高...

對 Tor 網路的攻擊

在「Is “KAX17” performing de-anonymization Attacks against Tor Users?」這邊看到針對 Tor 網路攻擊的一些說明...

BTCMITM20 這組比較好理解，目標也比較明確：

primary motivation: financial profit (by replacing bitcoin addresses in tor exit traffic)

KAX17 這組看起來就比較像是政府單位在後面掛：

motivation: unknown; plausible: Sybil attack; collection of tor client and/or onion service IP addresses; deanonymization of tor users and/or onion services

其中可以看到同時掌握了不少 hop，這樣就很有機會一路串起來：

To provide a worst-case snapshot, on 2020–09–08 KAX17's overall tor network visibility would allow them to de-anonymize tor users with the following probabilities:

  • first hop probability (guard) : 10.34%
  • second hop probability (middle): 24.33%
  • last hop probability (exit): 4.6%

由於 Tor 是匿名網路，目前最好的防禦方式還是讓更多人參與加入節點，降低單一團體可以取得足夠組出的資料... 之後找機會整理一下跑了一年多 exit node 的想法好了。

用 iptables 擋特定國家的封包

這兩天發現 ubuntu-20.04.3-live-server-amd64.iso 這個 BitTorrent 的 ISO image 有大量來自 CN 的連線在狂抓，導致整個上傳頻寬都被吃滿：

沒想到第一次用 iptables 的 xt_geoip 居然是這個用途... 主要是參考「GeoIP Blocking Ubuntu 20.04LTS」這邊的方法，不過因為我的 rtorrent 是跑在 Docker 裡面的，有另外要注意的地方。

首先是安裝軟體，這邊要裝 xtables-addons-common 與 libtext-csv-xs-perl：

sudo apt install -y libtext-csv-xs-perl xtables-addons-common

再來是建立目錄，並且下載一包 GeoIP 的資料 (從 DBIP 下載) 並且轉成 xt_geoip 可以用的格式：

sudo mkdir /usr/share/xt_geoip
cd /usr/share/xt_geoip
sudo /usr/lib/xtables-addons/xt_geoip_dl
sudo /usr/bin/perl /usr/lib/xtables-addons/xt_geoip_build

然後就是加到 iptables 的條件裡面了，我加到兩個地方，一個是 INPUT chain，另外一個是 DOCKER-USER chain (參考「Docker and iptables」這邊的說明)，假設你是用 port 6991 的話就這樣加：

sudo iptables -I INPUT -p tcp -m geoip --source-country CN -m tcp --dport 6991 -j DROP
sudo iptables -I DOCKER-USER -p tcp -m geoip --source-country CN -m tcp --dport 6991 -j DROP

然後可以考慮每個禮拜更新一次資料庫。

另外在找資料的時候發現「Free updated GeoIP legacy databases」這邊有人放出 MaxMind 的版本，不過免費版的應該都差不多，這邊就用 xtables-addons-common 內預設的。

弄完以後就正常多了...

讓 Tor 的 .onion 支援 HTTPS

看到 Tor 官方的「Get a TLS certificate for your onion site」這篇，查了一下發現先前漏掉一些資訊...

首先是 2020 年二月的時候 CA/Browser Forum 就已經在投票是否有開放 v3 .onion 的憑證：「[Servercert-wg] Voting Begins: Ballot SC27v3: Version 3 Onion Certificates」，而結果也順利通過：「Ballot SC27v3: Version 3 Onion Certificates - CAB Forum」。

而一直到今年才有消息，希臘的 Harica CA 在月初時正式支援 v3 .onion：「Harica CA now supports issuance of DV .onion certificates」，不過拿 SSL Lab 的工具翻了一下，發現不是所有的平台都有認 Harica CA：「SSL Report: www.harica.gr (155.207.1.46)」，裡面可以看到 Java 的 trust store 裡面沒有 Harica CA：

實際測了一下流程，Harica CA 的網站會等到認證完後收費，看起來可以透過信用卡，但我就沒走下去了：

想要看看的人可以看 Kushal Das 的 kushaldas.in 與 kushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion 就可以了。

另外查了一下 Certificate Transparency，可以看到我自己的 onion server 先被簽出來了：「5g4ukauwohjqjpydwqnkfkxxtcxkgtusr5twji53stfdzbz54xrmckid.onion」。

等 Let's Encrypt 出來後再說吧，目前看起來「Support for FQDNs under .onion」這邊沒有什麼進度...

Windows 上包裝 Syncthing 的 SyncTrayzor

在「SyncTrayzor is an open source Syncthing client for Windows」這邊看到有人將 Syncthing 包裝好，讓使用者在 Windows 上直接設定，而不需要另外開瀏覽器設定：

Syncthing is a popular peer-to-peer file sharing/synchronization software. It uses a web GUI which can be a little confusing for beginners. SyncTrayzor is an open source client that makes the P2P tool more user-friendly.

Syncthing 比較特別的觀念就是每一台都要設定允許其他台分享 (通常是這樣)。假設你有四台 Syncthing 要設定，每一台都要設定允許其他三台的分享。

不過也可以有其他的設計，像是你可以在 VPS hosting 上租一台空間很大的機器，然後其他機器都只對 VPS 這台機器同步，這樣就比較像有中央 server 的架構。

對於有多電腦的人還蠻好用的東西...