Переделка блога и решение проблемы с недоступностью TCP-трафика от Starlink до ConoHa VPS
Привет, я Munou.
Давно не было обновлений. Точнее, часть статей за вторую половину 2025 года куда-то пропала, и вот мы здесь.
Codex
Недавно я начал использовать Codex, и опыт разработки оказался настолько крутым, что я полностью в это погрузился.
Поэтому я переделал архитектуру блога, перейдя с Lume CMS, которой был вечно недоволен, на Codex.
Возможность писать на Markdown в SSG — это здорово, но так как я почти всё обновлял через браузер, я понял, что нет особого смысла специально использовать vim, мой привычный редактор.
Особенно мешали проблемы с изображениями, из-за чего пропадало всякое желание обновлять блог...
Код опубликован здесь, но на данный момент он полон багов.
GitHub - haturatu/alleycat: cms
Похоже, я смогу возобновить поддержку этого проекта, так что снова взялся за него. И надо же, когда я ответил на Reddit человеку, искавшему форк, оказалось, что это тот самый пользователь, который создавал issue в моем репозитории.
Мир всё-таки тесен.
Потеря сетевой доступности к ConoHa VPS
И тут внезапно возникла проблема.
Судя по всему, произошла так называемая Path MTU Black hole. Это было очень странно: сервисы, использующие UDP, такие как WireGuard или DNS-серверы, были доступны, но всё, что требовало TCP (например, SSH или HTTP), полностью отвалилось.
Так как сам ConoHa VPS работает на FreeBSD, я начал искать решение и наткнулся на информацию, что проблему можно исправить с помощью нормализации пакетов через функцию scrub в пакетном фильтре ( pf ). Я настроил это следующим образом:
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
~~~Теперь и входящий, и исходящий трафик нормализуются, а размер сегмента пакета (MSS) устанавливается в 1360.
Странный момент
Есть предположение, что причиной этого является некорректная работа CGNAT у Starlink.
$ 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: нет ответаВообще говоря, у меня было впечатление, что даже если размер пакета по умолчанию для Starlink и моей сетевой среды составляет 1500, в TCP-трафике всё обрабатывается должным образом, поэтому я не понимал, почему это внезапно произошло в этом месяце между ConoHa VPS <-> Starlink.
Если бы изначально что-то было не так с CGNAT у Starlink, было бы логично, если бы проблема возникла раньше, но это настолько странное явление, что я до сих пор в некотором замешательстве.