Reconstrucción del blog y resolución del problema por el cual solo la comunicación TCP no llegaba desde Starlink a ConoHa VPS
Hola, soy Munou.
Ha pasado tiempo desde la última actualización. De hecho, parte de los artículos de finales de 2025 desaparecieron y así estamos ahora.
Codex
Recientemente empecé a usar Codex y la experiencia de desarrollo es tan buena que estoy completamente enganchado.
Por eso, reorganicé la arquitectura del blog pasando de Lume CMS, con el que no estaba satisfecho, a Codex.
Poder escribir en Markdown con un SSG está bien, pero como terminaba actualizando casi todo desde el navegador, me di cuenta de que no tenía sentido usar mi editor habitual, vim, para escribir a propósito.
Especialmente el tema de las imágenes era un problema y no me daban ganas de actualizar el blog fácilmente...
He publicado el código aquí, pero actualmente está lleno de errores.
GitHub - haturatu/alleycat: cms
Parece que también podré retomar el mantenimiento de este, así que he vuelto a ello; y para mi sorpresa, al responder 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?
Pérdida de conectividad de red en ConoHa VPS
Y entonces, surgió un problema de repente.
Al parecer, estaba ocurriendo lo que se conoce como un Path MTU Black hole.
Fue realmente extraño: las comunicaciones que requieren UDP como WireGuard o los servidores DNS funcionaban, pero todo lo relacionado con TCP como SSH o HTTP fallaba por completo.
Como el propio ConoHa VPS está alojado en FreeBSD, investigué y encontré información que decía que el problema se podía solucionar normalizando los paquetes usando la función scrub del filtro de paquetes ( pf ), así que lo configuré de la siguiente manera:
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, se normalizan tanto el tráfico de subida como el de bajada, y el tamaño del segmento del paquete queda en 1360.
Puntos extraños
Existe la sospecha de que la causa de esto sea un mal funcionamiento del CGNAT 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 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 (un router incompleto devolvió datos corruptos) asymm 7
5: 206.224.70.184 37.307 ms
6: 210.171.225.229 34.518 ms
7: sin respuestaPara empezar, tenía la impresión de que, aunque el tamaño de paquete predeterminado de Starlink y de mi entorno de red fuera 1500, la comunicación TCP lo gestionaría adecuadamente, por lo que no entendía por qué esto ocurrió de repente este mes entre ConoHa VPS <-> Starlink.
Si el CGNAT original de Starlink fuera defectuoso, creo que no habría sido extraño que el problema hubiera ocurrido mucho antes, pero es un fenómeno tan extraño que me ha tenido inquieto todo este tiempo.