Cuando un desarrollador necesita HTTPS en su equipo o que un servicio externo llegue a su portátil, suele mezclar dos problemas distintos: conseguir que el navegador confíe en un sitio local, que se resuelve con certificados y almacén de confianza, y permitir que internet alcance una máquina detrás de un router, que exige un túnel o un servidor intermedio. Confundirlos lleva a abrir túneles públicos cuando solo hacía falta un certificado, y un túnel es, ante todo, una vía de entrada a la red que a menudo no tiene ninguna autenticación delante.
Las claves de HTTPS local y túneles en 30 segundos
- Que el navegador confíe en tu web local se arregla con mkcert, Caddy o Let’s Encrypt por DNS-01, sin túneles.
- Que internet llegue a tu equipo exige un túnel: SSH, frp, zrok o sish son opciones libres y autoalojables.
- Cloudflare Tunnel, Tailscale Funnel y ngrok dependen de un servicio de terceros.
- Todo túnel publica un puerto interno: hay que limitarlo, autenticarlo y cerrarlo al terminar.
- Instalar una CA de desarrollo da a quien tenga su clave poder para suplantar cualquier dominio en ese equipo.
Antes de instalar nada conviene hacerse una pregunta: ¿necesito que el navegador confíe en mí o que internet llegue hasta mí? La respuesta decide la herramienta. A continuación repasamos las principales, empezando por las de código abierto y autoalojables, y con los riesgos de seguridad de cada una.
Problema 1: HTTPS de confianza sin abrir nada
mkcert (código abierto, licencia BSD) crea una autoridad de certificación (CA) de desarrollo, la instala en los almacenes de confianza del sistema y del navegador y emite certificados con ella: mkcert -install y después mkcert dev.local localhost 127.0.0.1. Es la forma más rápida de quitar los avisos del navegador y de tener un contexto seguro, necesario para muchas API web. Su límite es de alcance: la CA solo es de confianza donde se ejecutó la instalación. Y su riesgo es serio: quien obtenga el archivo rootCA-key.pem puede emitir certificados que ese equipo aceptará para cualquier dominio, incluido el de un banco. Nunca debe compartirse ni copiarse a otros equipos.
Caddy (Apache 2.0) incluye una CA interna, de modo que un archivo de configuración con un nombre y un reverse_proxy localhost:3000 basta para servir una aplicación local por HTTPS sin gestionar certificados a mano. Tiene la misma frontera de confianza que mkcert, y añade un proxy inverso que quizá no se necesite.
OpenSSL (Apache 2.0) es el camino manual y merece la pena recorrerlo una vez, porque es lo que automatizan los demás. Con openssl req -x509 se genera una clave y un certificado autofirmado. La lección importante es la extensión subjectAltName: los navegadores actuales rechazan los certificados que no la incluyen, porque ya no usan el Common Name para comprobar el nombre del servidor. Un certificado autofirmado enseña el formato, pero no la confianza: el navegador seguirá quejándose.
Let’s Encrypt con el desafío DNS-01, por ejemplo con Certbot (Apache 2.0), es la respuesta cuando se quiere un certificado público real en un servidor interno al que internet no puede llegar. El desafío HTTP-01 necesita una conexión entrante, pero DNS-01 demuestra el control del dominio publicando un registro TXT, sin abrir nada. El riesgo está en la credencial: la máquina que renueva necesita un token de la API del DNS, y uno que pueda editar toda la zona es peligroso en un equipo interno. Lo prudente es delegar _acme-challenge mediante un registro CNAME a una zona aparte con permisos limitados.
Problema 2: que internet llegue a tu equipo, con herramientas libres
El reenvío remoto de puertos de OpenSSH no necesita instalar nada si ya se tiene un servidor: ssh -NT -R 8080:localhost:3000 usuario@servidor. Según la documentación de OpenSSH, el puerto remoto escucha por defecto solo en la interfaz de bucle local del servidor, y para escuchar en otra dirección hace falta la opción GatewayPorts, cuyo valor por defecto es no. Ponerla en yes expone el puerto a todo el mundo; es preferible clientspecified o mantenerlo en local detrás de un proxy inverso con autenticación.
frp (Apache 2.0) es la opción autoalojada más completa: frps en un VPS propio y frpc en el portátil, con proxies HTTP, HTTPS, TCP y UDP y publicaciones frecuentes. El extremo público es tuyo, sin intermediarios, pero también lo es la responsabilidad: hay que configurar auth.token en ambos lados, declarar solo los proxies necesarios y proteger el panel de frps, que queda expuesto como cualquier otro servicio del VPS.
zrok (Apache 2.0), construido sobre la red de confianza cero OpenZiti, permite compartir servicios de forma pública o privada por HTTP, TCP y UDP, y puede autoalojarse o usarse como servicio. Sus comparticiones privadas, en las que solo otro usuario de zrok puede acceder, son una buena forma de evitar dejar algo abierto a todo internet.
sish (MIT) es una alternativa a ngrok basada solo en SSH, con túneles HTTP(S), WebSocket y TCP. bore (MIT), escrito en Rust, es un túnel TCP mínimo que se puede leer en una tarde; su servidor debe arrancarse siempre con --secret para no convertirse en un relé abierto, y no ofrece TLS ni enrutado por nombre. Para entornos con autenticación integrada existe también Pangolin, una alternativa autoalojada a Cloudflare Tunnel con edición comunitaria bajo AGPL-3.
Servicios gestionados: cómodos, pero con un tercero en medio
Cloudflare Tunnel usa el demonio cloudflared, de código abierto, que abre una conexión saliente hacia la red de Cloudflare; las peticiones llegan al borde y bajan por ella, sin redirigir puertos. Que la conexión sea saliente no significa que sea segura: el nombre publicado es accesible por defecto sin autenticación, así que conviene poner delante una política de Cloudflare Access y terminar la configuración con una regla final http_status:404 para no exponer más de lo previsto.
Tailscale Serve y Funnel separan bien las audiencias: Serve publica un servicio solo dentro de la red privada de Tailscale, y Funnel lo abre a internet en los puertos 443, 8443 y 10000. El cliente es de código abierto y existe Headscale como servidor de control libre, aunque Funnel depende de la infraestructura de Tailscale. El riesgo habitual es olvidarse un Funnel encendido; tailscale funnel status ayuda a revisarlo.
ngrok, software propietario, sigue siendo el más conocido y destaca por su inspector local, que registra cada petición con cabeceras y cuerpo y permite repetirla, muy útil para depurar webhooks. Su plan gratuito tiene límites que cambian con frecuencia. La URL es pública desde que aparece en pantalla y la página intermedia del plan gratuito no es un control de acceso.
Una advertencia sobre localtunnel: aparece en muchas guías antiguas, pero su código lleva años sin cambios sustanciales, y no es recomendable confiar conexiones de internet a un software sin mantenimiento. En cualquier caso, ninguna de estas herramientas es una forma de saltarse controles de red ajenos: si hay un cortafuegos corporativo de por medio, la solución pasa por el equipo que lo gestiona.
Preguntas frecuentes
¿Necesito un túnel para tener HTTPS en local?
No. Para que el navegador confíe en un sitio local bastan mkcert o Caddy. Un túnel solo hace falta si un servicio externo tiene que llegar a tu equipo.
¿Qué alternativas libres hay a ngrok?
frp, zrok, sish y bore son de código abierto y autoalojables. También sirve el reenvío remoto de puertos de SSH si ya se tiene un servidor.
¿Es seguro Cloudflare Tunnel?
Evita abrir puertos, pero el nombre publicado es accesible sin autenticación por defecto. Conviene protegerlo con Cloudflare Access y eliminar el túnel al terminar.
¿Cómo consigo un certificado real para un servidor interno?
Con Let’s Encrypt y el desafío DNS-01, que valida el dominio con un registro TXT sin necesitar conexiones entrantes.
Fuentes:
