Escritorio remoto sin reenvío de puertos, explicado

Hace cinco años, configurar escritorio remoto sin reenvío de puertos era un problema de investigación. Tenías que entrar al router, abrir TCP 3389 (o el puerto que usara tu herramienta), rezar para que tu ISP no lo bloqueara y exponer un servidor RDP a Internet pública; por eso casi la mitad de los incidentes de ransomware en 2023 entraron por RDP expuesto a Internet, según Sophos. Hoy, casi todas las herramientas de escritorio remoto de consumo han dejado atrás el reenvío de puertos por completo. Este artículo explica cómo, cuáles son los compromisos y cómo Tenvo maneja cada modo de falla que probablemente te encuentres.

TL;DR: Los clientes modernos de escritorio remoto usan un servidor de rendezvous para poner en contacto a dos extremos y luego intentan UDP hole punching para una conexión directa peer-to-peer. Si el hole punching falla —como ocurre con NAT simétrico, CGNAT y algunos firewalls corporativos—, recurren a un relay. En ningún caso necesitas tocar tu router.

Por qué el reenvío de puertos es un problema en 2026

El reenvío de puertos tenía sentido en 2005. La mayoría de usuarios tenía una sola capa NAT (su router doméstico), IPv4 público era barato y los ISP no interferían. Ninguna de esas suposiciones se mantiene hoy.

• CGNAT (Carrier-Grade NAT): La mayoría de operadores móviles y un número creciente de ISP de fibra ponen a miles de clientes detrás de una misma IP pública. No puedes reenviar un puerto que no te pertenece. T-Mobile Home Internet, Starlink residencial y la mayoría de hotspots celulares usan CGNAT por defecto.
• Doble NAT: Los gateways provistos por ISP a menudo ejecutan su propio NAT delante de tu router, dejándote detrás de dos capas. El reenvío en el router interno no sirve de nada.
• Firewalls corporativos: Políticas de solo salidas. No vas a lograr que tu departamento de TI abra el 3389 entrante para tu laptop.
• Transiciones a IPv6: Algunas redes son solo IPv6 con NAT64; el concepto de reenvío de puertos en IPv4 deja de aplicar.
• Seguridad: Incluso cuando puedes reenviar un puerto, no deberías. El escaneo por fuerza bruta de RDP es ruido de fondo constante en Internet; Shodan indexa alrededor de 4 millones de endpoints RDP expuestos en cualquier momento.

Cómo la traversía de NAT reemplazó el reenvío de puertos

La técnica se llama NAT traversal, y se estandarizó en el stack WebRTC que usa todo navegador en llamadas de video. Las herramientas de escritorio remoto toman las mismas primitivas.

Paso 1: rendezvous vía el servidor de ID

Cuando lanzas Tenvo, el cliente abre una conexión saliente persistente a nuestro servidor de ID (llamado hbbs en la base de código upstream de RustDesk). Es una conexión TCP/UDP saliente normal, que cualquier NAT y firewall permite. El servidor de ID aprende tu ID de dispositivo, tu IP pública reflejada y el puerto de origen que te asignó el NAT. Hace esto para todos los clientes conectados.

Cuando ingresas el ID de otra persona y haces clic en Conectar, tu cliente pregunta al servidor de ID: "¿Dónde está el dispositivo 123 456 789?" El servidor responde con el endpoint público de ese dispositivo y les pide a ambos extremos empezar a punchear simultáneamente.

Paso 2: UDP hole punching

Ambos clientes envían ahora paquetes UDP al endpoint público del otro al mismo tiempo. La mayoría de NATs son endpoint-independent: una vez que enviaste un paquete a cualquier dirección externa, el NAT deja pasar cualquier respuesta por ese mismo puerto. Cuando ambos extremos punchéan simultáneamente, cada NAT interpreta el paquete entrante como una respuesta legítima a uno saliente y lo deja pasar. Se forma una conexión peer-to-peer directa y tu tráfico no pasa por ninguna infraestructura de Tenvo.

Esto funciona en alrededor del 85% de los emparejamientos de NAT de consumo según nuestra medición sin telemetría (probamos en los 50 ISP más comunes en EU + US en marzo de 2026). Es el mismo mecanismo detrás de Tailscale, el descubrimiento de endpoints de WireGuard y todas las llamadas de Zoom.

Paso 3: respaldo por relay (estilo TURN)

El hole punching falla cuando al menos un lado ejecuta un NAT simétrico, un NAT que elige un puerto externo distinto según el destino. CGNAT suele ser simétrico. El Wi‑Fi de hoteles frecuentemente también lo es. Cuando la P2P directa falla tras un timeout de 3 segundos, ambos clientes se reconectan a través de nuestro relay (llamado hbbr en upstream). El relay reenvía bytes entre ambos lados sobre TLS. Sé claro sobre lo que eso implica: TLS termina en el relay, así que, a diferencia de una conexión peer-to-peer directa, una sesión relayed no es de extremo a extremo entre tus dos dispositivos. Si eso importa en tu modelo de amenazas, ejecuta tu propio relay.

El relay añade latencia (típicamente 15-40 ms en nuestros PoPs de EU y US) y compartes ancho de banda con otras sesiones relayed, pero funciona detrás de cualquier topología NAT que permita tráfico saliente similar a HTTPS.

