acceso remoto y CGNAT: por qué dejó de funcionar el reenvío de puertos

Port forwarding used to be the simple answer: punch a hole in the home router, map TCP 3389 or a custom port, and you could reach the machine from anywhere. Today many of those machines are unreachable because the carrier puts customers behind CGNAT. If you search for "remote access cgnat" you want to know: why did port forwarding stop working, how do you detect it, and what are the practical, operational replacements that actually work at scale?

¿Qué es CGNAT y por qué lo usan los ISP?

CGNAT (Carrier-Grade NAT) es una medida de escala que los ISP adoptaron para estirar las direcciones IPv4 escasas. En lugar de asignar a cada cliente una IPv4 pública única, el ISP da una dirección privada RFC 6598 (100.64.0.0/10) u otro rango privado y comparte una única IP pública entre varios suscriptores. El ISP realiza NAT en su punto de agregación — de ahí "carrier-grade".

Dos hechos siguen de inmediato: primero, los dispositivos detrás de CGNAT ya no tienen una IPv4 pública enrutable a la que puedas apuntar. Segundo, el ISP controla los mapeos y las políticas de NAT: ellos deciden qué puertos se mapean, si se permiten conexiones entrantes en absoluto y cuán estables son los mapeos efímeros. En redes móviles, la mayoría de los suscriptores están detrás de CGNAT; algunos ISP de línea fija también lo usan para evitar asignar más espacio IPv4.

Por qué el reenvío de puertos dejó de ser una opción

• No hay IPv4 pública = no ruta entrante. Si la IP WAN de tu router está en 100.64.0.0/10 o en un bloque privado como 10.x.x.x, Internet no puede abrir una conexión directamente al reenvío de puertos local.
• Doble NAT y mapeos efímeros. Incluso si el CPE (enrutador del cliente) soporta reenvío de puertos, el NAT del operador está aguas arriba y suele tener mapeos de puerto transitorios que no puedes controlar.
• NAT simétrico y bloqueos por política. Muchos NAT de operadores son simétricos: el mapeo depende del destino, lo que rompe las estrategias de hole‑punching y hace que el peer‑to‑peer sea poco fiable.
• Seguridad y políticas legales del operador. Los ISP a menudo bloquean intencionalmente las conexiones entrantes no solicitadas para reducir el abuso y cumplir requisitos regulatorios.
• Enlaces móviles y transitorios. Los clientes celulares cambian de IP con frecuencia; aun teniendo un mapeo, no sobrevivirá un handover LTE o un reinicio del módem.

Cómo detectar CGNAT (comprobaciones prácticas)

Antes de cambiar la arquitectura, confirma CGNAT. Estas son comprobaciones rápidas y deterministas que puedes ejecutar en la máquina objetivo o pidiendo información al usuario.

Windows: ipconfig /all
Linux/macOS: ip addr show
Check public IP: curl -s https://ifconfig.co
Check router WAN: look at the router's "WAN" or "Internet" address in its admin UI
If the router shows 100.64.x.x or a private 10.x/192.168.x.x while curl shows a different public IP, you're behind CGNAT.

Otra pista útil es traceroute: si el primer salto público es un dispositivo NAT del ISP con direccionamiento privado o si traceroute muestra un rango privado antes de la IP pública, eso es indicativo. Además, si las reglas de reenvío de puertos que creaste en el CPE no tienen efecto desde Internet público, CGNAT es la causa probable.

Qué reemplazó al reenvío de puertos: alternativas en el mundo real

El reenvío de puertos es una solución a nivel de router local. Cuando la dirección pública desaparece, hay que moverse a uno de varios modelos generales. Cada uno tiene compensaciones en fiabilidad, latencia, visibilidad de seguridad y costo operativo.

