Gestión del agotamiento de IP públicas en residencias de estudiantes
Esta guía proporciona una referencia técnica definitiva para arquitectos de red que despliegan Carrier-Grade NAT (CGNAT) y Port Address Translation (PAT) para gestionar el agotamiento de IPv4 en entornos densos de residencias de estudiantes y WiFi multiinquilino. Cubre la arquitectura NAT444, el espacio de direcciones compartidas RFC 6598, el dimensionamiento de Port Block Allocation, estrategias de registro conformes con el GDPR y una ruta de migración de doble pila IPv6. La guía es esencial para cualquier operador que gestione cientos o miles de dispositivos simultáneos en un grupo limitado de IP públicas, proporcionando orientación de configuración práctica, casos de estudio del mundo real y análisis de ROI.
Video overview
Escuchar esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de WiFi multiinquilino →
Resumen Ejecutivo
A medida que se acelera el agotamiento de las direcciones IPv4, los responsables de TI y los arquitectos de red en entornos multiinquilino de alta densidad - como residencias de estudiantes, hostelería y grandes recintos públicos - se enfrentan a importantes retos operativos. Una sola residencia de estudiantes con 1.000 residentes puede generar más de 7.000 dispositivos conectados por IP de forma simultánea. Las arquitecturas estándar de Port Address Translation (PAT) fallan a esta escala, lo que provoca el agotamiento de puertos, la caída de conexiones y una degradación de la experiencia del usuario.
Esta guía de referencia técnica describe la arquitectura y el despliegue de Carrier-Grade NAT (CGNAT) utilizando el modelo NAT444 para gestionar el agotamiento de IP. Al aprovechar el espacio de direcciones compartido de la norma RFC 6598 e implementar la asignación estratégica de bloques de puertos (PBA), los operadores de red pueden lograr una alta densidad de abonados - de hasta 128 usuarios por IP pública - al tiempo que mantienen el cumplimiento de la normativa GDPR y las regulaciones de interceptación legal. Para los recintos que utilizan plataformas como Guest WiFi y WiFi Analytics , una arquitectura CGNAT sólida garantiza una conectividad estable y una recopilación de datos precisa sin el gasto de capital (CapEx) que supone la compra de bloques IPv4 adicionales.
Análisis técnico detallado
El problema de la escala en el alojamiento de estudiantes
La densidad de dispositivos en los alojamientos modernos para estudiantes es diferente a la de casi cualquier otro entorno de red gestionada. Un solo residente suele conectar un smartphone, un portátil, una smart TV, una videoconsola y, al menos, un dispositivo doméstico inteligente. Con una media de cinco a siete dispositivos por residente, un campus de 1.000 plazas presenta una carga de sesiones simultáneas que empequeñece incluso a un hotel de tamaño similar. El desafío se complica por los patrones de uso: las horas punta de la tarde (18:00 - 23:00) registran una actividad de gran ancho de banda casi simultánea en videojuegos, streaming de vídeo y redes sociales, manteniendo todos ellos conexiones en segundo plano persistentes.
El espacio de direcciones IPv4 está prácticamente agotado a nivel de Registro Regional de Internet (RIR). El RIPE NCC, que gestiona las asignaciones en Europa y Oriente Medio, alcanzó su política de asignación final /8 en 2019. El coste de adquirir bloques de direcciones IPv4 públicas adicionales en el mercado libre se sitúa ahora entre los 40 y los 60 dólares por dirección, un CapEx prohibitivo para cualquier operador que gestione cientos de subredes.
Limitaciones de PAT estándar
En las implementaciones tradicionales de un solo sitio, la traducción de direcciones de puerto (PAT) asigna una LAN privada completa (espacio RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) a una única dirección IP pública. Una sola dirección IPv4 tiene 65.535 puertos disponibles en TCP y UDP. Aunque esto es suficiente para una oficina pequeña, en alojamientos de estudiantes de alta densidad, la proliferación de aplicaciones en segundo plano -sincronización en la nube, plataformas de mensajería, servicios de streaming- hace que un solo usuario pueda consumir fácilmente cientos de puertos simultáneos. Cuando el router de borde PAT agota sus puertos disponibles, las nuevas solicitudes de sesión se descartan silenciosamente. Esto se manifiesta en tiempos de espera de las aplicaciones, llamadas VoIP fallidas y un aumento de los tickets de soporte.
Arquitectura de CGNAT (NAT444)
Para superar las limitaciones del NAT de un solo nivel, las redes empresariales deben adoptar una arquitectura CGNAT, concretamente el modelo NAT444. Este nombre hace referencia a las tres capas de espacio de direcciones IPv4 que intervienen en la cadena de traducción.
Nivel 1 - Capa de CPE / Punto de acceso: A los dispositivos de los usuarios se les asignan direcciones IP privadas del espacio RFC 1918 (por ejemplo, 192.168.x.x). El punto de acceso o el equipo local del cliente (CPE) realiza la primera traducción NAT.
Nivel 2 - Pasarela CGNAT: El CPE traduce la dirección privada RFC 1918 al espacio de direcciones compartidas RFC 6598 (100.64.0.0/10). Este espacio intermedio está reservado específicamente para su uso entre la infraestructura del proveedor de servicios y la pasarela CGNAT. El uso de RFC 6598 en lugar de otro rango RFC 1918 evita la superposición de direcciones y los conflictos de enrutamiento en entornos multiinquilino complejos.
Nivel 3 - Internet pública: La pasarela CGNAT realiza la traducción final de la dirección RFC 6598 a una dirección IPv4 pública compartida. Esta es la dirección que es visible para los servicios externos.
Port Block Allocation: decisiones críticas de diseño
La elección de configuración más crítica en un despliegue de CGNAT es la estrategia de asignación de puertos. Existen dos enfoques:
Dynamic Port Allocation (DPA): los puertos se asignan por sesión a partir de un grupo compartido. Esto maximiza la eficiencia del uso de los puertos, pero genera un registro de log para cada configuración y finalización de sesión, lo que crea una enorme carga de conformidad e infraestructura a gran escala.
Port Block Allocation (PBA): a cada abonado se le asigna un bloque de puertos contiguos al iniciar su primera sesión. El bloque permanece asignado hasta que finaliza la sesión del abonado. Este enfoque solo genera logs cuando se asigna y se libera un bloque, lo que reduce el volumen de logs hasta en un 98%.
| Parámetro de configuración | Valor recomendado | Justificación |
|---|---|---|
| Puertos por abonado (tamaño de bloque PBA) | 500 | Suficiente para el uso de aplicaciones web modernas sin agotar el grupo |
| Sesiones simultáneas máximas por abonado | 2.000 | Evita que un único dispositivo infectado agote el grupo |
| Tiempo de espera de sesión (TCP establecido) | 7.440 segundos (RFC 5382) | Se alinea con las recomendaciones del IETF para el comportamiento de NAT |
| Tiempo de espera de sesión (UDP) | 300 segundos | Evita que los mapeos UDP obsoletos consuman espacio de puertos |
Referencia del sector: NFWare, un proveedor experto en CGNAT con despliegues en más de 100 ISP, recomienda un máximo de 128 abonados por IP pública con 500 puertos asignados por abonado. Ir más allá de este límite - por ejemplo, llegar a 256 abonados por IP con 250 puertos cada uno - aumenta significativamente el riesgo de caídas de sesión durante las cargas de pico.
Dual-Stack IPv6 como ruta de migración a largo plazo
CGNAT es una estrategia de mitigación, no una solución permanente. La dirección arquitectónica correcta es un despliegue Dual-Stack: ejecutar IPv6 de forma nativa junto con IPv4 con CGNAT. Los dispositivos modernos y las principales CDN (Google, Netflix, Meta, Cloudflare) prefieren claramente IPv6 cuando está disponible. En un entorno dual-stack bien configurado, entre el 60% y el 70% del tráfico total se puede desviar a IPv6, lo que reduce drásticamente la carga en el grupo de CGNAT IPv4 y prolonga su vida útil efectiva.
Para entornos de sanidad y transporte donde el soporte de dispositivos heredados es crítico, dual-stack también proporciona una ruta de migración clara: los dispositivos compatibles con IPv6 migran de forma nativa, mientras que los dispositivos heredados que solo admiten IPv4 continúan funcionando a través de CGNAT sin ninguna interrupción para el usuario.
Guía de implementación
Paso 1: Auditar su asignación actual de IP y la densidad de dispositivos
Antes de desplegar CGNAT, establezca una base de referencia. Recopile los siguientes datos de sus sistemas de gestión de red existentes:
- Número máximo de dispositivos simultáneos por subred
- Sesiones medias y máximas por dispositivo
- Porcentaje actual de utilización de IP públicas
- Configuraciones de tiempo de espera de NAT existentes
Estos datos informan directamente sobre el tamaño del bloque PBA y los requisitos del pool de IP públicas.
Paso 2: Diseñar la red de tránsito RFC 6598
Asigne el bloque 100.64.0.0/10 para la red de tránsito de calidad de operador. Planifique el direccionamiento de subredes para que coincida con la topología de su campus, normalmente un /24 o /23 por edificio o segmento de capa de acceso. Asegúrese de que su infraestructura de enrutamiento no filtre prefijos RFC 6598 a la internet pública o a los socios de peering.
Paso 3: Desplegar y configurar las puertas de enlace CGNAT
La puerta de enlace CGNAT es normalmente un dispositivo de hardware dedicado o una función de red virtualizada (VNF) que se ejecuta en hardware de servidor común. Parámetros de configuración clave:
- Pool de NAT: Asigne su bloque de IPv4 público al pool de NAT. Asegúrese de que el tamaño del pool sea adecuado para su relación objetivo de abonados por IP.
- Configuración de PBA: Establezca el tamaño del bloque en 500 puertos. Configure el máximo de bloques por abonado en 1 (con la opción de ampliarlo a 2 si un abonado agota su bloque inicial, en lugar de aumentar el tamaño del bloque base).
- Registro (Logging): Configure la salida de syslog hacia su SIEM. Con PBA, cada entrada de registro registra: IP interna del abonado, IP pública asignada, inicio del bloque de puertos asignado, fin del bloque, marca de tiempo de la asignación y marca de tiempo de la liberación.
- Límites de sesión: Aplique un máximo de 2.000 sesiones simultáneas por abonado para evitar abusos.
Paso 4: Integrar con la capa de identidad y autenticación
En entornos que utilizan la plataforma Guest WiFi , la autenticación del Captive Portal debe realizarse en o antes del límite de NAT de Nivel 1. Esto garantiza que el proveedor de identidad pueda asociar de forma precisa las direcciones MAC y las credenciales de usuario a direcciones IP internas únicas antes de que el tráfico se agregue en el pool de CGNAT. La plataforma de Purple gestiona esto a nivel de punto de acceso, manteniendo una vinculación clara de usuario a IP que persiste a lo largo de la cadena de traducción NAT.
Para despliegues de acceso sin contraseña - como se describe en How a WiFi Assistant Enables Passwordless Access in 2026 - se aplica el mismo principio: la vinculación de identidad debe establecerse antes de la puerta de enlace CGNAT para garantizar una atribución de sesión precisa.
Paso 5: Configurar IPv6 Dual-Stack
Habilite IPv6 en todos los puntos de acceso y distribuya un prefijo /64 por VLAN a través de DHCPv6 o SLAAC. Declare las rutas IPv6 a través de su proveedor ascendente. Antes de reducir el tamaño de su pool de NAT IPv4, verifique que el tráfico de las principales CDN (Google, Netflix, YouTube) se resuelva en registros AAAA y se enrute a través de IPv6.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.
Buenas prácticas
Implemente NAT determinista siempre que sea posible. El NAT determinista utiliza un mapeo algorítmico entre la dirección IP interna de un suscriptor y su IP pública asignada y bloque de puertos. Dado que el mapeo es calculable matemáticamente, no es necesario mantener o registrar una tabla de sesiones; el mapeo se puede descodificar a la inversa bajo demanda para fines de interceptación legal. Este es el estándar de oro para despliegues que priorizan el cumplimiento normativo.
Distribuya la carga de la puerta de enlace CGNAT. Evite concentrar todo el tráfico CGNAT a través de un único dispositivo. Distribuya las puertas de enlace por el campus o los edificios para evitar un único punto de fallo. Las puertas de enlace distribuidas también mitigan el riesgo de reputación de la IP: si una IP pública en el grupo es marcada por una CDN debido a patrones de tráfico sospechosos (problemas de CAPTCHA), solo se verá afectado un subconjunto de usuarios.
Supervise activamente la reputación de la IP. Suscríbase a fuentes de reputación de IP (por ejemplo, Spamhaus, SURBL) y supervise las IP de su grupo de NAT público. Mantenga un grupo de reserva de IP limpias para rotar si una dirección activa entra en una lista negra. Esto es especialmente crítico en los alojamientos para estudiantes, donde un número reducido de usuarios puede realizar actividades que activen alertas de abuso.
Aplique límites de sesión por suscriptor. Un límite estricto de 2000 sesiones concurrentes por suscriptor evita que un solo dispositivo infectado - por ejemplo, uno que participe en un ataque de amplificación DDoS - agote todo el bloque de puertos asignado a esa IP pública. Para obtener más detalles sobre la supervisión del rendimiento de la red, consulte nuestra guía sobre cómo medir la intensidad de la señal y la cobertura WiFi .
Alinéese con 802.1X para el control de acceso. Desplegar la autenticación basada en puertos 802.1X en la capa de acceso garantiza que solo los dispositivos autenticados reciban asignaciones de IP. Esto mitiga el riesgo de que dispositivos no autorizados consuman las asignaciones de puertos y proporciona una pista de auditoría clara para fines de interceptación legal.
Resolución de problemas y mitigación de riesgos
Carga de registro y cumplimiento normativo
En el Reino Unido y Europa, bajo el GDPR y la Ley de Poderes de Investigación de 2016 (Investigatory Powers Act 2016), los operadores de red deben ser capaces de rastrear una dirección IP pública y un número de puerto hasta un usuario específico en una marca de tiempo concreta. Esta es una obligación legal no negociable.
Riesgo: Con CGNAT dinámico, registrar cada establecimiento y finalización de sesión genera terabytes de datos de syslog diariamente. Un despliegue de 1000 usuarios con asignación dinámica puede generar 500 millones de entradas de registro al día. Esto satura la infraestructura SIEM, infla los costes de almacenamiento y hace que las investigaciones forenses sean inviables.
Mitigación: La asignación de bloques de puertos reduce el volumen de registros hasta en un 98%. Con PBA, solo registra los eventos de asignación y liberación de bloques - normalmente dos entradas de registro por sesión de usuario, en lugar de cientos o miles. Asegúrese de que su SIEM conserve estos registros durante un mínimo de 12 meses para cumplir con los requisitos de retención de datos del Reino Unido.
Problemas de CAPTCHA y reputación de IP
Cuando 128 usuarios comparten una única IP pública, el volumen de tráfico agregado puede activar la limitación de velocidad o las protecciones antibot en los principales sitios web. El reCAPTCHA de Google, la gestión de bots de Cloudflare y sistemas similares utilizan heurísticas basadas en IP que pueden clasificar erróneamente una IP de CGNAT compartida como una fuente de bots.
Mitigación: Distribuya su pool de CGNAT a través de múltiples IP públicas. Supervise activamente las puntuaciones de reputación. Considere la posibilidad de implementar DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT) para evitar problemas de reputación basados en DNS. Explique a los usuarios que la aparición ocasional de CAPTCHA es un comportamiento conocido en entornos de IP compartidas.
Problemas de compatibilidad de aplicaciones
Algunas aplicaciones - especialmente los protocolos peer-to-peer, ciertas implementaciones de VoIP y las plataformas de juego más antiguas - dependen de un mapeo de puertos persistente o del inicio de conexiones entrantes. Esto puede fallar bajo un doble NAT.
Mitigación: Para VoIP, asegúrese de que su pasarela CGNAT sea compatible con ALG (Application Layer Gateway) para SIP. Para el gaming, considere la posibilidad de implementar un proxy UPnP o una VLAN de gaming dedicada con un pool de NAT independiente y menos denso. Para entornos de retail donde los sistemas de punto de venta requieren conectividad entrante, coloque esos dispositivos en una VLAN separada que evite por completo la capa CGNAT.
ROI e impacto empresarial
Ahorro en gastos de capital (CapEx)
La implementación de CGNAT proporciona un ahorro inmediato y sustancial de CapEx. A un precio de mercado de 50 $ por dirección IPv4, una universidad con 5.000 camas que requiera una relación dispositivo a IP de 1:1 necesitaría comprar aproximadamente 35.000 direcciones IP, lo que costaría 1,75 millones de dólares. Al desplegar CGNAT con una relación de 128:1, el mismo despliegue requiere menos de 300 IP públicas, lo que reduce los costes de adquisición de IP a aproximadamente 15.000 $.
Incluso después de tener en cuenta el coste del hardware de la pasarela CGNAT o de las funciones de red virtualizadas (normalmente entre 20.000 $ y 80.000 $ para un despliegue a escala de campus), el ahorro neto es sustancial.
Reducción de gastos operativos (OpEx)
Una conectividad estable reduce directamente los costes del servicio de asistencia. Los eventos de agotamiento de puertos - el principal modo de fallo del PAT estándar a gran escala - generan un volumen excesivo de tickets de soporte. Un despliegue de CGNAT bien configurado con límites de sesión adecuados y PBA elimina este modo de fallo, lo que se traduce en una reducción estimada del 30 al 40% en el volumen de consultas de soporte relacionadas con la red.
Ventaja competitiva en residencias de estudiantes
En el competitivo mercado del alojamiento para estudiantes, la calidad de la red es un criterio de selección primordial para los posibles inquilinos. Los operadores que pueden demostrar una conectividad constante y de alto rendimiento - validada a través de paneles de WiFi Analytics que muestran métricas de tiempo de actividad, calidad de sesión y densidad de dispositivos - consiguen tarifas de alquiler premium y logran una mayor ocupación. Esta estabilidad de la infraestructura es también la base para desplegar servicios avanzados basados en la ubicación, como se destaca en Purple launched offline maps mode for seamless, secure navigation for WiFi hotspots .
Caso de estudio 1: Residencia universitaria de 800 camas
Una residencia universitaria de 800 camas gestionada por una universidad del Reino Unido experimentaba problemas crónicos de conectividad durante las horas punta de la tarde. La investigación reveló que su configuración PAT de un solo nivel, que utilizaba una subred pública /29 (6 IPs útiles), agotaba los puertos disponibles a las 19:30 cada tarde. El operador desplegó una solución CGNAT con PBA (500 puertos por abonado, 128 abonados por IP), actualizó a una subred pública /27 (30 IPs útiles) y habilitó la doble pila IPv6. Las métricas posteriores al despliegue mostraron una reducción del 94% en los incidentes de agotamiento de puertos en comparación con el piloto inicial de asignación dinámica, una reducción del 38% en los tiques de soporte técnico relacionados con la red y una reducción del 65% en el volumen de registros de CGNAT. A los 60 días del despliegue, la tasa de descarga de IPv6 alcanzó el 62%.
Caso de estudio 2: Operador de alojamiento para estudiantes construido a tal efecto (PBSA) de 1.200 habitaciones
Un operador privado de PBSA que gestiona tres ubicaciones en dos ciudades del Reino Unido necesitaba estandarizar su arquitectura de red antes de abrir una cuarta ubicación. Su infraestructura existente utilizaba una mezcla de NAT de un solo nivel y segmentación VLAN ad-hoc sin una estrategia de registro coherente. Se implementó un despliegue de CGNAT con NAT determinista en los tres sitios, lo que permitió un mapeo de abonado a IP calculable matemáticamente sin la sobrecarga de registro de sesiones. Este enfoque satisfizo al equipo legal del operador en cuanto al cumplimiento de la interceptación legal, eliminó los costes de almacenamiento SIEM para los registros de sesiones y proporcionó una plantilla de arquitectura coherente para la cuarta ubicación. El operador también integró la plataforma de Guest WiFi de Purple para la autenticación del Captive Portal, estableciendo la vinculación de identidad antes de la pasarela CGNAT para garantizar una atribución precisa de los usuarios en los informes analíticos.
Definiciones clave
CGNAT (Carrier-Grade NAT)
Una arquitectura de red en la que un operador realiza la traducción de direcciones de red en una pasarela centralizada, lo que permite que múltiples suscriptores compartan una única dirección IPv4 pública. Definido en RFC 6264 y RFC 6888. También conocido como Large-Scale NAT (LSN) o CGN.
Los equipos de TI se encuentran con CGNAT cuando una única IP pública no es suficiente para dar servicio a todos los dispositivos de una red. En las residencias de estudiantes, CGNAT es el mecanismo principal para gestionar el agotamiento de IPv4 sin comprar espacio de direcciones públicas adicional.
NAT444
Una topología específica de CGNAT que implica tres capas de espacio de direcciones IPv4: direcciones privadas del suscriptor (RFC 1918), direcciones compartidas de grado de operador (RFC 6598) y direcciones de internet pública. El nombre hace referencia a las tres redes IPv4 que se atraviesan.
NAT444 es la arquitectura estándar para despliegues de CGNAT en entornos multi-inquilino. El diseño de red debe comprender el modelo de tres capas para estructurar correctamente la red intermedia y evitar el solapamiento de direcciones.
Espacio de direcciones compartidas RFC 6598
El bloque de direcciones IPv4 100.64.0.0/10 (100.64.0.0 a 100.127.255.255) reservado por la IANA para su uso en la red intermedia entre un CPE y una pasarela CGNAT. Este espacio no es enrutable en la internet pública y está diseñado específicamente para evitar conflictos de direcciones en despliegues NAT444.
Los equipos de TI deben utilizar el RFC 6598 - y no el RFC 1918 - para la red intermedia de CGNAT. El uso de RFC 1918 para este segmento crea riesgos de solapamiento cuando se utilizan los mismos rangos de RFC 1918 en las redes de los suscriptores.
Asignación de bloques de puertos (PBA)
Una estrategia de asignación de puertos en CGNAT en la que se asigna un bloque contiguo de puertos (por ejemplo, 500 puertos) a cada suscriptor durante la sesión, en lugar de asignar puertos de forma individual por conexión. Definido en RFC 7422.
PBA es el enfoque recomendado para despliegues de CGNAT que cumplan con el GDPR. Reduce la sobrecarga de registro (logging) hasta en un 98% en comparación con la asignación dinámica de puertos, lo que hace que el cumplimiento de la interceptación legal sea viable operativamente a gran escala.
NAT determinista
Una configuración de CGNAT en la que la asignación entre la dirección IP interna de un suscriptor y su bloque de puertos e IP pública asignados se calcula algorítmicamente, sin mantener una tabla de sesiones. La asignación es reversible matemáticamente, lo que permite la identificación del suscriptor sin necesidad de recuperar registros.
El NAT determinista es el estándar de oro para los despliegues preocupados por el cumplimiento normativo. Elimina por completo la sobrecarga de registro al tiempo que satisface los requisitos de interceptación legal, ya que el suscriptor puede identificarse a partir de una IP pública, puerto y marca de tiempo mediante el algoritmo conocido.
PAT (Port Address Translation)
Una forma de traducción de direcciones de red en la que múltiples direcciones IP privadas se asignan a una única dirección IP pública diferenciando las conexiones mediante números de puerto de origen únicos. También conocido como sobrecarga de NAT o NAT de muchos a uno.
PAT es el NAT de nivel único estándar utilizado en la mayoría de los routers de frontera empresariales. Es el predecesor de CGNAT y es insuficiente para entornos multi-inquilino densos debido al agotamiento de puertos a gran escala.
Tabla de sesiones
Una estructura de datos mantenida por una pasarela NAT que registra la asociación entre la dirección IP y el puerto internos (privados), y la dirección IP y el puerto externos (públicos), para cada conexión activa. La tabla de sesiones es el recurso principal de memoria y procesamiento consumido por CGNAT.
El dimensionamiento de la tabla de sesiones es un parámetro crítico de planificación de capacidad para las pasarelas CGNAT. Un despliegue de 1000 suscriptores con un máximo de 2000 sesiones por suscriptor requiere una capacidad de tabla de sesiones de al menos 2 millones de entradas. Un dimensionamiento insuficiente de la tabla de sesiones provoca fallos de conexión.
Doble pila
Una configuración de red en la que tanto los protocolos IPv4 como IPv6 están activos simultáneamente en la misma infraestructura de red y dispositivos finales. Los dispositivos con capacidad de doble pila preferirán IPv6 para las conexiones a destinos compatibles con IPv6.
La doble pila es la estrategia de transición recomendada para despliegues de CGNAT. Al descargar el tráfico compatible con IPv6 a la ruta nativa de IPv6, la doble pila reduce la carga en el grupo de IPv4 CGNAT y proporciona una vía de migración hacia una red principalmente IPv6.
Espacio de direcciones privadas RFC 1918
Los tres rangos de direcciones IPv4 reservados para uso en redes privadas: 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. Estas direcciones no son enrutables en el internet público y se utilizan para el direccionamiento de redes internas.
Las direcciones RFC 1918 se utilizan para el direccionamiento de dispositivos de abonados en despliegues de CGNAT. Los arquitectos de red deben asegurarse de que los rangos RFC 1918 utilizados en las redes de abonados no se superpongan con los utilizados en la red CGNAT intermedia; razón por la cual se utiliza RFC 6598 para la capa intermedia.
Interceptación legal
La interceptación de comunicaciones legalmente autorizada por parte de las fuerzas de seguridad. En el Reino Unido, está regulada por la Investigatory Powers Act 2016. Los operadores de red deben ser capaces de identificar al abonado asociado con una dirección IP pública, un puerto y una marca de tiempo específicos al recibir una solicitud de interceptación legal.
El cumplimiento de la interceptación legal es el principal factor que impulsa los requisitos de registro de CGNAT. Los operadores deben conservar registros suficientes para identificar a los abonados a partir de los datos de puertos e IP públicas. PBA y el NAT determinista son las dos arquitecturas que hacen que esto sea viable a escala sin saturar la infraestructura de registro.
Ejemplos prácticos
Un bloque de alojamiento para estudiantes de 600 camas utiliza actualmente una única subred pública /29 (6 IP útiles) con PAT estándar. Durante las horas de mayor afluencia nocturna (19:00 - 23:00), los usuarios informan de fallos generalizados de conectividad. El equipo de red ha confirmado el agotamiento de puertos en el router PAT. El operador dispone de presupuesto para hardware de puerta de enlace CGNAT, pero no puede adquirir más IP públicas además de una /27 (30 IP útiles). Diseñe un despliegue de CGNAT que elimine el problema de agotamiento de puertos y soporte el crecimiento futuro hasta las 900 camas.
Paso 1 - Evaluación de la línea base: Con 600 camas a 5 dispositivos por ocupante, el número máximo de dispositivos simultáneos es de aproximadamente 3.000. Con 500 puertos por abonado (PBA), cada IP pública admite 128 abonados. Con 30 IP útiles en la /27, la capacidad máxima teórica de abonados es de 3.840, suficiente para 900 camas a 4,3 dispositivos por ocupante. Paso 2 - Red intermedia RFC 6598: Asignar 100.64.0.0/20 para la red intermedia de nivel de operador, proporcionando 4.096 direcciones para el tráfico de la CPE a la puerta de enlace CGNAT. Subred por ala del edificio: 100.64.0.0/24, 100.64.1.0/24, etc. Paso 3 - Dimensionamiento de la puerta de enlace CGNAT: Desplegar una puerta de enlace CGNAT con una capacidad de tabla de sesiones de al menos 768.000 entradas (3.000 abonados × 2.000 sesiones máximas por abonado, con un 20% de margen de seguridad). Configurar PBA con bloques de 500 puertos. Establecer el máximo de bloques por abonado en 1, permitiendo el desbordamiento a 2 bloques para los abonados que superen las 500 sesiones simultáneas. Paso 4 - Doble pila IPv6: Habilitar IPv6 en todos los puntos de acceso. Distribuir prefijos /64 a través de SLAAC. Apuntar a una descarga de IPv6 del 60% en un plazo de 90 días, lo que reduce eficazmente la carga de CGNAT IPv4 a 1.200 abonados IPv4 simultáneos, muy dentro de la capacidad de la /27. Paso 5 - Registro: Configurar syslog hacia el SIEM únicamente con eventos de asignación/liberación de bloques PBA. Retener los registros durante un mínimo de 12 meses. Paso 6 - Límites de sesión: Imponer un máximo de 2.000 sesiones por abonado en la puerta de enlace CGNAT para evitar abusos.
Un operador de residencias de estudiantes para fines específicos (PBSA) ha desplegado CGNAT en un sitio de 1.000 camas utilizando asignación dinámica de puertos. Su equipo legal ha señalado que el enfoque de registro actual genera 400 GB de datos syslog al día, lo que está saturando el SIEM y haciendo inviable cumplir con las solicitudes de interceptación legal de las fuerzas de seguridad. Rediseñe la estrategia de registro para cumplir con las obligaciones de interceptación legal del Reino Unido y al mismo tiempo reducir el volumen de registros a un nivel manejable.
Paso 1 - Migrar a la asignación de bloques de puertos (PBA): Reemplace la asignación dinámica de puertos con PBA a 500 puertos por abonado. Esto reduce de inmediato los eventos de registro de uno por sesión a uno por asignación de bloque y uno por liberación de bloque. Para una implementación de 1.000 usuarios con una media de 3 ciclos de asignación/liberación de bloques por usuario al día, esto genera aproximadamente 6.000 entradas de registro al día, una reducción de más del 99% con respecto a la línea de base de asignación dinámica. Paso 2 - Esquema de registro: Asegúrese de que cada entrada de registro de PBA capture: (a) dirección IP interna del abonado, (b) dirección IP pública asignada, (c) inicio y fin del bloque de puertos asignado, (d) marca de tiempo de la asignación del bloque (UTC), (e) marca de tiempo de la liberación del bloque (UTC), (f) identificador del abonado (dirección MAC o nombre de usuario de RADIUS). Paso 3 - Opción de NAT determinista: Si la plataforma CGNAT lo admite, migre a NAT determinista. Esto elimina por completo el registro para las operaciones rutinarias, ya que el mapeo se puede calcular matemáticamente. Conserve los registros de PBA solo para casos de desbordamiento no deterministas. Paso 4 - Política de retención: Conserve los registros durante 12 meses en un almacén de registros a prueba de manipulaciones (por ejemplo, almacenamiento de objetos compatible con S3 de escritura única). Implemente controles de acceso para que la recuperación de registros para solicitudes de interceptación legal requiera doble autorización. Paso 5 - Procedimiento de respuesta a incidentes: Documente el procedimiento para responder a las solicitudes de interceptación legal, incluida la fórmula para calcular a la inversa el abonado a partir de una IP pública, un puerto y una marca de tiempo bajo NAT determinista.
El equipo de TI de una universidad informa que los estudiantes experimentan desafíos CAPTCHA frecuentes y límites de velocidad por parte de Google, Netflix y plataformas de videojuegos. La investigación revela que 200 estudiantes comparten una única dirección IP pública a través de CGNAT. Se ha informado al equipo de que no es posible adquirir más direcciones IP públicas a corto plazo. ¿Qué mitigaciones inmediatas se pueden implementar sin cambiar la asignación de IP?
Paso 1 - Reducir la densidad de abonados: La relación de 200:1 es la causa principal. Incluso sin direcciones IP públicas adicionales, revise si el grupo de CGNAT se está utilizando de manera eficiente. Asegúrese de que la doble pila IPv6 esté totalmente habilitada; si el 60% del tráfico se descarga a IPv6, el número efectivo de abonados IPv4 cae a aproximadamente 80 por IP, muy por debajo del umbral recomendado de 128:1. Paso 2 - Rotación de IP: Implemente una política de rotación para el grupo de IP públicas. Si la pasarela CGNAT lo admite, configure la rotación periódica de la IP pública asignada a cada grupo de abonados. Esto evita que una sola IP acumule una reputación negativa persistente. Paso 3 - Optimización de DNS: Asegúrese de que los resolutores DNS proporcionados a los clientes devuelvan registros AAAA de manera preferente. Muchos activadores de CAPTCHA se basan en DNS: si un cliente resuelve un servicio a una dirección IPv4 de forma innecesaria, se enruta a través de CGNAT cuando podría usar IPv6 de forma nativa. Paso 4 - Ajuste del tiempo de espera de la sesión: Reduzca los tiempos de espera de la sesión UDP de los predeterminados (a menudo 300 segundos) a 60 segundos para el tráfico UDP que no sea DNS. Esto libera espacio de puertos más rápido y reduce el volumen aparente de sesiones desde la perspectiva de los servicios externos. Paso 5 - Comunicación con las plataformas afectadas: Para problemas persistentes de listas negras, envíe solicitudes de eliminación de listas a las principales bases de datos de reputación de IP (Spamhaus, SURBL). Documente que la IP es una dirección CGNAT compartida que presta servicio a una institución educativa legítima.
Preguntas de práctica
Q1. Un campus de alojamiento para estudiantes de 2.000 camas dispone de una subred pública /26 (62 direcciones IP utilizables). El equipo de red está planificando un despliegue de CGNAT. Calcule: (a) el número máximo de abonados que se pueden admitir con la relación recomendada de 128:1, (b) la capacidad total de puertos disponible, (c) el tamaño recomendado del bloque PBA y (d) si el /26 existente es suficiente o si se necesitan direcciones IP adicionales.
Sugerencia: Comience con el total de direcciones IP utilizables en un /26 y, a continuación, aplique la relación de abonados de 128:1. Compare el resultado con el recuento de dispositivos para un alojamiento de 2.000 camas con una relación realista de dispositivos por ocupante. Tenga en cuenta la descarga de doble pila IPv6 en su recomendación final.
Ver respuesta modelo
Un /26 proporciona 62 direcciones IP públicas utilizables. Con 128 abonados por IP, la capacidad máxima de IPv4 CGNAT es 62 × 128 = 7.936 abonados. Con 5 dispositivos por ocupante, 2.000 camas generan aproximadamente 10.000 dispositivos simultáneos. Sin IPv6, el /26 es insuficiente (7.936 < 10.000). Sin embargo, con una doble pila IPv6 que logre una descarga del 60 %, la carga real de IPv4 disminuye a aproximadamente 4.000 dispositivos, lo que entra perfectamente dentro de la capacidad de 7.936 del /26. El tamaño recomendado de bloque PBA es de 500 puertos por abonado. Capacidad total de puertos: 62 IP × 64.000 puertos utilizables = 3.968.000 puertos. A 500 puertos por abonado: 3.968.000 / 500 = 7.936 abonados como máximo. Recomendación: Desplegar CGNAT con PBA a 500 puertos/abonado, habilitar la doble pila IPv6 como requisito previo, siendo suficiente el /26 existente. Si no se puede garantizar una descarga de IPv6 superior al 50 %, adquiera un /27 adicional como reserva.
Q2. Una implementación de CGNAT en una residencia de estudiantes de 500 camas está generando problemas de cumplimiento. El equipo legal del operador ha recibido una solicitud de interceptación legal de las fuerzas de seguridad para una dirección IP pública específica (203.0.113.45), puerto 51432, con marca de tiempo 2025-11-15 21:47:33 UTC. La pasarela CGNAT está configurada con asignación dinámica de puertos. El SIEM contiene 180 días de registros, pero el equipo forense informa que localizar al suscriptor específico a partir de los registros está llevando más de 4 horas por solicitud. Identifique la causa raíz y proponga una solución que reduzca el tiempo de respuesta a menos de 15 minutos.
Sugerencia: El tiempo de respuesta de 4 horas es un síntoma de la arquitectura de registro, no un problema de retención de datos. Considere qué información se registra bajo asignación dinámica frente a PBA, y cómo el NAT determinista cambiaría el proceso de respuesta por completo.
Ver respuesta modelo
Causa raíz: La asignación dinámica de puertos genera una entrada de registro por sesión. Con 500 usuarios × cientos de sesiones por usuario por hora, el SIEM contiene millones de entradas de registro al día. Localizar una sola entrada por IP, puerto y marca de tiempo requiere una búsqueda de texto completo en potencialmente miles de millones de registros, de ahí el tiempo de respuesta de 4 horas. Opción de solución 1 (PBA): Migrar a la asignación de bloques de puertos (Port Block Allocation). Con PBA, la entrada de registro para el puerto 51432 registraría la asignación del bloque (por ejemplo, puertos 51001-51500 asignados al suscriptor 192.168.1.23 a las 21:30:00 UTC, liberados a las 23:15:00 UTC). Una única consulta indexada sobre la IP pública + rango de puertos + marca de tiempo devuelve el resultado en segundos. Tiempo de respuesta estimado: menos de 2 minutos. Opción de solución 2 (NAT determinista): Si la plataforma lo admite, migrar a NAT determinista. El puerto 51432 se puede calcular matemáticamente de forma inversa a la IP interna del suscriptor sin necesidad de realizar ninguna consulta de registro. Tiempo de respuesta: menos de 30 segundos. Acción inmediata: Indexar los registros existentes del SIEM en (public_ip, port, timestamp) para reducir el tiempo de respuesta actual mientras se planifica la migración a PBA.
Q3. Un arquitecto de redes está diseñando la infraestructura CGNAT para una nueva promoción de alojamiento para estudiantes (PBSA) de 800 camas. El ISP ascendente ha proporcionado una subred pública /27 y ha confirmado que el tránsito IPv6 está disponible. El operador también desea implementar la plataforma de WiFi para invitados de Purple para la autenticación a través de Captive Portal. Describa la ubicación correcta de la autenticación del Captive Portal con respecto a la pasarela CGNAT, y explique por qué una ubicación incorrecta genera un riesgo de cumplimiento.
Sugerencia: Considere qué información necesita registrar el Captive Portal (identidad del usuario, MAC del dispositivo, IP interna) y en qué punto de la cadena de traducción NAT sigue estando disponible esta información. Piense en qué le ocurre a la dirección IP interna después de pasar por la pasarela CGNAT.
Ver respuesta modelo
La autenticación del Captive Portal debe realizarse en el límite de NAT de Nivel 1 o antes de este, es decir, en el punto de acceso o en la capa de CPE, antes de que el tráfico entre en la red intermedia RFC 6598. Ubicación correcta: La plataforma de WiFi para invitados de Purple autentica al usuario en el punto de acceso. La plataforma registra la vinculación: identidad del usuario → dirección MAC → IP interna RFC 1918 → marca de tiempo. Esta vinculación se establece antes de que la pasarela CGNAT realice su traducción. A continuación, la pasarela CGNAT mapea la IP RFC 1918 a una IP pública y a un bloque de puertos, y el registro PBA almacena: IP RFC 1918 → IP pública → bloque de puertos → marca de tiempo. Ambos registros de registro se pueden asociar mediante la IP RFC 1918 y la marca de tiempo para producir una cadena completa: identidad del usuario → IP pública + puerto. Ubicación incorrecta (Captive Portal después de la pasarela CGNAT): Si la autenticación se produce después de la pasarela CGNAT, la plataforma solo ve la IP pública y el puerto, no la IP interna. En este punto, no se pueden distinguir varios usuarios detrás de la misma IP de CGNAT. La plataforma no puede crear una vinculación fiable de usuario a IP, lo que hace imposible la atribución para la interceptación legal y vulnera los requisitos de responsabilidad de GDPR. Este es el riesgo de cumplimiento. Con la arquitectura de Purple, la vinculación de identidad se establece antes de la capa CGNAT, lo que garantiza una atribución de usuario precisa tanto en la plataforma de analítica como en la cadena de registros de cumplimiento.
Continúe leyendo esta serie
Diseño de redes WiFi para edificios de oficinas multi-inquilino
Esta guía proporciona a directores de TI, arquitectos de redes y CTO una hoja de ruta neutral respecto al proveedor para diseñar redes WiFi escalables, seguras y aisladas en edificios de oficinas multi-inquilino. Cubre la segmentación de VLAN bajo IEEE 802.1Q, la asignación dinámica de VLAN mediante 802.1X y RADIUS, la planificación de RF para entornos de alta densidad y consideraciones de cumplimiento normativo bajo GDPR y PCI-DSS. Los operadores de recintos y gestores de edificios encontrarán orientación arquitectónica práctica, casos de estudio reales y errores de configuración que deben evitar antes de la implementación.
Tiempo medio hasta la inocencia: cómo demostrar que el problema no es el WiFi
El tiempo medio hasta la inocencia (MTTI) es la métrica clave que define cuánto tiempo dedican los equipos de TI a demostrar que un problema de red no es su culpa. Esta guía detalla una metodología de observabilidad de cinco pasos para eliminar el juego de las culpas en entornos multi-tenant, sustituyendo las acusaciones por pruebas compartidas para reducir el tiempo medio de resolución (MTTR).
Requisitos legales y de cumplimiento para la infraestructura de WiFi compartida
Esta guía de referencia técnica autorizada describe los requisitos legales, normativos y de arquitectura críticos para implementar y gestionar infraestructuras de WiFi compartidas. Ofrece a los responsables de TI, arquitectos de red y operadores de recintos marcos prácticos para garantizar una sólida protección de datos, un estricto cumplimiento de la seguridad de los pagos y un aislamiento de inquilinos de alto rendimiento utilizando estándares empresariales.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.