El árbol de decisión de la conexión

Cómo se compara esto con otros enfoques

VPNs (WireGuard, Tailscale, Twingate)

Las VPNs resuelven el mismo problema en otra capa: colocan ambos endpoints en una red privada virtual para que cualquier protocolo funcione entre ellos. Tailscale usa específicamente las mismas técnicas de NAT traversal descritas arriba para su mallado. La desventaja es que tienes ahora un segundo software que instalar, gestionar y mantener actualizado, y estás enrutando todo el tráfico hacia la máquina remota, no solo la sesión de escritorio remoto. Para un caso de uso específico (controlar un PC remoto), una herramienta con NAT traversal integrado es más simple.

RDP con reenvío de puertos

RDP nativo de Windows requiere que reenvíes TCP 3389 (o otro puerto si lo remapeas) desde tu router hacia la máquina objetivo. Esto funciona en una red doméstica con NAT simple, requiere IP pública estática o DNS dinámico, te expone al escaneo global por fuerza bruta de RDP y deja de funcionar si tu ISP te migra a CGNAT. La recomendación de Microsoft es poner RDP detrás de un Remote Desktop Gateway o Azure Bastion, ambos esencialmente relays.

AnyDesk y TeamViewer

Ambos también usan rendezvous + hole punching + relay fallback. La arquitectura es, en términos generales, la misma que la de Tenvo. Diferencias: AnyDesk y TeamViewer ejecutan protocolos propietarios en clientes de código cerrado, sus relays no pueden ser autoalojados y sus precios reflejan el costo operativo de mantener infraestructura de relays global para millones de usuarios. Tenvo está construido sobre el fork open-source de RustDesk, así que el protocolo es auditable y el relay puede autoalojarse si quieres control total.

Configuración en tres pasos

El punto de la NAT traversal es que no hay nada que configurar. Aquí está la configuración real en Windows:

# 1. Download (no admin required for the portable build)
Invoke-WebRequest https://tenvoai.com/download/godesk-windows-x64.exe -OutFile godesk.exe

# 2. Launch, generates a 9-digit ID and a one-time password
.\godesk.exe

# 3. On the controlling machine, enter the ID and password. Connected.

No hay cambios en el router. No hay reglas de firewall. No hay IP estática. El mismo flujo funciona en macOS (DMG), Linux (deb/rpm/AppImage) y Android (APK o Play Store). Para desplegar en muchas máquinas, consulta nuestra guía de plataforma Windows para instalación silenciosa basada en MSI.

Cuándo aún podrías querer reenvío de puertos

Dos casos límite:

• LAN air-gapped sin acceso a Internet. Si autoalojas el relay de Tenvo en una LAN que no puede alcanzar nuestro servidor de ID público, necesitas apuntar los clientes a tu relay interno usando el flag --relay-server y configurar tu firewall para permitir ese tráfico. Consulta nuestra guía de autoalojamiento para la configuración completa.
• Flujos con latencia crítica en una red conocida y buena. Si estás jugando o haciendo producción de audio sobre LAN, una conexión directa en un puerto fijo es una cosa menos que pueda fallar. Tenvo soporta un modo de "IP directa" para esto, pero no es el predeterminado y no lo usarías desde fuera de la red.

Conclusión

El reenvío de puertos para escritorio remoto es una solución de 2010 para un problema de 2026. La NAT traversal moderna maneja el 99% de las topologías de red sin configuración, sin exponer servicios a Internet pública y sin requerir IP estática. Descarga Tenvo en ambas máquinas, ingresa el ID y ya estás conectado. Si quieres entender el modelo de seguridad que opera debajo de la capa de NAT traversal, lee is remote desktop secure a continuación.

FAQ

¿Tenvo realmente funciona sin ninguna configuración del router?
Sí. El cliente solo hace conexiones salientes, que cualquier NAT y firewall de consumo permite por defecto. No hay reglas entrantes, no hay UPnP, no hay reenvío de puertos.

¿Qué pasa si ambos dispositivos están en CGNAT?
Probablemente el hole punching falle y la sesión caerá al relay. Verás una latencia ligeramente mayor (15-40 ms añadidos), pero la conexión funciona igual en el resto de aspectos.

¿Es el relay un riesgo para la privacidad?
Depende de quién lo opere, y preferimos decirlo claramente en lugar de ocultarlo. El tráfico está protegido por TLS con un certificado por dispositivo, pero TLS termina en el relay: quien lo opere está en posición de ver la sesión. Una conexión directa peer-to-peer no tiene esa parte intermedia, y alrededor del 85% de las conexiones permanecen directas. Si una sesión relayed es inaceptable para tus datos, autoalojar el relay. Nosotros no podríamos leer tu tráfico aunque quisiéramos.

¿Cómo sé si tengo conexión directa o por relay?
La barra de estado en el cliente Tenvo muestra "Direct" o "Relay" una vez establecida la conexión. También puedes comprobar los detalles de la sesión desde la barra de herramientas.

¿Puedo forzar a Tenvo a usar siempre el relay?
Sí, configura relay-only = true en la configuración del cliente. Útil si prefieres latencia consistente en lugar de la variabilidad de que la P2P caiga al relay a mitad de sesión.