SSH vs Cloudflare Tunnel vs Pangolin vs Tailscale vs Headscale vs WireGuard, qué uso para qué

El último mes han pasado por mi compose y por mi ~/.ssh/config seis cosas distintas que un lector de fuera podría confundir entre sí. cloudflared abriendo túnel desde el VPS, Pangolin en cola para el home lab, Tailscale en el portátil para llegar a un servidor de pruebas sin tocar el router, una conexión SSH que rebota por dos hosts hasta un contenedor, y WireGuard como pieza base que sostiene a la mitad de las anteriores. Todas hacen "túneles", todas dan acceso a algo que no estaba expuesto, y por eso es fácil pensar que una sustituye a la otra. No es así.

Esta entrega es el árbol de decisión que tengo en la cabeza para no acabar con seis cosas haciendo lo mismo. Voy una a una, diciendo cuándo me sirve cada herramienta y cuándo no.

Tres familias, no seis alternativas

Lo primero que me ayudó a ordenar el lío fue darme cuenta de que no son seis opciones del mismo nivel, son tres familias con dos o tres miembros cada una.

• Publicar un servicio HTTP a Internet con identidad delante. Aquí viven Cloudflare Tunnel + Access y Pangolin. La pregunta es "quiero abrir panel.midominio.com al mundo, pero solo entran identidades que yo apruebo".
• Mesh privada entre mis dispositivos. Aquí viven Tailscale, Headscale y WireGuard puro. La pregunta es "quiero que mi portátil hable con mi Raspberry como si estuvieran en la misma LAN, sin abrir nada al exterior y sin publicar dominio público para esa conversación".
• Conexión ad-hoc para ingeniería y operación. SSH tunnels. La pregunta es "quiero, durante diez minutos, mover un puerto de un sitio a otro para depurar algo".

Cuando alguien dice "voy a montarme un túnel" hay que preguntar antes para qué, porque la respuesta cambia toda la elección. Confundir las familias es lo que lleva a montar un Tailscale donde sobraba un SSH, o un Cloudflare Tunnel donde lo correcto era simplemente meter un firewall delante.

SSH tunnels, la herramienta más vieja que sigo abriendo a diario

Suelen quedar fuera de las comparativas modernas, como si fueran cosa del 2010, pero ssh -L sigue siendo lo primero que abro varias veces al día. No para tener el panel del home lab fuera, para mover un puerto puntual.

Las tres formas que uso de verdad.

• Local forward (ssh -L). Llevo el puerto remoto a mi localhost. Es lo que hago cuando quiero conectar Drizzle Studio al SQLite del VPS sin exponerlo a Internet, ssh -L 5433:localhost:5432 vps y trabajo desde el portátil con la BD remota como si fuera local.
• Remote forward (ssh -R). Saco un puerto local a través del VPS. Lo usé alguna vez para enseñar un dev server a otra persona sin desplegar nada, ssh -R 8080:localhost:3000 vps y la otra persona apunta a la URL pública del VPS.
• ProxyJump (ssh -J). Salto desde la máquina A a la C pasando por B. Mi ~/.ssh/config tiene un host con ProxyJump dokploy que apunta a un contenedor interno del orquestador, así puedo entrar al shell de un servicio sin que el contenedor tenga puerto SSH propio. El día que aprendí ProxyJump dejé de hacer ese baile feo de "abre dos terminales, en una ssh al VPS, y desde ahí ssh al servicio".

El SSH tunnel tiene una cosa que ninguno de los otros tiene, cero servidor de control. Si dos máquinas se hablan por SSH ya tienes túnel. No hay coordinación, no hay relay, no hay base de datos detrás. Por eso sigue siendo perfecto para tareas de ingeniería puntuales. Y por eso falla en cuanto quieres dárselo a usuarios que no son ingenieros, porque montar SSH en el portátil de un familiar para que pueda ver la cámara del salón no es razonable.

Un detalle operativo. Si tienes autossh y un service unit, puedes mantener un SSH tunnel arriba como si fuera una mesh permanente. He visto setups así. Funcionan, pero son frágiles, y cuando se complican (varios destinos, varios saltos, reconexión con backoff) acaban siendo una mesh hecha a mano con la pieza equivocada.

Cloudflare Tunnel con Access, lo que tengo en producción

La migración de los paneles admin del VPS a CF Tunnel + Access ya tiene su propia entrega. Aquí solo el resumen de cuándo es la respuesta correcta y cuándo no.

Cuándo elegir CF Tunnel + Access.

• Quieres publicar HTTP/HTTPS a Internet con identidad delante.
• El servicio ya vive (o puede vivir) detrás de un dominio en Cloudflare.
• Necesitas cero esfuerzo operativo, no quieres mantener un control plane propio.
• Te encajan las políticas de Access (Allow + email, OIDC, SAML) y, sobre todo, los Bypass para webhooks externos.
• Estás bien con que CF termine TLS en su edge y que los bytes pasen por un tercero en el camino.

