¿Qué es CGNAT? Por qué falla el reenvío de puertos y cómo solucionarlo

Cuando un Reenvío de Puerto Correcto Aún No Llega a Ningún Lado

Tu NAS se abre normalmente en casa. El servicio está en ejecución, y la regla de reenvío de puertos apunta a la dirección local correcta. Luego cambias tu teléfono a datos móviles, lo intentas de nuevo y obtienes un timeout. El mismo patrón puede afectar a un servidor de juegos casero, servidor VPN, feed CCTV o aplicación auto-alojada.

La respuesta rápida es que la regla puede ser correcta pero estar detrás de otro límite. Con CGNAT (Carrier-Grade NAT), el ISP comparte direcciones IPv4 públicas y toma la primera decisión de entrada aguas arriba. Controlas la regla en tu router casero, pero una nueva conexión a internet nunca la alcanza a menos que el traductor del proveedor sepa dónde enviarla.

Eso no prueba que CGNAT sea responsable; los problemas locales pueden verse idénticos. El servicio puede escuchar solo en localhost, o un firewall del host puede bloquearlo. Una regla del router puede usar el protocolo TCP/UDP incorrecto o una dirección de destino desactualizada, mientras que un segundo router local puede agregar otro límite. Primero identifica el límite, distingue CGNAT de NAT ordinario y NAT doble, luego elige una solución para el acceso que necesitas.

Palabras clave rápidas: Qué es CGNAT y por qué los ISP lo utilizan

Estos términos son suficientes para seguir dónde se detiene esa conexión faltante.

RFC 6888 define un NAT de nivel de operador (CGN)—también llamado NAT a gran escala (LSN)—como una función del lado del proveedor que permite que múltiples suscriptores compartan una dirección IPv4. Los suscriptores no lo gestionan. “Nivel de operador” describe la ubicación y escala, no una calidad superior.

El límite de propiedad se ve así:

YOU CONTROL                         ISP CONTROLS
device → home router / NAT → ISP CGNAT → shared public IPv4 → internet

El router del hogar controla la red local del cliente. El CGN del ISP asigna conexiones de suscriptores a su dirección pública compartida. La navegación normal sigue funcionando porque un dispositivo inicia la conversación y ambas capas de traducción pueden rastrear la respuesta.

Piensa en la dirección IPv4 pública como la entrada de una calle de un edificio y un puerto como un timbre. Tu router es el mostrador de recepción interior. CGNAT añade un mostrador exterior compartido por muchos clientes y operado por el ISP. Los puertos ayudan a ese mostrador exterior a rastrear conversaciones activas; no dan a cada cliente propiedad permanente de cada timbre en la dirección compartida.

Los ISP utilizan este diseño porque el espacio IPv4 enrutable globalmente es limitado y la transición a IPv6 sigue siendo incompleta. Los grupos libres regionales están efectivamente agotados, aunque las direcciones existentes aún pueden transferirse y reutilizarse. CGNAT preserva la compatibilidad IPv4 compartiendo direcciones escasas. IPv6 proporciona el espacio de direcciones más grande a largo plazo, pero no está disponible de extremo a extremo en todas partes.

NAT vs NAT doble vs CGNAT

Las preguntas decisivas no son “¿Cuántas cajas veo?” sino “¿Dónde ocurre la traducción y quién puede cambiarla?”

📝 Nota: CGNAT a menudo resulta en dos capas NAT IPv4 cuando hay un router doméstico presente, pero “CGNAT” nombra la función operada por el ISP mientras que “NAT doble” solo describe la topología.

Esa distinción de propiedad cambia lo que puedes arreglar. Con dos puertas de enlace locales, es posible que puedas usar modo bridge/AP o configurar ambas capas. Un traductor del proveedor está fuera de esos controles, y algunos diseños CGNAT no incluyen un segundo traductor operado por el cliente en absoluto.

Las etiquetas de consola como “abierto”, “moderado” o “NAT estricto” son separadas. Resumen el comportamiento de conectividad para esa plataforma; no identifican quién es propietario de los traductores ni prueban que CGNAT existe.

