¿Tu internet se cae por saturación de conexiones? El problema del CG-NAT y los límites ocultos

Configurar un laboratorio o sala de informática puede parecer sencillo, pero los problemas de conectividad suelen ser los más frustrantes. Imagina tener 34 equipos cableados y enfrentarte a una situación donde el internet se cae al cargar páginas básicas como Gmail o Wikipedia, mientras que el ping sigue funcionando perfectamente.

Este escenario es un clásico caso de estudio para entender las limitaciones ocultas del hardware de red y los proveedores de servicio. A primera vista, la tentación es culpar a la falta de megas, pero cuando revisamos los datos y vemos que el tráfico total no supera los 100 megas mientras fallan conexiones específicas, nos damos cuenta de que estamos ante algo más complejo.

La clave para resolver esto radica en entender la diferencia entre ancho de banda y la capacidad de gestionar conexiones. Un laboratorio con 34 equipos modernos no se traduce simplemente en 34 conexiones; cada computadora ejecuta navegadores, actualizaciones automáticas y servicios en segundo plano que generan miles de sesiones simultáneas.

Aquí es donde entran en juego los límites ocultos del hardware. El CG-NAT (Conjunto Compartido de Red de Administración) de un proveedor de internet suele tener un límite de sesiones por cliente, o bien el ONT doméstico colapsa su propia tabla NAT al intentar procesar ese volumen de tráfico.

Un síntoma revelador en este tipo de problemas es que el ping funciona pero todo lo demás falla. Esto indica una saturación de la tabla de conexiones (NAT) o del seguimiento de conexiones (conntrack), donde los paquetes HTTP/HTTPS no pueden establecerse correctamente porque la tabla está llena.

La solución práctica no siempre implica pagar por salir del CG-NAT, lo cual a menudo solo resulta en una reducción drástica de velocidad. En su lugar, se debe revisar el estado actual del sistema: verificar las tablas de conexión en MikroTik con comandos como /ip firewall connection print count-only para ver cuántas conexiones hay cuando falla.

Además, limitar las conexiones por host (por ejemplo, a 200-500 por IP) y activar técnicas como FastTrack puede evitar que ciertos equipos maten la red. Acortar los tiempos de conexión TCP también ayuda a liberar entradas de conntrack más rápido, retrasando el colapso hasta que se pueda identificar si el cuello está en el Mikrotik o en el proveedor.

En conclusión, este caso demuestra que diagnosticar problemas de conectividad requiere mirar más allá del ancho de banda. Al aislar variables como el ONT y las tablas de conexión, podemos evitar soluciones costosas y mantener la red operativa bajo carga real.