El problema clásico: tu preview corre en localhost y nadie más puede verla
Tienes un draft de un post, una demo de producto o un webhook en localhost:8080 y necesitas que otra persona lo abra desde su navegador. La opción cómoda es abrir una cuenta en ngrok o en Cloudflare Quick Tunnels y listo, pero ambos pasan tu tráfico por infraestructura de terceros. La opción incómoda pero más barata y privada es montártelo tú mismo con OpenSSH y Nginx, y eso es exactamente lo que Vincent Bernat explica en un tutorial publicado esta semana.
El enfoque encaja con una tendencia que TechTargetdocumentó a partir de presentaciones de Red Hat Summit: las empresas están reevaluando el coste real de confiar toda su infraestructura a proveedores externos. Una encuesta de Omdia recogida en ese artículo señala que el 18% de las organizaciones ya ejecuta cargas de IA on-prem para recortar costes, y casi la mitad de los 400 encuestados usa modelos open source. Para una startup, "autoalojado" ya no es postureo: es una decisión de coste mes a mes.
¿Qué es un túnel HTTP autoalojado y para qué sirve?
Un túnel HTTP es, en esencia, una forma de exponer un puerto que solo escucha en tu máquina (localhost) hacia una URL pública en internet. El caso de uso típico de la guía de Bernat es compartir un preview efímero con un revisor externo sin desplegar todavía el entorno. Otros casos frecuentes:
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad- Mostrarle un webhook en desarrollo a un partner para que apunte su servicio a tu endpoint real.
- Probar un flujo de OAuth que requiere una URL pública con callback.
- Validar integraciones con APIs que solo hablan con HTTPS y dominios concretos.
- Compartir un staging temporal con un cliente sin levantar infraestructura nueva.
La base: SSH remote port forwarding sin instalar nada nuevo
El primer paso es lo que la propia guía llama "setup básico". Con un único comando expones tu puerto local en un servidor remoto que ya controlas:
ssh -N -R 0:localhost:8080 web02.luffy.cx
El -R 0:localhost:8080 le pide al servidor que elija un puerto libre (el 0) y lo reenvíe a tu localhost:8080. Lo interesante es que no necesitas instalar nada en el servidor: solo OpenSSH, que ya está en cualquier Linux, BSD o macOS. El servidor remoto asigna un puerto efímero y lo publica, y tu sesión SSH mantiene la conexión viva mientras se usa el túnel.
Según la documentación de SSH que recoge TechTarget, este mecanismo se llama remote port forwarding y existe desde hace décadas: el cliente abre un puerto en el servidor y todo el tráfico que llegue ahí se redirige a la máquina del cliente. Es la misma capacidad que las empresas usan para exponer bases de datos internas de forma segura, pero aplicada a un caso mucho más ligero.
El truco de Nginx: un server_name que extrae el puerto del subdominio
Aquí es donde la solución pasa de "túnel SSH" a "túneles HTTPS con URL limpia". El bloque de servidor de Nginx usa una expresión regular en server_name para capturar el número de puerto del propio subdominio:
server_name ~^p(?<port>\d\d\d\d\d)\.ssh\.luffy\.cx$;
Luego un proxy_pass http://127.0.0.1:$port; reenvía la petición al puerto local que el túnel SSH está exponiendo. Para que esto funcione necesitas tres cosas extra que el artículo detalla:
- Un certificado wildcard para
*.ssh.tudominio.comemitido por Let's Encrypt mediante el challenge DNS-01. - Un registro DNS
CNAMEque apunte el wildcard a tu servidor de túneles. - Una zona DNS auxiliar (en el ejemplo,
acme.luffy.cxen Route 53) que centralice los challenges DNS-01.
El bloque de Nginx se queda en menos de 15 líneas para enrutar cualquier subdominio pPUERTO.ssh.tudominio.com hacia el puerto correspondiente, lo que evita tener que recargar la configuración cada vez que abres un túnel nuevo.
El talón de Aquiles: el puerto es el único secreto
La guía lo dice sin rodeos: tal como está, "el puerto es el único secreto" que mantiene el contenido confidencial. Si alguien enumera puertos en tu subdominio wildcard, entra. Para resolverlo, Bernat añade el módulo ngx_http_secure_link_module de Nginx.
La idea es elegante: el cliente envía un hash temporal codificado en base64 dentro del nombre de usuario de una autenticación HTTP Basic, junto a un timestamp de expiración. Nginx calcula el hash esperado con secure_link_md5 "$secure_link_expires $port TU_SECRETO" y compara. Si no coincide, devuelve 401 con WWW-Authenticate. Si coincide pero expiró, devuelve 410 Gone. Si todo está bien, proxy_pass como antes.
El comando para generar el token es un pipe de una línea con openssl md5, openssl base64 y dos tr para adaptar el alfabeto:
printf '%s %s %s' "$expires" "$port" "$secret" | openssl md5 -binary | openssl base64 | tr +/ -_ | tr -d =
Resultado: una URL del estilo https://[email protected]/ que caduca a las 24 horas, imposible de adivinar y sin necesidad de base de datos de tokens en el servidor.
El script que ahorra los últimos 10 minutos de pelea
El problema práctico restante es que OpenSSH no expone en ninguna variable de entorno el puerto efímero que acaba de asignar. Bernat lo resuelve buscando en la cadena de procesos padre hasta dar con el sshd-session y leyendo sus puertos en escucha con ss --listening --processes. El script completo:
- Recorre el árbol de PIDs hasta localizar el
sshd-sessionque originó tu sesión. - Saca los puertos que ese proceso tiene abiertos con
ssejecutado víasudo -n. - Para cada puerto genera un token con el hash correspondiente y la expiración configurada.
- Imprime las URLs finales y entra en
sleep infinitypara mantener la sesión SSH viva.
En su forma final, configurar ~/.ssh/config con un bloque Host http-over-ssh que use RemoteCommand http-over-ssh reduce todo a un único comando: ejecutas ssh http-over-ssh y recibes en pantalla las URLs listas para compartir.
¿Qué significa esto para tu startup?
La decisión de autoalojar infraestructura no es solo filosófica. Como recogió TechTarget citando el caso de BNP Paribas en Red Hat Summit, mover cargas del cloud público a tu propio hardware puede rebajar el TCO a largo plazo, aunque calcularlo con precisión sea "difícil de comunicar" según su propio arquitecto técnico, Pascal Guerineau. En el otro extremo, el lanzamiento de Kimi K3 documentado por TechTimes recordó que self-hostear modelos frontera exige más de 1,4 TB de memoria de GPU, algo que está fuera del alcance de la mayoría de equipos. La moraleja: el autoalojamiento tiene un punto dulce claro para cargas pequeñas y recurrentes, y deja de tenerlo cuando la escala dispara la complejidad operativa.
Acciones concretas que puedes aplicar esta semana:
- Audita qué servicios de tunneling usas hoy (ngrok, Cloudflare Quick Tunnels, VS Code Dev Tunnels). Para cada uno, calcula el coste mensual y el dato que estás enviando a un tercero: aunque sea un preview, ese tráfico es producción para tu cliente.
- Reserva un subdominio
*.tun.tudominio.comy un wildcard de Let's Encrypt vía DNS-01. Es la pieza que más cuesta montar la primera vez y la que más se reutiliza después. - Copia el script
http-over-ssh.shy versiona tuhttp-over-ssh.nixo equivalente en el repo de infra. La próxima vez que un cofundador, un diseñador o un cliente pida ver algo en local, el flujo es un solossh http-over-ssh.
Fuentes
- Self-hosted HTTP tunnels with SSH and Nginx (fuente original)
- IT orgs face tricky cost calculus for self-hosted AI inference — TechTarget
- What is SSH (Secure Shell) and How Does It Work? — TechTarget
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