1. Peer‑to‑peer con hole punching (STUN/ICE/WebRTC): Funciona bien cuando ambos extremos están en NAT que permiten UDP o tienen mapeos previsibles. Muchas herramientas modernas usan ICE para intentar rutas directas. Pros: baja latencia cuando conecta; contras: falla con NATs simétricos de operadores y requiere fallback.
2. Relays / TURN / relay gestionado: Cuando el hole punching falla, el tráfico se proxya a través de un relay. Los relays tipo TURN garantizan conectividad a costa de saltos extra y uso de ancho de banda. Esta es la sustitución pragmática del reenvío de puertos en el mundo real porque funciona independientemente del NAT del cliente.
3. VPNs (site o por dispositivo): Una VPN puede dar al administrador remoto una dirección enrutable dentro de una malla (Tailscale, ZeroTier, IPsec site‑to‑site clásico). Pros: enrutamiento estable y controles de acceso fuertes; contras: necesita instalación de cliente o hardware de puerta de enlace y puede complicar el ruteo en flotas grandes.
4. IPv6: IPv6 nativo restaura el modelo antiguo porque cada dispositivo puede tener una dirección enrutable globalmente. Pero los ISP muchas veces no ofrecen IPv6 de forma consistente, y operar IPv6 de forma segura a escala requiere una postura de firewall y monitoreo distinta.
5. Túneles inversos (SSH, autossh): Simple y efectivo para pocas máquinas: el objetivo abre una conexión saliente a un servidor conocido que controlas, creando una ruta entrante utilizable. Es operativo para flotas pequeñas, pero costoso en gestión de llaves y fiabilidad a escala.

En la práctica, la mayoría de los productos comerciales de acceso remoto usan una combinación: intentan directo (STUN/UDP) primero y luego recurren a un relay. La vía del relay es la única opción que reemplaza de forma fiable el reenvío de puertos frente a la variedad de NATs de operador, portales cautivos y enlaces móviles que encontrarás.

Qué esperar de un relay y los tradeoffs de seguridad

Muchos lectores suponen que los relays son mágicamente cifrados end‑to‑end de forma que el operador del relay no puede ver el contenido de la sesión. Eso no es la verdad implícita para la mayoría de los sistemas de escritorio remoto. El modelo técnico real suele ser TLS con certificados por dispositivo: cuando una sesión cae en un relay, TLS termina en el relay, por lo que el operador de la infraestructura puede acceder o inspeccionar el tráfico de la sesión si así lo decide. Una conexión P2P directa que nunca pasa por un relay es end‑to‑end entre los dos endpoints, pero en un mundo CGNAT no puedes contar con eso.

Consecuencia operativa: elige un operador de relay en el que confíes, ejecuta relays en múltiples regiones para baja latencia y conmutación por error, y asegúrate de que el relay ofrezca logs de auditoría y controles de acceso verificables. Si una regulación prohíbe el acceso de terceros al tráfico de sesión, necesitarás un relay auto‑hospedado bajo tu control (más abajo hablamos de eso).

Ruta recomendada por Tenvo: relay gestionado por defecto

A escala, la opción más económica y con menos riesgo es un relay gestionado con un cliente moderno que soporte rutas directas y por relay. Tenvo incluye clientes nativos para Windows, macOS y Linux, un cliente en navegador en beta pública y un relay gestionado multi‑región que puedes usar listo para usar. Niveles de precio: Free $0 / Lite $2.99/mo / Pro $7.99/mo. El relay gestionado elimina la carga operativa de parcheo, renovación de certificados, conmutación por error multi‑región y custodia de llaves — tareas que muchos equipos subestiman cuando consideran el "self‑hosting" como una opción gratuita.

Detalle importante: Tenvo usa TLS con un certificado por dispositivo para las sesiones. Eso significa que las conexiones directas entre pares son end‑to‑end para los dos dispositivos, pero las sesiones que usan el relay gestionado tendrán TLS terminado en el relay. Para equipos que no aceptan que el operador del relay esté en posición de descifrar, el auto‑hospedaje es la única vía correcta — pero tiene costos reales.

Para una visión técnica más profunda sobre cómo conectar sin reenvío de puertos, lee Explicación: Acceso remoto sin reenvío de puertos.

Cuándo tiene sentido auto‑hospedar un relay

Auto‑hospedar un relay tiene sentido solo cuando un requisito escrito lo obliga: una obligación de cumplimiento que prohíbe infraestructura de terceros, una red aislada sin egress a Internet, o una regla de residencia de datos mandatada. Si eliges auto‑hospedar por comodidad o por el supuesto costo "gratis", lo pagarás en horas y riesgo:

