El CGNAT resuelve un problema real: la escasez de IPv4 permite que decenas o cientos de abonados compartan una misma IP pública. Es una solución pragmática que casi todos los ISPs en España usan en mayor o menor medida. El problema es que, junto con el ahorro en IPs, viene una obligación legal que muchos operadores pequeños ignoran hasta que se encuentran cara a cara con una solicitud policial que no pueden responder.
En Bayma llevamos años operando CGNAT y hemos ayudado a otros operadores a implementarlo correctamente. Este post no es un análisis jurídico (para eso hay abogados especializados en telecomunicaciones), sino una guía técnica y práctica para entender qué tienes que guardar, cómo y durante cuánto tiempo.
La obligación legal: de qué hablamos exactamente
En España, la normativa que regula la retención de datos por parte de los operadores es principalmente la Ley 25/2007 de conservación de datos relativos a las comunicaciones electrónicas, que transpuso la Directiva 2006/24/CE europea. Esta ley, junto con el Real Decreto 424/2005 que regula las condiciones de prestación de servicios de comunicaciones electrónicas, establece las obligaciones de retención.
La sentencia del TJUE de 2014 (caso Digital Rights Ireland) declaró inválida la Directiva 2006/24/CE, lo que generó incertidumbre jurídica en toda Europa. En España, la Ley 25/2007 sigue formalmente en vigor, aunque su aplicación ha sido objeto de debate. La Audiencia Nacional ha interpretado reiteradamente que los operadores siguen obligados a conservar ciertos datos de tráfico.
Para un ISP que opera CGNAT, la obligación práctica concreta es esta: debes ser capaz de responder a la pregunta «¿qué abonado usó esta IP pública en este puerto en este momento?». Sin el log de traducciones NAT, esa pregunta es imposible de responder, aunque tengas todos los demás registros perfectos.
Qué datos hay que guardar y durante cuánto tiempo
Para el caso específico de CGNAT, los datos críticos son las traducciones NAT: para cada sesión (o al menos para cada «binding» de puerto), necesitas registrar:
- IP pública asignada al abonado en ese momento
- Puerto de origen en la IP pública (o el rango de puertos si usas Port Block Allocation)
- IP privada interna del abonado
- Timestamp de inicio y fin de la traducción
- Identificador del abonado que tiene asignada esa IP privada en ese momento (que debe correlacionarse con vuestro sistema de autenticación RADIUS)
El plazo de retención que establece la Ley 25/2007 es de 12 meses para datos de tráfico de acceso a internet. En la práctica, muchos operadores conservan 12 meses y algunos amplían a 18 por precaución.
El volumen de datos que genera el log de CGNAT es considerable si lo haces por sesión individual. Un abonado residencial puede tener cientos de sesiones activas simultáneas. Para 1.000 abonados, hablamos de decenas de millones de registros por día. Por eso es crítico elegir bien el modelo de logging.
Port Block Allocation: el modelo que reduce el volumen de logs
La técnica más usada para hacer manejable el logging de CGNAT es Port Block Allocation (PBA): en lugar de registrar cada sesión individual, asignas al abonado un bloque de puertos fijo (por ejemplo, 512 puertos consecutivos) durante un período. Solo necesitas registrar cuándo se asignó y liberó ese bloque.
El trade-off es que cualquier sesión dentro de ese bloque durante ese período apunta al mismo abonado, lo que es suficiente para responder a una solicitud de identificación. El volumen de logs se reduce en varios órdenes de magnitud: en lugar de millones de registros por día, tienes miles.
El tamaño del bloque de puertos es un parámetro de diseño importante. Bloques demasiado grandes (2.048 o 4.096 puertos) pueden limitar el número de abonados que comparten una IP pública. Bloques demasiado pequeños (64 o 128 puertos) pueden causar problemas a abonados con muchas conexiones simultáneas (torrents, videollamadas, streaming con múltiples streams). En la práctica, 256-512 puertos por abonado es un balance razonable para la mayoría de perfiles residenciales.
Soluciones técnicas: qué usa la gente de verdad
MikroTik con script de logging
MikroTik tiene capacidad nativa de NAT y puede exportar los registros de conexiones via Netflow o syslog. El problema es que el volumen de logs por sesión individual en un MikroTik de tamaño mediano puede desbordar el sistema de logging si no está bien dimensionado. La configuración de PBA en MikroTik requiere scripting personalizado porque no está implementada de forma nativa como en soluciones más enterprise.
Para volúmenes de hasta 500-800 abonados simultáneos, un CCR2004 con logging a servidor externo funciona. Por encima de eso, la carga de CPU del logging empieza a ser significativa.
Soluciones enterprise: Cisco, A10 Networks
Los appliances dedicados de CGNAT (Cisco ASR con el módulo CGv6, A10 Networks Thunder CGN) tienen soporte nativo de PBA y logging estructurado. Son caros (un A10 Thunder de gama media puede estar en el rango de 15.000-40.000 euros) pero son la opción más robusta para volúmenes grandes y tienen soporte de fabricante si un juzgado o la Guardia Civil te pide una certificación del sistema de logging.
Soluciones open source: nftables + pmacct
Para ISPs que quieren control total y tienen capacidad técnica, una combinación de nftables (para el NAT en Linux) con pmacct (para el logging de flujos) sobre hardware commodity es una opción viable. Requiere más trabajo de integración y sobre todo más cuidado en el diseño del sistema de retención y búsqueda de logs, pero el coste es significativamente menor.
Lo crítico aquí es el sistema de indexación y búsqueda: cuando la policía llama un viernes por la tarde con una IP, un timestamp y un número de oficio, necesitas poder responder en minutos, no en horas de búsqueda manual en ficheros de log. Tener los logs bien indexados en una base de datos (PostgreSQL funciona bien para esto) con índices por IP pública, timestamp y rango de puertos es esencial.
El error que cometen los ISPs pequeños
El error más común que veo es no implementar el logging porque «somos pequeños y no vamos a tener ningún problema». Es un razonamiento que entiendo pero que tiene un fallo fundamental: no eres tú quien decide si tienes un problema. Lo decide lo que hagan tus abonados con su conexión.
Conozco el caso de un operador en Andalucía con menos de 800 abonados que recibió una notificación judicial relacionada con descarga de material ilegal de un menor. La IP que figuraba en la denuncia era una IP pública del operador usada en CGNAT. Sin el log de traducciones NAT, era imposible identificar al abonado. El resultado fue una diligencia judicial prolongada, costes legales importantes, y la obligación de implantar el sistema de logging en un plazo reducido bajo supervisión. Lo que habría costado implementar el logging desde el principio: unas pocas horas de trabajo técnico y un servidor con capacidad de almacenamiento razonable.
Qué hacer si ya tienes CGNAT sin logging
Si estás en esa situación ahora mismo, el primer paso es implementar el logging lo antes posible. No esperes. Los pasos básicos son:
- Activar el logging de traducciones NAT en tu dispositivo (con PBA si es posible)
- Enviar los logs a un servidor de almacenamiento externo con redundancia
- Asegurarte de que puedes correlacionar IP privada con abonado en el tiempo (requiere que el log del servidor RADIUS también sea completo)
- Diseñar el sistema de búsqueda para poder responder a una consulta en menos de 15 minutos
- Verificar que los logs se están generando correctamente con una auditoría mensual
En Bayma tenemos experiencia tanto en implementar sistemas de CGNAT desde cero como en auditar y mejorar implantaciones existentes. Si necesitas implantar o revisar tu solución CGNAT, podemos ayudarte. Visita bayma.es/operadores/redes-conectividad y cuéntanos tu situación. El compliance legal no tiene que ser un problema técnico si está bien diseñado desde el principio.