Por qué el reenvío de puertos falla detrás de CGNAT

El tráfico saliente funciona porque cada traductor crea estado: un registro temporal que vincula un flujo interno a una dirección y puerto externos. Cuando tu dispositivo inicia una solicitud, el router del hogar y el CGN del ISP registran cada uno, permitiendo que las respuestas coincidentes regresen.

Una nueva conexión entrante no tiene tal estado. Llega primero al IPv4 público compartido del ISP, donde el CGN no tiene un mapeo específico del suscriptor:

OUTBOUND WORKS
device → home NAT [state created] → ISP CGN [state created] → internet
device ← home NAT [state match]   ← ISP CGN [state match]   ← reply

NEW INBOUND CONNECTION STOPS
outside user → shared public IPv4 → ISP CGN
                                      X — no subscriber mapping
                                      home router is never reached

Por eso falla el reenvío de puertos CGNAT. Tu regla de router del hogar puede ser válida, pero pertenece a la recepción interna. Cambiar la lista de visitantes de esa recepción no puede decirle a la recepción externa compartida del ISP qué suscriptor debe recibir un visitante inesperado. El paquete nunca llega a tu regla.

Un proxy inverso en el lado del hogar inaccesible no cambia esto. Puede organizar solicitudes después de que lleguen, pero no puede crear la ruta faltante. Un túnel inverso—o un proxy o relé en un borde accesible—es diferente porque el lado privado establece primero una ruta saliente.

Cómo Saber Si Estás Detrás de CGNAT

Usa la evidencia en este orden:

1. Desactiva VPNs y proxies. Apaga cualquier cosa que cambie la dirección pública desde la cual tu tráfico parece salir.
2. Identifica la puerta de enlace orientada al ISP. Usa el router o módem conectado directamente al proveedor, no un segundo router más adentro de tu red.
3. Compara las dos direcciones. Anota la dirección WAN o IPv4 de Internet de esa puerta de enlace, luego usa un servicio externo para ver tu IPv4 pública al mismo tiempo.

❗ Importante: Una discrepancia entre las direcciones WAN y pública prueba que existe un límite de traducción ascendente, no automáticamente que sea CGNAT. Haz esta inferencia solo desde la puerta de enlace conectada directamente al ISP.

4. Interpreta el resultado. Usa estas señales juntas:
   • Una dirección WAN en 100.64.0.0/10—100.64.0.0 a través de 100.127.255.255—es evidencia fuerte de CGNAT. RFC 6598 reserva este Espacio de Direcciones Compartidas no enrutable globalmente para uso del proveedor; no es espacio privado RFC 1918.
   • Una dirección en 10.0.0.0/8, 172.16.0.0/12, o 192.168.0.0/16 también muestra una WAN no pública, pero puede pertenecer a otro router local.
   • Direcciones WAN y públicas diferentes indican traducción ascendente. Las direcciones enrutables globalmente coincidentes hacen que CGNAT IPv4 ordinario sea mucho menos probable en esa ruta.
5. Descarta causas locales. Antes de llamarlo CGNAT, verifica que:
   • El servicio escuche en su dirección LAN, no solo en localhost.
   • El firewall del host permita el puerto e protocolo previstos.
   • La regla del router apunte a la dirección interna actual y a la opción TCP/UDP correcta.
   • Un segundo router local no esté añadiendo otra capa de traducción.
   • La prueba provenga de datos móviles u otra red genuinamente externa.
6. Confirma con el ISP. Traceroute puede apoyar el diagnóstico cuando saltos compartidos o privados aparecen más allá de la puerta de enlace del hogar, pero los saltos ocultos lo hacen inconcluso. Pregunta al proveedor si la línea usa CGNAT y si hay disponible un IPv4 público dinámico o estático.

Qué afecta CGNAT y qué generalmente no afecta

Esa división saliente/entrante determina lo que los usuarios notan. La navegación, transmisión, descargas y la mayoría de clientes de aplicaciones generalmente funcionan normalmente. Los problemas aparecen cuando un sistema externo debe iniciar una nueva conexión a algo detrás del límite del operador.

El alojamiento directo de IPv4 y el acceso remoto, por lo tanto, necesitan otra ruta accesible. En una red privada, esto afecta el acceso a un NAS, sistema CCTV o panel interno. Los sitios web públicos, receptores de webhook y servidores de juegos enfrentan el mismo requisito de entrada. Un cliente VPN normalmente funciona porque se conecta hacia afuera. Un servidor VPN doméstico es diferente porque los usuarios remotos inician la conexión, por lo que necesita entrada accesible, IPv6 compatible o un punto final en un relé o host público.

Los juegos peer-to-peer, voz y uso compartido de archivos son menos predecibles. Algunas aplicaciones encuentran una ruta directa, mientras que otras usan un relé a través de un intermediario accesible. Un relé puede preservar la conectividad al costo de una latencia adicional. Cuando el recorrido falla, la aplicación puede informar NAT restrictivo o no conectarse. RFC 7021 documenta estos puntos de presión sin implicar un fallo universal.

Compartir una dirección IPv4 puede fusionar suscriptores no relacionados en una reputación. El comportamiento de un usuario puede causar que otros suscriptores vean más CAPTCHAs o límites de velocidad. La dirección compartida también puede terminar en listas de bloqueo, desencadenar restricciones de inicio de sesión simultáneo o producir geolocalización aproximada. Una salida residencial compartida o cambiante complica aún más las listas blancas comerciales que esperan un punto final estable.

📝 Nota: Bloquear IPv4 entrante no solicitado de forma predeterminada puede reducir la exposición accidental, pero CGNAT no es un firewall y no reemplaza la autenticación, actualizaciones, TLS o política de acceso.

CGNAT no detiene el tráfico saliente malicioso. No asegura aplicaciones expuestas a través de otra ruta ni controla quién puede iniciar sesión. Un túnel, IP pública o ruta IPv6 aún requiere controles de seguridad deliberados.

Cinco formas de trabajar alrededor de CGNAT

Las cinco opciones resuelven diferentes problemas de acceso. Las mallas privadas, los túneles gestionados y los relés VPS comparten un patrón útil: el lado privado se conecta hacia afuera primero.

private service → outbound mesh / tunnel link → reachable edge ← outside user

En la analogía del edificio, obtienes una entrada a la calle utilizable o mantienes una línea hacia una entrada en otro lugar.

📝 Nota: “Bypass” es una abreviatura. Estos enfoques no desactivan el NAT del operador; obtienen otro borde público, utilizan IPv6 de extremo a extremo, o establecen una ruta creada por salida.

Comienza con la tabla, luego utiliza los detalles a continuación para los compromisos que importan para tu configuración.

1. Solicita al ISP una IPv4 pública

Para entrada IPv4 general, esta suele ser la opción más simple cuando el ISP la ofrece. Una IPv4 pública dinámica funciona con DNS actualizado. Elige una IPv4 pública estática para listas de permitidos estables, registros o puntos finales VPN. Verifica disponibilidad y costo, y asegura cualquier servicio que expongas directamente.

2. Utiliza IPv6 nativo

El tráfico IPv6 evita CGNAT de IPv4. El acceso directo requiere un prefijo global, un escuchador IPv6, reglas de firewall adecuadas, DNS correcto donde sea necesario, e IPv6 en el lado remoto. No ayuda a clientes solo IPv4 ni expone un servicio automáticamente.

3. Construye una malla privada

Una VPN de malla como Tailscale se adapta a usuarios y dispositivos confiables que pueden ejecutar software cliente autenticado. Intenta conexiones directas, luego puede recurrir a un relé de pares o DERP con algún costo de rendimiento. No está destinada a visitantes anónimos o webhooks públicos.

4. Publica a través de un túnel de salida gestionado

Un servicio como Cloudflare Tunnel conecta el origen hacia afuera a un borde del proveedor. Esto funciona bien para aplicaciones web, APIs, demostraciones y acceso privado controlado. Los visitantes HTTP públicos pueden no necesitar cliente, mientras que los modos privados o no web pueden requerir software del proveedor. La compatibilidad de protocolos, identidad, límites y disponibilidad de borde siguen siendo dependencias del proveedor.

5. Utiliza un VPS como borde público o mueve la carga de trabajo

Un VPS puede retransmitir tráfico a través de un túnel de salida desde casa, u alojar la aplicación directamente cuando no necesita datos o hardware de LAN doméstica. Esto ofrece un punto final estable y control TCP/UDP amplio. Eres responsable de la seguridad, monitoreo, confiabilidad del túnel, ancho de banda, manejo de abuso y latencia añadida. Un VPS de AlexHost seleccionado apropiadamente puede cumplir este rol, sujeto a su direccionamiento público y política de red.

¿Qué opción se ajusta a tu caso de uso?

Elige la arquitectura respondiendo cuatro preguntas en orden:

1. ¿El acceso está limitado a personas y dispositivos de confianza, o abierto al público?
2. ¿Puede cada dispositivo que se conecta instalar y autenticarse a través de software cliente?
3. ¿El servicio es basado en web, o requiere comportamiento arbitrario de TCP/UDP?
4. ¿Prefieres conveniencia administrada o control de la puerta de enlace pública?

Para NAS de confianza, CCTV, o acceso administrativo, usa una VPN de malla cuando los usuarios pueden instalar software cliente. Para endpoints web públicos y webhooks, usa un túnel administrado u hosting público. Traslada la carga de trabajo si no necesita la LAN del hogar.

Para TCP/UDP público, usa IPv4 público de ISP, un edge VPS, o IPv6 cuando todos los clientes lo soportan. El hosting de juegos es específico del título: verifica su modelo de servidor, soporte de traversal y protocolos. Un túnel genérico no puede garantizar una mejor etiqueta NAT de consola.

Un endpoint VPN público necesita IPv4 público, IPv6 funcional, o un host VPS. Para ingreso empresarial o listas de permitidos de socios, elige una dirección estática o una puerta de enlace controlada en lugar de una salida residencial compartida.

Preguntas frecuentes y conceptos erróneos sobre CGNAT

¿Es CGNAT lo mismo que doble NAT? No. CGNAT identifica un NAT multi-suscriptor operado por ISP. Doble NAT solo significa que el tráfico cruza dos traductores.

¿CGNAT siempre ralentiza Internet? No. El rendimiento depende más del proveedor, la aplicación y si hay una retransmisión involucrada.

¿Puede DNS dinámico solucionar CGNAT? No. Rastrea una dirección cambiante pero no puede crear un mapeo ascendente. Ayuda una vez que tienes una dirección pública dinámica alcanzable.

¿Una VPN normal evita CGNAT? Generalmente no. Funciona solo cuando el servicio VPN proporciona reenvío entrante, una superposición privada u otro punto de entrada alcanzable.

¿Puede IPv6 resolverlo? Sí, cuando ambos extremos tienen IPv6 y el firewall y DNS lo permiten. No ayuda a clientes solo IPv4.

¿Es 100.64.0.0/10 espacio privado? Es espacio de uso especial, no enrutable globalmente, Espacio de dirección compartida. Es distinto de los rangos privados RFC 1918 utilizados en redes locales ordinarias.

¿Es CGNAT una característica de seguridad? No. Su comportamiento entrante no es una política de seguridad. Aún necesitas reglas de firewall, autenticación, parches, cifrado y exposición cuidadosa.

La conclusión: Soluciona el Edge Público Faltante, No Solo el Router

El NAS de apertura o servidor de juegos puede tener una regla local correcta y aún así agotarse porque la conexión se detiene en el límite del ISP. Más cambios de router no solucionarán una ruta que el router nunca recibe. Comienza con la audiencia: usa una malla para acceso privado de confianza, mientras que el acceso público necesita IPv4 público, IPv6 funcional, un túnel administrado o un host controlado. Verifica primero las opciones del ISP, luego considera un VPS de AlexHost solo cuando una carga de trabajo alojada o relé se ajuste al diseño.