Reconstrucción del blog y solución al problema de la inaccesibilidad de la comunicación TCP desde Starlink a ConoHa VPS

6 min

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

Hola, soy el inútil.

Ha pasado mucho tiempo desde la última actualización. De hecho, algunas publicaciones de la segunda mitad de 2025 desaparecieron y así llegamos a esto.

Codex

Recientemente, he empezado a usar Codex y la experiencia de desarrollo es tan buena que me he sumergido completamente en ello.

Por eso, he re-arquitecturado mi blog usando Codex, dejando atrás Lume CMS, con el que siempre estuve insatisfecho.

Poder escribir en Markdown para SSG está bien, pero como la mayoría de las veces actualizaba desde el navegador, me di cuenta de que no tenía sentido usar mi editor habitual, vim, para ello.

Especialmente los problemas con las imágenes me quitaban las ganas de actualizar el blog fácilmente...

El código está publicado aquí, pero actualmente está lleno de errores.

GitHub - haturatu/alleycat: cms

GitHub - haturatu/ViMusic

También parece que podré reanudar el mantenimiento, así que he vuelto a empezar a mantenerlo. Y, sorprendentemente, cuando respondí a alguien en Reddit que buscaba un fork, ¡resultó ser la misma persona que había abierto un issue en mi repositorio!

El mundo es un pañuelo, ¿verdad?

Inaccesibilidad de la red a ConoHa VPS

Y así, de repente, surgió un problema.

Parece que se estaba produciendo un fenómeno llamado Path MTU Black hole. Fue realmente extraño: podía alcanzar cosas que requerían comunicación UDP, como WireGuard o servidores DNS, pero todo lo que requería TCP, como SSH o comunicaciones HTTP, fallaba por completo.

Dado que ConoHa VPS está alojado en FreeBSD, investigué y encontré información de que el problema podría resolverse normalizando los paquetes usando la función scrub del filtro de paquetes (pf), así que configuré lo siguiente:

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

Con esto, tanto el tráfico de subida como el de bajada se normalizan, y el tamaño del segmento de paquete se establece en 1360.

Puntos extraños

Existe la especulación de que la causa de esto podría ser un CGNAT defectuoso de 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:  応答なし
 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:  応答なし

En primer lugar, aunque el tamaño de paquete predeterminado de Starlink y de mi entorno de red era de 1500, tenía la impresión de que la comunicación TCP se gestionaba bien, pero no entendía por qué esto ocurrió de repente este mes entre ConoHa VPS <-> Starlink.

Si el CGNAT original de Starlink fuera defectuoso, no sería extraño que el problema hubiera surgido mucho antes, pero es un fenómeno tan extraño que me tiene perplejo.

Related Posts