Saltar al contenido

← Volver a proyectos

Private

louzt/quic-tunnel

Período: jun 2024 —

Active

El reto

Mis sesiones SSH al VPS se caían aproximadamente cada hora en los carriers mexicanos. La inspección de tráfico del carrier estaba matcheando fingerprints comunes de SSH y haciendo shaping de la conexión a mitad de sesión. El tooling estándar de SSH no me daba visibilidad sobre qué transporte se estaba shappeando, y un túnel de un solo transporte es un único punto de fallo.

Mi rol

Diseñé y entregué un demonio de fallback de transporte en capas que escoge el mejor camino disponible al conectar y degrada por tiers sucesivos cuando uno falla. El demonio es la capa de transporte sobre la que corre mi bridge loust-vps.

Lo que hice

  1. 01

    Cadena de transporte en cinco tiers

    Por qué: Cada tier tiene propiedades de fingerprint distintas, así que cuando uno es matcheado y shappeado el siguiente tiene una firma diferente. La cadena va por transportes sucesivamente más livianos hasta que uno sobrevive.

    Trade-off: Más superficie de código y más partes móviles que un túnel de un solo transporte. La alternativa eran caídas horarias, así que la superficie extra es el precio de la fiabilidad.

  2. 02

    CA pinning de extremo a extremo

    Por qué: Un ataque de downgrade podría re-enrutar mi sesión a un endpoint controlado por un atacante. Pinning el CA en ambos extremos hace que la sesión rechace cualquier peer que no esté en la allow-list.

    Trade-off: El setup de un peer es una ceremonia de cinco minutos en lugar de un minuto. El costo de setup es un precio único por una sesión que no puede ser redirigida silenciosamente.

  3. 03

    Migración de conexión para tránsito hostil

    Por qué: Cuando un middlebox interrumpe una conexión a mitad de sesión, el túnel se re-establece en un camino fresco sin soltar el trabajo en vuelo. La sesión sigue viva durante la interrupción.

    Trade-off: Añade unos diez milisegundos de latencia en el primer reconnect. Ahorra los treinta y tantos segundos de reconnect manual que solía gastar en cada caída.

Lo que cambió

  • Supervivencia de sesión

    Antes: Caídas cada hora aproximadamente en carriers mexicanos

    Después: Doce o más horas de sesiones continuas

    Evidencia: Telemetría del bridge loust-vps, 2026-Q3

  • Tiempo de reconnect tras caída

    Antes: 30+ segundos, manual

    Después: Menos de 1 segundo, automático

  • Tiempo de setup de un peer nuevo

    Antes: 1 minuto

    Después: 5 minutos (ceremonia de CA pin)

    Evidencia: estimado, no medido

Trade-offs

El demonio es privado porque el orden de los tiers y las reglas de fingerprinting están tuneadas para mis propios carriers. Publicar el orden de las reglas daría un roadmap a cualquiera que esté sondeando mi transporte; los patrones generalizan, la configuración no.

Lo que aprendí

Endurecer transporte está más cerca de plomería que de criptografía — son los detalles operativos aburridos los que determinan si un sistema sigue arriba a las 3am, no la astucia del handshake.

Stack

  • Go
  • QUIC
  • Hysteria2
  • TLS
  • SSH

← Volver a proyectos · curated 2026-09-20