Cuándo no es la pieza adecuada.

• El tráfico es íntimo y no quieres que circule por la edge de un proveedor externo, aunque ese proveedor no lo lea.
• Necesitas exponer protocolos no HTTP nativamente (RTSP, MQTT plano, SSH, SMB). Spectrum lo cubre, pero ya no es la solución sencilla que era para los paneles.
• Quieres acceso peer-to-peer entre dos dispositivos tuyos detrás de NATs distintos sin publicar dominio público para esa conversación.

Pangolin, la versión self-hosted del mismo modelo

Lo cuento aparte en otra entrega, así que aquí solo lo justo. La idea es la misma que CF Tunnel + Access (cero puerto abierto en el origen, identidad antes del primer byte), pero en una VPS que controlo yo. Newt en el origen abre la conexión saliente, Gerbil hace de servidor WireGuard en la VPS pública, Traefik sirve los recursos con Let's Encrypt automático, Pangolin es el plano de control con dashboard y auth.

Cuándo me encaja Pangolin sobre CF Tunnel.

• Tráfico personal, ese que no quiero que circule por la edge de un proveedor.
• Mezcla de protocolos, HTTP y TCP plano sobre la misma pieza sin pasar por planes de pago.
• No quiero acoplar todo el setup a una cuenta de Cloudflare que también lleva el blog, las APIs públicas y el correo.
• Acepto pagar 5 a 10 € de VPS al mes y mantener una pieza más actualizada.

Si quitas la última, CF gana en operativa diaria. Por eso reparto, paneles admin del trabajo en CF, home lab personal en Pangolin.

Tailscale, la mesh privada que "simplemente funciona"

Aquí cambia la familia. Tailscale no publica un dominio al mundo, no termina TLS pública, no es un reverse proxy. Es una mesh VPN, una red virtual privada en la que cualquier dispositivo donde instales el cliente queda en la misma "LAN virtual" que los demás, identificada por un nombre estable y una IP del rango 100.x.x.x.

Por dentro es WireGuard, eso es importante para entender por qué es rápida (kernel WireGuard cuando se puede, user-space si no) y por qué es fácil de auditar (no inventa criptografía propia). Tailscale aporta la capa que WireGuard no tiene, una pieza que llaman control plane que coordina las claves públicas de cada nodo, mantiene un mapa de quién es quién, y empuja los endpoints dinámicos (las IPs cambiantes y los puertos NAT) para que los nodos se descubran sin tocar el router. Cuando dos nodos no consiguen hablarse directamente porque hay NATs simétricos por medio, el tráfico pasa por un relay DERP que Tailscale opera, y para el usuario eso es transparente, "el ping va, todo va".

Lo que de verdad lo hace cómodo en el día a día son tres cosas más.

• MagicDNS, cada nodo es alcanzable por su nombre (raspberry, nas) sin tocar resolver.
• ACLs en HuJSON, declaras qué nodos pueden hablar con qué otros y por qué puerto, en un fichero que se versiona como código.
• Subnet router, un nodo cualquiera puede anunciar la ruta de toda una LAN dentro de la mesh, así expones la red de casa entera con un solo Tailscale corriendo.

El plan personal es generoso (hasta 100 dispositivos y 3 usuarios gratis, con MagicDNS, ACLs y exit nodes incluidos), por eso es la herramienta por defecto para "quiero llegar a esa Raspberry desde mi portátil" sin pensar más.

Lo que pierdes al elegir Tailscale es lo mismo que ganabas, dependes del control plane de Tailscale. Tus claves privadas no salen del nodo (eso se mantiene), pero el mapa de quién es quién sí pasa por sus servidores. Para mí en uso personal no es un problema, para quien sea más estricto en soberanía sí lo es.

Headscale, el control plane que controlo yo

Headscale es una reimplementación open source del control plane de Tailscale. Lo importante de la frase es que los clientes oficiales de Tailscale (el del Mac, el del móvil, el de Windows, el de Linux) hablan contra Headscale igual que contra Tailscale, basta con apuntar al endpoint propio. Es decir, te quedas con la UX pulida del cliente y mueves el control plane a una máquina tuya.

Cuándo elegir Headscale sobre Tailscale.

• Quieres mesh con la UX de Tailscale pero sin que la coordinación pase por un tercero.
• El equipo es grande y el plan gratis de Tailscale ya no llega.
• Tienes una política interna que dice "todo el plano de control en infraestructura propia".

El coste real de Headscale es operativo. Tienes que mantener un control plane sano (con su backup, su monitoreo, su renovación de TLS), y si quieres relays propios para los nodos que no hablan directos tienes que montar tu propio DERP. Para una persona en su casa, Tailscale gana en simple. Para una organización con criterios de soberanía, Headscale gana en control.

