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 NAT de calidad de operador (CGNAT) y traducción de direcciones de puerto (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 asignación de bloques de puertos (PBA), estrategias de registro que cumplen con la GDPR y una ruta de migración dual-stack IPv6. La guía es esencial para cualquier operador que gestione cientos o miles de dispositivos simultáneos en un pool de IP públicas limitado, proporcionando orientación de configuración práctica, casos de estudio del mundo real y análisis de ROI.
Video overview
Escucha 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 administradores de TI y los arquitectos de red en entornos multi-inquilino de alta densidad - como residencias de estudiantes, hospitality y grandes espacios públicos - se enfrentan a importantes desafíos operativos. Una sola residencia de estudiantes con 1,000 residentes puede generar más de 7,000 dispositivos conectados por IP de manera concurrente. Las arquitecturas estándar de Port Address Translation (PAT) fallan a esta escala, lo que resulta en el agotamiento de puertos, conexiones caídas y una experiencia de usuario degradada.
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 RFC 6598 e implementar una asignación estratégica de bloques de puertos (PBA), los operadores de red pueden lograr una alta densidad de suscriptores - hasta 128 usuarios por IP pública - mientras mantienen el cumplimiento con el GDPR y las regulaciones de interceptación legal. Para los establecimientos 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) de adquirir bloques de IPv4 adicionales.
Análisis técnico detallado
El problema de escala en las residencias de estudiantes
La densidad de dispositivos en las residencias de estudiantes modernas es diferente a casi cualquier otro entorno de red gestionada. Un solo residente suele conectar un smartphone, una laptop, una smart TV, una consola de videojuegos y al menos un dispositivo inteligente para el hogar. Con un promedio de cinco a siete dispositivos por residente, un campus de 1,000 camas presenta una carga de sesiones concurrentes que supera incluso a la de un hotel de tamaño comparable. El desafío se complica aún más por los patrones de uso: en las horas pico de la noche (18:00 - 23:00) se observa una actividad de alto ancho de banda casi simultánea en videojuegos, streaming de video y redes sociales, todo ello manteniendo conexiones persistentes en segundo plano.
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 Medio Oriente, llegó a su política final de asignación /8 en 2019. El costo de adquirir bloques IPv4 públicos adicionales en el mercado libre se sitúa ahora entre $40 y $60 USD 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 sola 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 residencias de estudiantes densas, la proliferación de aplicaciones en segundo plano (sincronización en la nube, plataformas de mensajería, servicios de streaming) significa que un solo usuario puede 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 como tiempos de espera de aplicaciones agotados, llamadas de VoIP fallidas y un aumento en los tickets de soporte técnico.
Arquitectura CGNAT (NAT444)
Para superar las limitaciones de NAT de un solo nivel, las redes empresariales deben adoptar una arquitectura CGNAT (Carrier-Grade NAT), específicamente el modelo NAT444. Este nombre se refiere a las tres capas de espacio de direcciones IPv4 involucradas en la cadena de traducción.
Nivel 1 - Capa de CPE / Punto de acceso: A los dispositivos de los suscriptores se les asignan direcciones IP privadas del espacio RFC 1918 (por ejemplo, 192.168.x.x). El punto de acceso o equipo en las instalaciones del cliente (CPE) realiza la primera traducción NAT.
Nivel 2 - Gateway CGNAT: El CPE traduce la dirección privada RFC 1918 al espacio de direcciones compartido 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 el gateway 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 multi-inquilino complejos.
Nivel 3 - Internet pública: El gateway 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.
Asignación de bloques de puertos: Decisiones de diseño críticas
La opción de configuración más crítica en una implementación de CGNAT es la estrategia de asignación de puertos. Existen dos enfoques:
Asignación dinámica de puertos (DPA): Los puertos se asignan por sesión desde un grupo compartido. Esto maximiza la eficiencia en el uso de los puertos, pero genera un registro de log por cada inicio y cierre de sesión, lo que crea una enorme carga de cumplimiento e infraestructura a gran escala.
Asignación de bloques de puertos (PBA): A cada suscriptor se le asigna un bloque contiguo de puertos al iniciar su primera sesión. El bloque permanece asignado hasta que la sesión del suscriptor termina. Este enfoque solo genera logs cuando se asigna y se libera un bloque, reduciendo el volumen de registros hasta en un 98%.
| Parámetro de configuración | Valor recomendado | Justificación |
|---|---|---|
| Puertos por suscriptor (tamaño de bloque PBA) | 500 | Suficiente para el uso de aplicaciones web modernas sin agotar el grupo de puertos |
| Máximo de sesiones concurrentes por suscriptor | 2,000 | Evita que un solo dispositivo infectado agote el grupo de puertos |
| Tiempo de espera de sesión (TCP establecido) | 7,440 segundos (RFC 5382) | Se alinea con las recomendaciones de la IETF para el comportamiento de NAT |
| Tiempo de espera de sesión (UDP) | 300 segundos | Evita que los mapeos UDP inactivos consuman espacio de puertos |
Referencia de la industria: NFWare, un proveedor experto en CGNAT con implementaciones en más de 100 ISPs, recomienda un máximo de 128 suscriptores por IP pública con 500 puertos asignados por suscriptor. Ir más allá de este límite - por ejemplo, llegar a 256 suscriptores por IP con 250 puertos cada uno - aumenta significativamente el riesgo de caída de sesiones durante las horas pico de carga.
Dual-Stack IPv6 como la 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 una implementación de Dual-Stack: ejecutar IPv6 de forma nativa junto con IPv4 con CGNAT. Los dispositivos modernos y las principales CDN (Google, Netflix, Meta, Cloudflare) prefieren firmemente IPv6 cuando está disponible. En un entorno dual-stack bien configurado, entre el 60% y el 70% del tráfico total puede desviarse a IPv6, lo que reduce drásticamente la carga en el grupo de direcciones IPv4 de CGNAT y prolonga su vida útil efectiva.
Para entornos de atención médica y de transporte donde el soporte para 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: Auditoría de la asignación actual de IP y densidad de dispositivos
Antes de implementar CGNAT, establezca una línea base. Recopile los siguientes datos de sus sistemas de gestión de red existentes:
- Conteos máximos de dispositivos concurrentes por subred
- Promedio y pico de sesiones por dispositivo
- Porcentaje actual de utilización de IP públicas
- Configuraciones de tiempo de espera de NAT existentes
Estos datos informan directamente el tamaño de su 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 grado operador. Planifique la división en 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 socios de interconexión.
Paso 3: Implementar y configurar las puertas de enlace CGNAT
La puerta de enlace CGNAT suele ser un dispositivo de hardware dedicado o una función de red virtualizada (VNF) que se ejecuta en hardware de servidor comercial. Parámetros clave de configuración:
- Pool de NAT: Asigne su bloque IPv4 público al pool de NAT. Asegúrese de que el tamaño del pool sea adecuado para su relación de suscriptores por IP objetivo.
- Configuración de PBA: Establezca el tamaño del bloque en 500 puertos. Configure el máximo de bloques por suscriptor en 1 (con la opción de ampliarlo a 2 si un suscriptor 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 suscriptor, IP pública asignada, inicio del bloque de puertos asignado, fin del bloque, marca de tiempo de asignación y marca de tiempo de liberación.
- Límites de sesión: Aplique un máximo de 2,000 sesiones concurrentes por suscriptor 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 ocurrir en o antes del límite de NAT de Nivel 1. Esto garantiza que el proveedor de identidad pueda mapear con precisión las direcciones MAC y las credenciales de usuario a direcciones IP internas únicas antes de que el tráfico se agregue al pool de CGNAT. La plataforma de Purple maneja 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 implementaciones de acceso sin contraseña, como se describe en Cómo un asistente de WiFi permite el acceso sin contraseña en 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 upstream. 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 gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.
Mejores prácticas
Implemente NAT determinista donde sea posible. El NAT determinista utiliza un mapeo algorítmico entre la dirección IP interna de un suscriptor y su IP pública y bloque de puertos asignados. Dado que el mapeo se puede calcular matemáticamente, no es necesario mantener o registrar una tabla de sesiones; el mapeo se puede descifrar mediante ingeniería inversa bajo demanda para fines de interceptación legal. Este es el estándar de oro para implementaciones conscientes del cumplimiento.
Distribuya la carga de la puerta de enlace de CGNAT. Evite concentrar todo el tráfico de CGNAT a través de un solo dispositivo. Distribuya las puertas de enlace a lo largo del campus o los edificios para evitar un único punto de falla. Las puertas de enlace distribuidas también mitigan el riesgo de reputación de IP: si una IP pública en el pool es marcada por una CDN debido a patrones de tráfico sospechosos (problemas de CAPTCHA), solo un subconjunto de usuarios se verá afectado.
Monitoree activamente la reputación de IP. Suscríbase a fuentes de reputación de IP (por ejemplo, Spamhaus, SURBL) y monitoree las IP de su pool de NAT público. Mantenga un pool de reserva de IP limpias para rotarlas si una dirección activa entra en una lista negra. Esto es particularmente crítico en alojamientos para estudiantes, donde un número pequeño de usuarios puede realizar actividades que activen alertas de abuso.
Aplique límites de sesión por suscriptor. Un límite estricto de 2,000 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 el monitoreo del rendimiento de la red, consulte nuestra guía sobre cómo medir la intensidad de la señal y la cobertura de WiFi.
Alinee con 802.1X para el control de acceso. La implementación de 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 un registro de auditoría claro para fines de interceptación legal.
Solución de problemas y mitigación de riesgos
Carga de registro y cumplimiento
En el Reino Unido y Europa, bajo el GDPR y la Ley de Poderes de Investigación de 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 específica. Esta es una obligación legal no negociable.
Riesgo: Con CGNAT dinámico, registrar cada configuración y finalización de sesión genera terabytes de datos de syslog diariamente. Una implementación de 1,000 usuarios con asignación dinámica puede generar 500 millones de entradas de registro al día. Esto sobrecarga la infraestructura SIEM, infla los costos de almacenamiento y hace que las investigaciones forenses sean poco prácticas.
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, por lo general 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 sola IP pública, el volumen de tráfico agregado puede activar protecciones de límite de velocidad o sistemas anti-bots 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 en múltiples IPs públicas. Monitoree activamente las puntuaciones de reputación. Considere implementar DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT) para prevenir problemas de reputación basados en DNS. Oriente a los usuarios sobre que las solicitudes ocasionales de CAPTCHA son un comportamiento conocido en entornos de IP compartida.
Problemas de compatibilidad de aplicaciones
Algunas aplicaciones - particularmente los protocolos peer-to-peer, ciertas implementaciones de VoIP y las plataformas de juego más antiguas - dependen del mapeo de puertos persistente o del inicio de conexiones entrantes. Estas pueden fallar bajo un doble NAT.
Mitigación: Para VoIP, asegúrese de que su gateway CGNAT sea compatible con ALG (Application Layer Gateway) para SIP. Para videojuegos, considere implementar un proxy UPnP o una VLAN de juegos dedicada con un pool de NAT separado 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 de CGNAT.
ROI e impacto empresarial
Ahorros en gastos de capital (CapEx)
La implementación de CGNAT proporciona ahorros inmediatos y sustanciales de CapEx. A una tasa de mercado de $50 USD por dirección IPv4, una universidad de 5,000 camas que requiera una relación de dispositivo a IP de 1:1 necesitaría comprar aproximadamente 35,000 direcciones IP - con un costo de $1.75 millones de USD. Al implementar CGNAT con una relación de 128:1, el mismo despliegue requiere menos de 300 IPs públicas, lo que reduce los costos de adquisición de IP a aproximadamente $15,000 USD.
Incluso después de considerar el costo del hardware de gateway CGNAT o de las funciones de red virtualizadas (que suelen oscilar entre $20,000 y $80,000 USD para un despliegue a escala de campus), los ahorros netos son sustanciales.
Reducción de gastos operativos (OpEx)
La conectividad estable reduce directamente los costos indirectos de la mesa de ayuda. Los eventos de agotamiento de puertos - el principal modo de falla 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 falla, lo que resulta en una reducción estimada del 30 al 40% en el volumen de soporte técnico relacionado con la red.
Ventaja competitiva en alojamiento estudiantil
In the competitive student housing market, network quality is a primary selection criterion for prospective tenants. Operators who can demonstrate consistent, high-throughput connectivity - validated through WiFi Analytics dashboards showing uptime, session quality, and device density metrics - command premium rental rates and achieve higher occupancy. This infrastructure stability is also the foundation for deploying advanced location-based services, as highlighted in Purple launched offline maps mode for seamless, secure navigation for WiFi hotspots.
Case Study 1: 800-Bed University Residence Hall
An 800-bed residence hall operated by a UK university was experiencing chronic connectivity issues during peak evening hours. Investigation revealed that their single-level PAT configuration, which was using a /29 public subnet (6 usable IPs), was exhausting available ports by 19:30 every evening. The operator deployed a CGNAT solution with PBA (500 ports per subscriber, 128 subscribers per IP), upgraded to a /27 public subnet (30 usable IPs), and enabled IPv6 dual-stack. Post-deployment metrics showed a 94% reduction in port exhaustion incidents compared to the initial dynamic allocation pilot, a 38% reduction in network-related helpdesk tickets, and a 65% reduction in CGNAT log volume. Within 60 days of deployment, the IPv6 offload rate reached 62%.
Case Study 2: 1,200-room Purpose-Built Student Accommodation (PBSA) Operator
A private PBSA operator managing three sites across two UK cities needed to standardise their network architecture before opening a fourth site. Their existing infrastructure used a mix of single-level NAT and ad-hoc VLAN segmentation with no coherent logging strategy. A CGNAT deployment with deterministic NAT was implemented across all three sites, enabling mathematically calculable subscriber-to-IP mapping without session logging overhead. This approach satisfied the operator's legal team regarding lawful intercept compliance, eliminated SIEM storage costs for session logs, and provided a consistent architecture template for the fourth site. The operator also integrated Purple's Guest WiFi platform for Captive Portal authentication, establishing identity binding upstream of the CGNAT gateway to ensure accurate user attribution in analytics reports.
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 puerta de enlace 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 enfrentan a CGNAT cuando una sola IP pública es insuficiente para dar servicio a todos los dispositivos de una red. En los alojamientos para 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 involucra tres capas de espacio de direcciones IPv4: direcciones privadas del suscriptor (RFC 1918), direcciones compartidas de clase operador (RFC 6598) y direcciones de internet pública. El nombre hace referencia a las tres redes IPv4 atravesadas.
NAT444 es la arquitectura estándar para implementaciones de CGNAT en entornos multiinquilino. Los arquitectos de redes deben comprender el modelo de tres capas para diseñar correctamente la red intermedia y evitar la superposición de direcciones.
Espacio de direcciones compartido RFC 6598
El bloque de direcciones IPv4 100.64.0.0/10 (100.64.0.0 a 100.127.255.255) reservado por IANA para su uso en la red intermedia entre un CPE y una puerta de enlace CGNAT. Este espacio no es enrutable en el internet público y está diseñado específicamente para evitar conflictos de direcciones en implementaciones NAT444.
Los equipos de TI deben utilizar el RFC 6598 - no el RFC 1918 - para la red intermedia de CGNAT. El uso de RFC 1918 para este segmento crea riesgos de superposición de direcciones cuando se utilizan los mismos rangos de RFC 1918 en las redes de los suscriptores.
Port Block Allocation (PBA)
Una estrategia de asignación de puertos CGNAT en la que se asigna un bloque contiguo de puertos (por ejemplo, 500 puertos) a cada suscriptor durante la duración de su sesión, en lugar de asignar puertos individualmente por conexión. Definido en RFC 7422.
PBA es el enfoque recomendado para implementaciones de CGNAT que cumplan con el GDPR. Reduce la sobrecarga de registro 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 operativamente viable a escala.
Deterministic NAT
Una configuración de CGNAT en la que la asignación entre la dirección IP interna de un suscriptor y su IP pública y bloque de puertos asignados se calcula mediante un algoritmo, sin mantener una tabla de sesiones. La asignación es matemáticamente reversible, lo que permite la identificación del suscriptor sin necesidad de recuperar registros.
Deterministic NAT es el estándar de oro para implementaciones conscientes del cumplimiento normativo. Elimina por completo la sobrecarga de registro al tiempo que satisface los requisitos de interceptación legal, ya que el suscriptor puede ser identificado a partir de una IP pública, puerto y marca de tiempo utilizando 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 se conoce como sobrecarga de NAT o NAT de muchos a uno.
PAT es el NAT estándar de un solo nivel utilizado en la mayoría de los routers perimetrales empresariales. Es el predecesor de CGNAT y es insuficiente para entornos multiinquilino densos debido al agotamiento de puertos a escala.
Tabla de sesiones
Una estructura de datos mantenida por una gateway de NAT que registra el mapeo entre la dirección IP y puerto internos (privados), y la dirección IP y puerto externos (públicos), para cada conexión activa. La tabla de sesión es el principal recurso 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 puertas de enlace CGNAT. Una implementación de 1,000 suscriptores con un máximo de 2,000 sesiones por suscriptor requiere una capacidad de tabla de sesiones de al menos 2 millones de entradas. Dimensionar de menos la tabla de sesiones provoca fallas en la conexión.
Dual-Stack
Una configuración de red en la que los protocolos IPv4 e IPv6 están activos simultáneamente en la misma infraestructura de red y dispositivos finales. Los dispositivos con capacidad dual-stack preferirán IPv6 para las conexiones a destinos compatibles con IPv6.
Dual-stack es la estrategia de transición recomendada para implementaciones de CGNAT. Al desviar el tráfico compatible con IPv6 hacia la ruta IPv6 nativa, dual-stack reduce la carga en el pool de IPv4 en CGNAT y proporciona una ruta 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 suscriptores en implementaciones de CGNAT. Los arquitectos de red deben asegurarse de que los rangos RFC 1918 utilizados en las redes de suscriptores no se traslapen con los utilizados en la red intermedia de CGNAT, razón por la cual se utiliza RFC 6598 para la capa intermedia.
Intercepción Legal
La intercepción de comunicaciones legalmente autorizada por parte de las agencias de aplicación de la ley. En el Reino Unido, está regulada por la Investigatory Powers Act 2016. Los operadores de red deben ser capaces de identificar al suscriptor asociado con una dirección IP pública, puerto y marca de tiempo específicos al recibir una solicitud de intercepción legal.
El cumplimiento de la intercepción legal es el principal motor de los requisitos de registro de CGNAT. Los operadores deben conservar suficientes registros para identificar a los suscriptores a partir de los datos de IP pública y puerto. PBA y Deterministic NAT son las dos arquitecturas que hacen que esto sea viable a escala sin saturar la infraestructura de registro.
Ejemplos resueltos
Un complejo de alojamiento estudiantil de 600 camas utiliza actualmente una única subred pública /29 (6 IP útiles) con PAT estándar. Durante las horas pico de la noche (19:00-23:00), los usuarios reportan fallas generalizadas de conectividad. El equipo de red ha confirmado el agotamiento de puertos en el enrutador PAT. El operador tiene presupuesto para hardware de gateway CGNAT pero no puede adquirir IP públicas adicionales más allá de una /27 (30 IP útiles). Diseñe un despliegue de CGNAT que elimine el problema de agotamiento de puertos y soporte un crecimiento futuro a 900 camas.
Paso 1 - Evaluación de línea base: Con 600 camas a 5 dispositivos por ocupante, el conteo máximo de dispositivos simultáneos es de aproximadamente 3,000. A 500 puertos por suscriptor (PBA), cada IP pública soporta 128 suscriptores. Con 30 IP útiles en la /27, la capacidad máxima teórica de suscriptores es de 3,840 - suficiente para 900 camas a 4.3 dispositivos por ocupante. Paso 2 - Red intermedia RFC 6598: Asigne 100.64.0.0/20 para la red intermedia de calidad de operador, proporcionando 4,096 direcciones para el tráfico de CPE a la gateway CGNAT. Subred por ala del edificio: 100.64.0.0/24, 100.64.1.0/24, etc. Paso 3 - Dimensionamiento de la gateway CGNAT: Despliegue una gateway CGNAT con una capacidad de tabla de sesiones de al menos 768,000 entradas (3,000 suscriptores × 2,000 sesiones máximas por suscriptor, con un 20% de margen de seguridad). Configure PBA con bloques de 500 puertos. Establezca el máximo de bloques por suscriptor en 1, permitiendo el desbordamiento a 2 bloques para los suscriptores que superen las 500 sesiones simultáneas. Paso 4 - Dual-Stack IPv6: Habilite IPv6 en todos los puntos de acceso. Distribuya prefijos /64 a través de SLAAC. Apunte a una descarga del 60% de IPv6 en un plazo de 90 días, lo que reduce efectivamente la carga de IPv4 CGNAT a 1,200 suscriptores IPv4 simultáneos - muy dentro de la capacidad de la /27. Paso 5 - Registro: Configure syslog hacia el SIEM únicamente con eventos de asignación/liberación de bloques PBA. Conserve los registros durante un mínimo de 12 meses. Paso 6 - Límites de sesión: Aplique un máximo de 2,000 sesiones por suscriptor en la gateway CGNAT para evitar abusos.
Un operador de 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 por día, lo que está abrumando al SIEM y haciendo inviable cumplir con las solicitudes de interceptación legal de las fuerzas del orden. Rediseñe la estrategia de registro para cumplir con las obligaciones de interceptación legal de UK GDPR y del Reino Unido mientras reduce el volumen de registros a un nivel manejable.
Paso 1 - Migrar a la Asignación de Bloques de Puertos: Reemplace la asignación dinámica de puertos con PBA a 500 puertos por suscriptor. 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 un promedio 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% en comparación con la línea base de asignación dinámica. Paso 2 - Esquema de Registros: Asegúrese de que cada entrada de registro de PBA capture: (a) dirección IP interna del suscriptor, (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 suscriptor (dirección MAC o nombre de usuario de RADIUS). Paso 3 - Opción de NAT Determinista: Si la plataforma de CGNAT lo admite, migre a NAT Determinista. Esto elimina por completo el registro para operaciones de rutina, ya que el mapeo es computable matemáticamente. Conserve los registros de PBA únicamente para casos de desbordamiento no deterministas. Paso 4 - Política de Retención: Conserve los registros durante 12 meses en un almacenamiento 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 ante 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, incluyendo la fórmula para calcular a la inversa el suscriptor a partir de una IP pública, puerto y marca de tiempo bajo NAT Determinista.
¿Un equipo de TI universitario informa que los estudiantes experimentan desafíos frecuentes de CAPTCHA y limitación de velocidad por parte de Google, Netflix y plataformas de videojuegos. La investigación revela que 200 estudiantes comparten una sola dirección IP pública a través de CGNAT. Se le ha informado al equipo que adquirir más direcciones IP públicas no es posible a corto plazo. ¿Qué mitigaciones inmediatas se pueden implementar sin cambiar la asignación de IP?
Paso 1 - Reducir la Densidad de Suscriptores: 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é completamente habilitada; si el 60% del tráfico se descarga a IPv6, el recuento real de suscriptores de IPv4 disminuye a aproximadamente 80 por IP, muy dentro 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 puerta de enlace CGNAT lo admite, configure la rotación periódica de la IP pública asignada a cada grupo de suscriptores. Esto evita que una sola IP acumule una reputación negativa persistente. Paso 3 - Optimización de DNS: Asegúrese de que los solucionadores de 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 innecesariamente, se enruta a través de CGNAT cuando podría usar IPv6 de forma nativa. Paso 4 - Ajuste de Tiempo de Espera de Sesión: Reduzca los tiempos de espera de sesión UDP del valor predeterminado (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 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 brinda servicio a una institución educativa legítima.
Preguntas de práctica
Q1. Un campus de alojamiento estudiantil de 2,000 camas tiene una subred pública /26 (62 IPs utilizables). El equipo de red está planeando una implementación de CGNAT. Calcule: (a) el número máximo de suscriptores que se pueden soportar con la relación recomendada de 128:1, (b) la capacidad total de puertos disponible, (c) el tamaño de bloque PBA recomendado y (d) si el /26 existente es suficiente o si se requieren IPs adicionales.
Sugerencia: Comience con el total de IPs utilizables en un /26, luego aplique la relación de suscriptores de 128:1. Compare el resultado con el recuento de dispositivos para un campus de 2,000 camas con una proporción realista de dispositivos por ocupante. Considere el desvío de tráfico mediante IPv6 dual-stack en su recomendación final.
Ver respuesta modelo
Un /26 proporciona 62 IPs públicas utilizables. A 128 suscriptores por IP, la capacidad máxima de IPv4 en CGNAT es de 62 × 128 = 7,936 suscriptores. Con 5 dispositivos por ocupante, 2,000 camas generan aproximadamente 10,000 dispositivos concurrentes. Sin IPv6, el /26 es insuficiente (7,936 < 10,000). Sin embargo, con IPv6 dual-stack logrando un 60% de desvío, la carga efectiva de IPv4 disminuye a aproximadamente 4,000 dispositivos, lo cual está muy dentro de la capacidad de 7,936 del /26. El tamaño de bloque PBA recomendado es de 500 puertos por suscriptor. Capacidad total de puertos: 62 IPs × 64,000 puertos utilizables = 3,968,000 puertos. A 500 puertos por suscriptor: 3,968,000 / 500 = 7,936 suscriptores como máximo. Recomendación: Implementar CGNAT con PBA a 500 puertos/suscriptor, habilitar IPv6 dual-stack como requisito previo y el /26 existente será suficiente. Si no se puede garantizar un desvío 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 inquietudes de cumplimiento. El equipo legal del operador recibió una solicitud de interceptación legal por parte de las fuerzas del orden para una dirección IP pública específica (203.0.113.45), puerto 51432, en la marca de tiempo 2025-11-15 21:47:33 UTC. La puerta de enlace 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á tomando más de 4 horas por solicitud. Identifique la causa raíz y proponga una remediació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 la asignación dinámica en comparación con PBA, y cómo el Deterministic NAT 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 por 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 remediación 1 (PBA): Migrar a 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 sola consulta indexada sobre 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 remediación 2 (NAT determinista): Si la plataforma lo admite, migrar a NAT determinista. El puerto 51432 se puede revertir matemáticamente a la IP interna del suscriptor sin 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 un nuevo desarrollo de PBSA de 800 camas. El ISP ascendente proporcionó una subred pública /27 y confirmó que el tránsito IPv6 está disponible. El operador también desea implementar la plataforma Purple's Guest WiFi para la autenticación de Captive Portal. Describa la ubicación correcta de la autenticación de Captive Portal en relación con la puerta de enlace CGNAT y explique por qué una ubicación incorrecta crea un riesgo de cumplimiento.
Sugerencia: Considere qué información necesita capturar el Captive Portal (identidad del usuario, MAC del dispositivo, IP interna) y en qué punto de la cadena de traducción NAT esta información sigue estando disponible. Piense en lo que sucede con la dirección IP interna después de que pasa a través de la puerta de enlace CGNAT.
Ver respuesta modelo
La autenticación de Captive Portal debe ocurrir en o antes del límite de NAT de Nivel 1, es decir, en la capa del punto de acceso o CPE, antes de que el tráfico ingrese a la red intermedia RFC 6598. Ubicación correcta: La plataforma Purple's Guest WiFi autentica al usuario en el punto de acceso. La plataforma registra la vinculación: identidad de usuario → dirección MAC → IP interna RFC 1918 → marca de tiempo. Esta vinculación se establece antes de que la puerta de enlace CGNAT realice su traducción. Luego, la puerta de enlace CGNAT asigna la IP RFC 1918 a una IP pública y un bloque de puertos, y el registro de PBA registra: IP RFC 1918 → IP pública → bloque de puertos → marca de tiempo. Ambos registros se pueden unir mediante la IP RFC 1918 y la marca de tiempo para producir una cadena completa: identidad de usuario → IP pública + puerto. Ubicación incorrecta (Captive Portal después de la puerta de enlace CGNAT): Si la autenticación ocurre después de la puerta de enlace CGNAT, la plataforma solo ve la IP pública y el puerto, no la IP interna. En este punto, múltiples usuarios detrás de la misma IP de CGNAT son indistinguibles. La plataforma no puede crear una vinculación confiable de usuario a IP, lo que imposibilita la atribución de interceptación legal y viola 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 precisa de usuarios tanto en la plataforma de analíticas como en la cadena de registros de cumplimiento.
Continúe leyendo esta serie
Por qué el WiFi para huéspedes estilo hotel falla en los edificios residenciales
Podrá diagnosticar por qué los residentes en bloques BTR, residencias de estudiantes y MDU siguen reportando fallas de WiFi, y elegir el modelo de autenticación que las solucione. La respuesta es una clave iPSK por hogar en sus puntos de acceso existentes, manteniendo una red con Captive Portal independiente para los visitantes.
Diseño de redes WiFi para edificios de oficinas multi-inquilino
Esta guía proporciona a los directores de TI, arquitectos de red y CTO un plano neutral respecto a proveedores para diseñar redes WiFi escalables, seguras e aisladas en edificios de oficinas multi-inquilino. Abarca la segmentación de VLAN bajo IEEE 802.1Q, la asignación dinámica de VLAN a través de 802.1X y RADIUS, la planificación de RF para entornos de alta densidad y consideraciones de cumplimiento bajo GDPR y PCI-DSS. Los operadores de recintos y administradores de edificios encontrarán orientación de arquitectura accionable, casos de estudio del mundo real y errores de configuración que deben evitar antes de la implementación.
Tiempo promedio de inocencia: cómo demostrar que no es un problema de WiFi
El tiempo promedio de inocencia (MTTI) es la métrica crítica 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 culpas en entornos multi-tenant, reemplazando los señalamientos con evidencia compartida para reducir el tiempo promedio de resolución (MTTR).
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.