重新搭建博客以及解决从 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 版本的人时，发现对方竟然是在我仓库里提过 issue 的人。

这世界还真是小啊。

ConoHa VPS 变得无法访问网络

接着，突然出了问题。

似乎是发生了 Path MTU Black hole 问题。真的很奇怪，像 WireGuard 这种需要 UDP 通信的，或者 DNS 服务器之类的都能访问，但需要 TCP 的 SSH 和 HTTP 通信全都挂了。

由于 ConoHa VPS 本身是托管在 FreeBSD 上的，查了一下发现，似乎可以通过数据包过滤器 ( pf ) 的 scrub 功能进行数据包规范化来解决问题，于是进行了如下设置：

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
~~~

这样一来，上行和下行都会被规范化，数据包的分段大小将变为 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