• Parcheo y respuesta a CVE on‑call para el software del relay y el sistema operativo
• Emisión y renovación de certificados (letsencrypt o PKI empresarial) y almacenamiento seguro de llaves
• Alta disponibilidad e ingeniería de conmutación por error multi‑región para igualar las ofertas gestionadas
• Telemetría operativa, logging y retención para auditorías

Si tu requisito te fuerza a auto‑hospedar, la guía canónica es Remote Desktop Auto‑Hospedado: por qué, cómo y qué falla, que recorre la lista de verificación y los escollos.

Lista de verificación práctica para migración: pasar del reenvío de puertos a acceso fiable

• Inventario de dispositivos: identifica qué endpoints dependen de reenvío de puertos y si están detrás de CGNAT. Registra OS, versión del cliente y si hay agentes desatendidos disponibles.
• Detecta CGNAT: ejecuta las comprobaciones anteriores en dispositivos representativos. Registra ejemplos para poder hablar con el ISP si es necesario.
• Decide el modelo de conectividad: relay gestionado para la mayoría de las flotas; VPN para redes que necesitan una malla enrutada; IPv6 cuando ISP y postura de seguridad lo permitan.
• Implementa agentes persistentes: cambia sesiones efímeras RDP/SSH por un pequeño agente persistente que inicie conexiones salientes al relay o a la malla. Esto reduce el trabajo reactivo.
• Planifica el monitoreo: añade SLOs de disponibilidad de sesión, chequeos de salud del relay y alertas de costo de ancho de banda (los relays consumen egress que debes presupuestar).
• Endurece el acceso: exige MFA, atestación del dispositivo donde sea posible y logs centralizados para grabación de sesiones y forense post‑incidente.
• Prueba conmutación por error y recuperación: simula caídas de relay y asegura que haya una región secundaria o una ruta VPN disponible.

Para un paso a paso rápido sobre cómo poner en marcha un agente de acceso remoto, ve a Cómo configurar acceso remoto en 60 segundos. Para la mecánica subyacente de cómo se establecen las conexiones, lee Cómo funciona el acceso remoto: una explicación simple.

Números operativos y expectativas

Espera que el tráfico por relay añada latencia y costo de ancho de banda. Un relay regional bien ubicado debería agregar 20–80 ms de ida y vuelta comparado con un salto LAN cuando los endpoints están en el mismo continente; las sesiones intercontinentales estarán dominadas por la geografía en cualquier caso. El ancho de banda es facturable: si ejecutas sesiones con video/gráficos, cuenta 1–5 Mbps como línea base para tareas administrativas típicas; edición a alta tasa de frames o gaming puede fácilmente requerir 20–50 Mbps. Estos números informan si una VPN local o una ruta IPv6 son preferibles.

Resumen (TL;DR)

Si enfrentas "remote access cgnat" en producción, deja de planear el reenvío de puertos como solución fiable. Detecta CGNAT y luego elige un modelo: relay gestionado para la mayoría de equipos, VPN/malla para acceso enrutado y aislamiento, IPv6 cuando el ISP y la postura de seguridad lo permitan, y auto‑hospedaje solo cuando un requisito escrito prohíbe relays de terceros. La opción de relay gestionado reduce la carga operativa — la oferta de Tenvo es multi‑región, soporta clientes nativos y un cliente en navegador en beta pública, y viene en niveles Free/Lite/Pro (Free $0 / Lite $2.99/mo / Pro $7.99/mo).

Por último, recuerda el tradeoff de seguridad: los relays terminan TLS. Si tu política admite que un operador de confianza ejecute relays con controles de auditoría, usa la opción gestionada. Si no, presupuesten tiempo y personal para ejecutar vuestros propios relays correctamente.

¿Listo para dejar de perseguir el reenvío de puertos y obtener acceso remoto fiable que soporte CGNAT? Descarga el cliente Tenvo y prueba una ruta de relay gestionado en tu flota: Descargar Tenvo.