重新製作部落格與解決從 Starlink 到 ConoHa VPS 僅 TCP 通訊無法到達的問題

4 min

自宅サーバーサーバーfreebsd
language: ja bn en es hi pt ru zh-cn zh-tw

你好，我是無能。

好久沒更新了。或者該說，2025 年後半部分的文章消失了一些，就變成現在這樣了。

Codex

最近開始使用 Codex，開發體驗實在太棒了，完全陷入其中。

因此，我利用 Codex 對一直以來感到不滿意的 Lume CMS 進行了部落格架構重構。

雖然能用 SSG 的 Markdown 撰寫很不錯，但因為大多是透過瀏覽器更新，我才發現到頭來根本沒必要特地用平常慣用的編輯器 vim 來寫。

特別是圖片處理方面的問題，讓我提不起勁輕鬆更新部落格……

程式碼公開在這裡，但目前還滿是 bug。

GitHub - haturatu/alleycat: cms

GitHub - haturatu/ViMusic

似乎也能恢復維護了，所以又開始動手維護；沒想到在 Reddit 回覆尋找 fork 對象的人時，對方竟然是在我的儲存庫（repository）開過 issue 的人。

這世界還真是小呢。

無法連線至 ConoHa VPS 網路

接著，突然發生了問題。

看來是發生了所謂的 Path MTU Black hole。真的很神祕，像 WireGuard 這種需要 UDP 通訊的，或是 DNS 伺服器等都能連上，但需要 TCP 的 SSH 或 HTTP 通訊卻全都掛了。

由於 ConoHa VPS 本身是用 FreeBSD 託管的，查了一下發現，似乎可以利用封包過濾器 ( pf ) 的 scrub 功能進行封包正規化（normalization）來解決問題，於是進行了如下設定：

set skip on lo
set block-policy drop
exsrv1 = dummy
insrv1 = dummy
insrv2 = dummy
wireguard_clients="{ dummy, dummy, dummy }"
wanint="vtnet0"
wg_ports="{51820}"
scrub in on $wanint all random-id max-mss 1360
scrub out on $wanint all random-id max-mss 1360
~~~

這樣一來，上傳和下載都會被正規化，封包的分段大小（segment size）會變成 1360。

神祕的點

關於發生原因，有一種推測是 Starlink 的 CGNAT 出問題了？

$ mtr -T -P 443 -n -r -c 2 163.44.113.145
Start: 2026-02-24T00:13:53+0900
HOST: thepassenger                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%     2    1.4   1.5   1.4   1.6   0.1
  2.|-- 100.64.0.1                 0.0%     2   19.3  19.4  19.3  19.4   0.1
  3.|-- 172.16.251.26              0.0%     2   20.1  23.4  20.1  26.8   4.8
  4.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  5.|-- 206.224.70.186             0.0%     2   25.9  22.3  18.8  25.9   5.0
        206.224.70.182                   
  6.|-- 210.171.225.229            0.0%     2   23.0  22.7  22.4  23.0   0.4
  7.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  8.|-- 172.71.208.15              0.0%     2   24.9  23.1  21.3  24.9   2.5
        162.159.109.42                   
  9.|-- 172.71.4.38                0.0%     2   21.9  23.3  21.9  24.8   2.1
        172.64.212.62                    
 10.|-- 172.71.4.35                0.0%     2   63.3  43.8  24.2  63.3  27.7
        172.70.221.227                   
 11.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 12.|-- 172.70.165.3               0.0%     2   44.7  39.8  35.0  44.7   6.9
 13.|-- 150.95.7.204               0.0%     2   33.4  34.0  33.4  34.6   0.8
 14.|-- 150.95.7.139               0.0%     2   39.2  50.3  39.2  61.4  15.7
 15.|-- 150.95.7.147               0.0%     2   36.6  37.2  36.6  37.9   0.9
 16.|-- 163.44.113.145             0.0%     2   34.2  35.8  34.2  37.5   2.3
$ tracepath -n -m 30 163.44.113.145
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.1.1                                           1.347 毫秒 
 1:  192.168.1.1                                           1.293 毫秒 
 2:  100.64.0.1                                           53.580 毫秒 asymm  3 
 3:  172.16.251.26                                        37.025 毫秒 
 4:  206.224.70.208                                       34.552 毫秒 (不完整的路由器回傳了損壞的資料) asymm  7 
 5:  206.224.70.184                                       37.307 毫秒 
 6:  210.171.225.229                                      34.518 毫秒 
 7:  無回應
8: 172.71.4.43 34.303 毫秒 9: 162.159.109.87 39.922 毫秒 10: 162.159.109.55 33.535 毫秒 11: 無回應 12: 172.70.165.3 56.395 毫秒 asymm 11 13: 150.95.7.204 46.647 毫秒 asymm 10 14: 150.95.7.139 66.797 毫秒 asymm 11 15: 150.95.7.147 46.542 毫秒 asymm 12 16: 無回應 17: 無回應 18: 無回應

原本的印象是，即便 Starlink 和我家網路環境的預設封包大小是 1500，TCP 通訊也會自動處理妥當，但我不明白為什麼這件事會在這個月突然發生在 ConoHa VPS <-> Starlink 之間。

如果原本 Starlink 的 CGNAT 有問題，按理說應該更早就會發生才對，但這現象實在太過不可思議，讓我一直感到很困惑。

Related Posts