Reconstrucción del blog y solución al problema de que solo la comunicación TCP no puede llegar de Starlink a ConoHa VPS
Hola, soy un inútil.
Ha pasado un tiempo desde la última actualización. De hecho, algunas de las publicaciones de la segunda mitad de 2025 se perdieron y aquí estamos.
Codex
Recientemente, empecé a usar Codex y la experiencia de desarrollo es tan buena que estoy completamente enganchado.
Por eso, rearquitecturé mi blog usando Codex, dejando atrás el 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 escribirlo específicamente en mi editor habitual, vim.
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
Parece que también podré reanudar el mantenimiento de esto, 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 realmente pequeño.
Imposibilidad de alcanzar ConoHa VPS por red
Y así, de repente surgió un problema.
Parece que estaba ocurriendo un Path MTU Black hole. Fue realmente extraño; podía alcanzar cosas que requieren comunicación UDP como WireGuard y servidores DNS, pero todas las comunicaciones TCP como SSH y HTTP fallaban.
Dado que ConoHa VPS está alojado en FreeBSD, investigué y encontré información de que el problema podía resolverse normalizando los paquetes usando la función scrub del filtro de paquetes (pf), y 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, tanto el tráfico de subida como el de bajada se normalizan, y el tamaño del segmento de los paquetes será de 1360.
Punto misterioso
Se especula que la causa de esto es que el CGNAT de Starlink podría estar funcionando mal.
$ 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 (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 respuesta
8: 172.71.4.43 34.303 ms
9: 162.159.109.87 39.922 ms
10: 162.159.109.55 33.535 ms
11: sin respuesta
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: sin respuesta
17: sin respuesta
18: sin respuestaOriginalmente, aunque el tamaño de paquete predeterminado de Starlink y mi entorno de red era 1500, tenía la impresión de que la comunicación TCP lo manejaba bien, pero no entendía por qué esto ocurrió de repente este mes entre ConoHa VPS <-> Starlink.
Si el CGNAT original de Starlink estuviera 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.