Una cosa que no siempre se cuenta. Si te quedas con DERPs públicos de Tailscale aunque uses Headscale (es la opción más rápida de arrancar), parte del beneficio de "yo controlo todo" se diluye. El handshake va por tu Headscale pero el tráfico de fallback puede pasar por sus relays. Para soberanía completa, DERP propio.

WireGuard puro, la pieza que sostiene a casi todo lo demás

Pangolin (Newt + Gerbil), Tailscale y Headscale usan WireGuard por debajo. Si lo entiendes, entiendes el 80% de lo que hacen las tres.

WireGuard solo es muy poco. Una clave privada por nodo, una clave pública por peer, un fichero wg0.conf en cada extremo con la lista de peers permitidos y sus IPs internas. Los peers se hablan por el puerto que les digas (51820 por convención), por encima de UDP, con criptografía moderna y código pequeño.

Lo que WireGuard no resuelve es exactamente lo que las herramientas de arriba añaden por encima.

• NAT traversal. WireGuard no perfora NAT por sí solo, espera que cada peer sea alcanzable. Si los dos nodos están detrás de NAT, mala suerte. Tailscale y Headscale ponen DERP, Pangolin pone su VPS pública como concentrador.
• Discovery dinámico. WireGuard no sabe que la IP de tu portátil cambió porque te has movido al café. Hay que actualizar Endpoint a mano. Las herramientas de arriba lo hacen por ti, manteniendo el mapa actualizado.
• Identidad y rotación. WireGuard no tiene concepto de "usuario", solo "peer". Si quieres revocar a alguien, le borras la clave del fichero de todos los demás. Manual.
• UI y logging. Cero. Lo que tienes es wg show y los logs del kernel.

Cuándo uso WireGuard puro a pelo. Cuando son dos máquinas concretas, las dos con IP pública estable, y no me apetece añadir control plane. Túnel directo entre dos VPS, por ejemplo, para meter una BD réplica detrás del peering privado sin pagar VPC. Para tres nodos ya prefiero Tailscale, para cinco ni me lo planteo.

El árbol de decisión que llevo en la cabeza

Convertido en preguntas, en este orden.

1. ¿Es para diez minutos, mover un puerto y cerrar? SSH tunnel, ya sea local forward, remote forward o ProxyJump según el caso.
2. ¿Quiero un dominio público X.midominio.com con un servicio HTTP detrás y una identidad delante? Sí, y acepto que el tráfico pase por la edge de un tercero, Cloudflare Tunnel + Access. Sí, pero quiero todo el camino del dato bajo mi control, Pangolin.
3. ¿Quiero acceso privado entre mis propios dispositivos sin publicar nada al exterior? Sí, con un control plane gestionado, Tailscale. Sí, con control plane mío, Headscale.
4. ¿Son solo dos máquinas con IP estable y no necesito ni control plane ni mesh? WireGuard puro.

El error que veo más a menudo en gente que llega de fuera es saltarse el primer paso. "Quiero entrar al panel del NAS desde el móvil" termina como "monté Tailscale en seis dispositivos" cuando muchas veces lo que quería era literalmente ssh -L esos cinco minutos al mes.

Lo que descarté antes de elegir

Para no dar la lista incompleta, lo que pensé y descarté.

• ZeroTier. Conceptualmente parecido a Tailscale, mesh con control plane gestionado. Se puede self-hostear pero la documentación está menos cuidada. Tailscale ha ganado la batalla del mindshare en este nicho y no veo razón para nadar contracorriente.
• Twingate. Producto comercial bonito que apunta más a empresas. Para un setup personal no compensa el precio ni el lock-in.
• Nebula (de Slack). Mesh propia con su propio CA, no usa WireGuard. Buena pieza pero la curva está más cerca de "infra de empresa" que de "home lab los sábados".
• OpenVPN. Sigue funcionando, pero después de probar WireGuard nadie en sus cabales vuelve a OpenVPN para casos nuevos. Lento, pesado, configuración que es prácticamente otro lenguaje.
• Cloudflare WARP en modo private network. CF tiene un equivalente al modelo Tailscale (clientes WARP que se conectan al edge y de ahí entran a tu Tunnel privado). Es elegante, pero sigue dependiendo de Cloudflare y, para mi caso de "no quiero que CF vea mi tráfico personal", no resuelve nada.

Lo que sigue

El reparto que tengo decidido es el siguiente. Paneles admin del VPS por CF Tunnel + Access, ya en producción. Home lab por Pangolin, en plan inminente. Acceso peer-to-peer entre mis dispositivos por Tailscale, ya en uso. Operación puntual por SSH tunnels y ProxyJump, todos los días. Headscale y WireGuard puro están en el cajón de "lo saco si vuelvo a tener un caso que los pida". El error que voy a vigilar de cerca es que cuando tenga Pangolin en marcha, la tentación de tirar Tailscale será grande, y conviene parar y recordar que cada uno resuelve un problema distinto, no son sustitutos.