Reconstrução do blog e a resolução do problema de não conseguir alcançar apenas a comunicação TCP do Starlink para o ConoHa VPS

6 min

language: ja bn en es hi pt ru zh-cn zh-tw

Olá, sou um inútil.

Faz tempo que não atualizo. Na verdade, alguns artigos do segundo semestre de 2025 foram perdidos e cheguei até aqui.

Codex

Recentemente, comecei a usar Codex e a experiência de desenvolvimento é tão boa que estou completamente viciado.

Por isso, reestruturei meu blog, usando Codex a partir do Lume CMS, do qual eu estava insatisfeito.

É bom poder escrever em Markdown para SSG, mas como eu atualizava principalmente pelo navegador, acabei percebendo que não fazia sentido escrever especificamente no vim, meu editor de uso diário.

Especialmente com as imagens sendo um problema, não me sentia motivado a atualizar o blog facilmente...

O código está publicado aqui, mas atualmente está cheio de bugs.

GitHub - haturatu/alleycat: cms

GitHub - haturatu/ViMusic

Parece que a manutenção também pode ser retomada, então comecei a mantê-lo novamente, e, inesperadamente, quando respondi a alguém no Reddit que estava procurando um fork, era a mesma pessoa que havia aberto um issue no meu repositório.

O mundo é realmente pequeno.

Impossibilidade de alcançar a rede no ConoHa VPS

Então, um problema surgiu de repente.

Aparentemente, estava ocorrendo um Path MTU Black hole. Foi realmente estranho, pois conseguia alcançar coisas que exigem comunicação UDP, como WireGuard e servidores DNS, mas todas as comunicações TCP, como SSH e HTTP, falhavam.

Como o próprio ConoHa VPS é hospedado em FreeBSD, ao pesquisar, vi informações de que o problema poderia ser resolvido normalizando os pacotes usando a função scrub do filtro de pacotes (pf), e 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 se torna 1360.

Ponto Estranho

Há uma especulação de que a causa disso poderia ser um problema com o CGNAT do 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.347ms 
 1:  192.168.1.1                                           1.293ms 
 2:  100.64.0.1                                           53.580ms asymm  3 
 3:  172.16.251.26                                        37.025ms 
 4:  206.224.70.208                                       34.552ms (Roteador incompleto retornou dados corrompidos) asymm  7 
 5:  206.224.70.184                                       37.307ms 
 6:  210.171.225.229                                      34.518ms 
 7:  Sem resposta
 8:  172.71.4.43                                          34.303ms 
 9:  162.159.109.87                                       39.922ms 
10:  162.159.109.55                                       33.535ms 
11:  Sem resposta
12:  172.70.165.3                                         56.395ms asymm 11 
13:  150.95.7.204                                         46.647ms asymm 10 
14:  150.95.7.139                                         66.797ms asymm 11 
15:  150.95.7.147                                         46.542ms asymm 12 
16:  Sem resposta
17:  Sem resposta
18:  Sem resposta

Originalmente, mesmo que o tamanho do pacote padrão do Starlink e do meu ambiente de rede fosse 1500, eu tinha a impressão de que a comunicação TCP estava funcionando bem, mas não entendi por que isso de repente aconteceu este mês entre o ConoHa VPS <-> Starlink.

Se o CGNAT original do Starlink estivesse com problemas, não seria estranho que o problema tivesse ocorrido muito antes, mas é um fenômeno tão estranho que me deixa intrigado o tempo todo.

Related Posts