Reconstrução do blog e resolução do problema de falha na comunicação TCP do Starlink para o ConoHa VPS
Olá, aqui é o Munou.
Faz tempo que não atualizo. Na verdade, parte dos artigos do final de 2025 sumiu, e é por isso que estou aqui agora.
Codex
Recentemente comecei a usar o Codex e a experiência de desenvolvimento tem sido tão boa que estou completamente viciado.
Por isso, usei o Codex para rearquitetar o blog, saindo do Lume CMS, do qual eu andava insatisfeito há algum tempo.
É bom poder escrever em Markdown com SSG, mas como eu acabava atualizando quase tudo pelo navegador, percebi que não fazia sentido me dar ao trabalho de escrever no meu editor habitual, o vim.
Especialmente com as imagens, era um problema e eu não sentia vontade de atualizar o blog de forma simples...
O código está disponível aqui, mas atualmente está cheio de bugs.
GitHub - haturatu/alleycat: cms
Parece que também poderei retomar a manutenção do ViMusic, então comecei a mantê-lo novamente. E, surpreendentemente, quando respondi a alguém no Reddit que estava procurando por um fork, era a mesma pessoa que tinha aberto uma issue no meu repositório.
O mundo é realmente pequeno, não é?
Incapaz de alcançar a rede no ConoHa VPS
E então, de repente, surgiu um problema.
Parece que estava ocorrendo o que chamam de Path MTU Black hole. Foi realmente estranho: comunicações que exigem UDP, como o WireGuard, ou o alcance de servidores DNS funcionavam, mas tudo o que exigia TCP, como SSH ou comunicações HTTP, falhava completamente.
Como o próprio ConoHa VPS é hospedado em FreeBSD, pesquisei e encontrei informações de que o problema poderia ser resolvido usando a função scrub do filtro de pacotes ( pf ) para realizar a normalização dos pacotes. Configurei da seguinte forma:
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
~~~Com isso, tanto o tráfego de entrada quanto o de saída são normalizados, e o tamanho do segmento do pacote passa a ser 1360.
Pontos estranhos
Há uma especulação de que a causa disso seja algum problema no CGNAT da 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 ms
1: 192.168.1.1 1.293 ms
2: 100.64.0.1 53.580 ms asymm 3
3: 172.16.251.26 37.025 ms
4: 206.224.70.208 34.552 ms (roteador incompleto retornou dados corrompidos) asymm 7
5: 206.224.70.184 37.307 ms
6: 210.171.225.229 34.518 ms
7: Sem resposta8: 172.71.4.43 34.303 ms
9: 162.159.109.87 39.922 ms
10: 162.159.109.55 33.535 ms
11: Sem resposta
12: 172.70.165.3 56.395 ms asymm 11
13: 150.95.7.204 46.647 ms asymm 10
14: 150.95.7.139 66.797 ms asymm 11
15: 150.95.7.147 46.542 ms asymm 12
16: Sem resposta
17: Sem resposta
18: Sem respostaPara começar, eu tinha a impressão de que, mesmo que o tamanho do pacote padrão da Starlink e do meu ambiente de rede fosse 1500, a comunicação TCP lidaria com isso adequadamente, mas não entendi por que isso ocorreu de repente este mês entre o ConoHa VPS <-> Starlink.
Se o CGNAT original da Starlink estivesse com problemas, não seria estranho se o problema tivesse ocorrido mais cedo, mas é um fenômeno tão estranho que ainda estou intrigado.