Si la conversión del tráfico móvil ha caído repentinamente y el formulario de registro o pago muestra un error 403 a clientes reales, lo más probable es que no sea un hacker, sino su propio WAF. El cortafuegos ve miles de solicitudes desde una sola dirección IP de un operador de telefonía móvil y lo interpreta como un DDoS o un ataque de fuerza bruta. En realidad, detrás de esta IP hay cientos o miles de personas comunes: esta es la tecnología CGNAT. Vamos a ver cómo detectarlo y solucionarlo sin abrir una brecha para ataques reales.
Qué es CGNAT y por qué crea un problema
CGNAT (Carrier-Grade NAT) es una tecnología que los operadores de telefonía móvil utilizan debido a la escasez de direcciones IPv4. En lugar de asignar a cada suscriptor una IP pública única, el operador "esconde" a miles de usuarios detrás de una o varias direcciones compartidas. Para el sitio, esto se ve así: desde una IP llega tráfico de cientos de personas diferentes al mismo tiempo: diferentes dispositivos, diferentes navegadores, diferentes comportamientos, pero la misma dirección externa.
Para un servidor web normal, esto no es un problema: simplemente procesa las solicitudes. Pero para los sistemas de protección que cuentan las solicitudes por unidad de tiempo desde una IP, esto parece una anomalía. Imagina: en un minuto llegan 200 solicitudes a la página de inicio desde una dirección. Para el WAF, este es un patrón clásico de fuerza bruta o scraping. Y en realidad, pueden ser 150 clientes reales de un operador móvil en tu región que simplemente abrieron el sitio al mismo tiempo después de una campaña publicitaria o una publicación en redes sociales.
El problema se manifiesta especialmente agudamente en países con alta densidad de internet móvil: los operadores agrupan una enorme cantidad de suscriptores detrás de un número mínimo de IP externas. Por eso, es necesario probar el comportamiento del sitio no desde una IP de centro de datos normal, sino precisamente desde proxies móviles, que realmente pasan a través de la infraestructura CGNAT del operador: solo así se puede reproducir la misma imagen que ve el WAF de los usuarios reales.
Por qué WAF ve una amenaza en CGNAT
La mayoría de las soluciones WAF — Cloudflare, AWS WAF, Imperva, módulos integrados de Nginx/ModSecurity — utilizan limitación de tasa por dirección IP como mecanismo básico de protección contra bots y DDoS. La lógica es simple: si desde una IP hay más de N solicitudes en T segundos, bloqueamos o mostramos un captcha. Esta regla funciona muy bien para ataques clásicos desde un solo dispositivo, pero se rompe completamente con el tráfico CGNAT.
Hay varios escenarios típicos donde esto falla:
- Limitación de tasa por IP. El límite "100 solicitudes por minuto desde una IP" es normal para el tráfico de centros de datos, pero catastrófico para una región móvil con un millón de suscriptores detrás de una sola dirección.
- Puntuación de comportamiento. Si el sistema acumula "reputación" de la IP basada en el historial de solicitudes, un solo usuario "malo" detrás de CGNAT puede arruinar la reputación de la dirección para miles de clientes honestos posteriores.
- Heurística geográfica. A veces, el WAF marca una IP como sospechosa si ve saltos bruscos de actividad que no son propios de un "usuario normal": el comportamiento de una dirección CGNAT es precisamente así: picos de carga en horas de actividad de la audiencia.
- Bloqueo por ASN del operador. Algunas reglas WAF bloquean rangos completos de ASN de operadores móviles si anteriormente se realizaron ataques desde esos rangos: todos los clientes del operador en el país quedan afectados.
En resumen: cuanto más rígido esté configurado el WAF "de fábrica", mayor será la probabilidad de que esté bloqueando no a bots, sino a tu verdadera audiencia móvil, especialmente si el negocio está orientado a países con internet móvil desarrollado y una alta proporción de tráfico CGNAT.
Qué riesgos representa para el negocio: clientes y dinero perdidos
El problema de los bloqueos por CGNAT rara vez es visible en la analítica estándar. Google Analytics y Yandex.Metrica simplemente no registran a quienes reciben un error 403 a nivel de WAF: tales visitas a menudo ni siquiera llegan al contador. Como resultado, el marketero ve una caída en la conversión, pero no entiende la razón y comienza a optimizar creativos y páginas de destino, aunque el problema está en la infraestructura.
Consecuencias reales para diferentes segmentos de negocio:
- E-commerce. Un comprador desde internet móvil no puede completar el pedido: el formulario de pago muestra un error, el carrito se pierde. Pérdidas directas en ingresos, especialmente notables después de lanzar publicidad en TikTok Ads o Facebook Ads, donde el tráfico principal es móvil.
- SaaS y registros. Un usuario intenta registrarse o iniciar sesión, recibe un captcha en cada paso o un bloqueo: se va a la competencia.
- Contenido y publicidad. El tráfico publicitario desde dispositivos móviles se "cae" masivamente en la página de destino, el presupuesto publicitario se gasta, pero no hay conversiones: los algoritmos de las plataformas publicitarias interpretan esto como baja calidad de la audiencia y aumentan el costo por clic.
- Servicio de atención al cliente. Aumenta la cantidad de consultas "su sitio no se abre", "no puedo registrarme": y el soporte técnico no ve el problema, porque ellos mismos acceden desde un escritorio a través de Wi-Fi de oficina sin CGNAT.
Lo más desagradable es que estos bloqueos son difíciles de diagnosticar a posteriori, porque el registro del WAF muestra una única IP "sospechosa" con un enorme número de solicitudes, y el administrador ve en esto una confirmación de la corrección del bloqueo, y no un falso positivo.
6 verificaciones desde IP móviles para encontrar el problema
Para entender si su WAF está bloqueando a clientes móviles honestos, es necesario reproducir las condiciones reales de CGNAT, es decir, probar el sitio desde verdaderas IP móviles de diferentes operadores y regiones. Aquí hay una lista de verificación práctica de 6 verificaciones.
Verificación 1: Acceso masivo desde una IP móvil
Configure varias sesiones paralelas a través de la misma IP móvil (esto es natural para proxies con CGNAT del operador) y realice 50-100 acciones normales: abrir páginas, agregar al carrito, navegar entre secciones. Si después de un cierto umbral comienza a aparecer un captcha o un 403, esta es la primera señal del problema.
Verificación 2: Cambio de User-Agent desde una IP
Una dirección CGNAT atiende diferentes dispositivos: iPhone, Android, diferentes navegadores. Ejecute solicitudes con diferentes cadenas de User-Agent a través de una IP y verifique si se activa la regla WAF de "variabilidad sospechosa de dispositivos desde una dirección".
Verificación 3: Prueba en formularios críticos
Realice todo el recorrido del cliente: registro, autorización, finalización de pedido, pago, precisamente a través de la IP móvil del operador. A menudo, el WAF está configurado de manera más agresiva precisamente en los formularios de entrada de datos (inicio de sesión, pago), donde el riesgo de fuerza bruta es mayor, y este es el primer lugar donde se pierden clientes reales.
Verificación 4: Verificación con diferentes operadores y regiones
El comportamiento de CGNAT varía entre diferentes operadores y en diferentes países: en algunos lugares, detrás de una IP se esconden 50 suscriptores, en otros 5000. Pruebe el sitio desde IP móviles de varios operadores en las geografías clave para el negocio, para entender si hay especificidades regionales en los bloqueos.
Verificación 5: Análisis de la respuesta del servidor por códigos y encabezados
Registre no solo el hecho del bloqueo, sino el código HTTP exacto y los encabezados de respuesta (por ejemplo, cf-mitigated: challenge en Cloudflare). Esto ayudará a entender qué mecanismo de protección se activó: limitación de tasa, detección de bots o regla geográfica.
Verificación 6: Monitoreo a largo plazo de la reputación de la IP
Repita la prueba desde la misma IP móvil durante varios días. Si el acceso empeora con el tiempo sin razones visibles de su parte, significa que el sistema de puntuación acumulativa "estropea" la reputación de la dirección debido a la actividad de otros suscriptores detrás del mismo CGNAT, y este es un problema sistémico, no puntual.
Es importante entender:
Para tales pruebas se necesitan precisamente IP móviles reales, no direcciones de centros de datos o residenciales comunes: solo el tráfico que ha pasado por la infraestructura del operador reproduce con precisión el patrón CGNAT que ve su WAF en usuarios reales.
Cómo configurar WAF para no bloquear a clientes honestos
Después del diagnóstico, es necesario ajustar las reglas de protección para no perder el nivel de seguridad, pero dejar de bloquear a los usuarios móviles reales. Aquí están los enfoques principales.
| Problema | Solución en WAF |
|---|---|
| Limitación de tasa estricta por IP | Aumentar el límite para ASN conocidos de operadores móviles o cambiar a limitación por sesión/cookie en lugar de IP pura |
| Puntuación acumulativa de reputación de IP | Reducir el tiempo de "memoria" de reputación para rangos CGNAT, agregar una lista blanca para ASN conocidos de operadores |
| Bloqueo por geolocalización/ASN completo | Reemplazar el bloqueo completo por un desafío suave (verificación JS) en lugar de un 403 |
| Captcha estricto en formularios de inicio | Activar captcha de manera adaptativa: solo ante señales reales de fuerza bruta (múltiples intentos fallidos desde una cuenta), y no por el hecho de ser IP CGNAT |
Una buena práctica es mantener una lista propia de rangos conocidos de operadores móviles en sus geografías clave y aplicarles reglas más suaves en comparación con el tráfico de internet normal. Esto requiere tiempo para la configuración, pero reduce drásticamente el número de bloqueos falsos.
Herramientas para pruebas con proxies móviles
Para auditorías regulares de la protección del sitio, es conveniente utilizar una combinación de navegador anti-detección y proxies móviles. Los navegadores anti-detección (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) permiten crear perfiles aislados con diferentes huellas de dispositivo, y los proxies móviles proporcionan tráfico CGNAT real de los operadores.
Enfoque paso a paso para las pruebas:
- Crear varios perfiles en el navegador anti-detección con diferentes parámetros de dispositivo (diferente User-Agent, resolución de pantalla, zona horaria).
- Conectar a cada perfil proxies móviles de la región y operador necesarios: esto proporcionará un comportamiento CGNAT real.
- Realizar escenarios clave de usuario: registro, inicio de sesión, agregar al carrito, pago.
- Registrar todos los casos de captcha, 403 y otros bloqueos, y compararlos con la configuración del WAF.
- Repetir la prueba a través de proxies residenciales para comparación: esto ayudará a entender si el problema es específico del tráfico móvil.
Para pruebas paralelas en diferentes geografías, también son útiles proxies residenciales: ayudan a evaluar cuán agresivo es el WAF para el tráfico de internet doméstico normal y el CGNAT móvil. Si planeas realizar pruebas de carga desde la infraestructura del servidor sin vinculación a un operador, para verificaciones de control sin el efecto CGNAT, puedes conectar proxies de centros de datos: proporcionarán una línea base limpia sin distorsiones propias de las redes móviles.
Este enfoque integral: IP móviles, residenciales y de centros de datos en una sola prueba, proporciona una imagen completa: ves exactamente dónde se activa la protección y para qué tipo de tráfico, en lugar de adivinar por indicios indirectos en los registros.
Preguntas frecuentes
¿Se pueden excluir completamente los rangos CGNAT de las reglas WAF?
No se recomienda: esto disminuirá la protección contra ataques reales, que también pueden provenir de redes móviles. Es más correcto suavizar los umbrales y cambiar a un desafío suave en lugar de un bloqueo estricto.
¿Con qué frecuencia se deben realizar tales verificaciones?
Al menos una vez al mes y obligatoriamente después de cualquier cambio en las reglas del WAF o el lanzamiento de una nueva campaña publicitaria dirigida a la audiencia móvil.
¿Esto afecta al SEO?
Sí: si los bots de búsqueda o los usuarios reales desde dispositivos móviles reciben un 403, esto aumenta la tasa de rebote y puede afectar negativamente a las métricas de comportamiento de clasificación.
Conclusión
CGNAT no es una amenaza, sino una característica del internet móvil con la que se enfrenta prácticamente cualquier negocio con audiencia móvil. El problema no está en la tecnología en sí, sino en que la configuración estándar del WAF no considera su especificidad y castiga a los usuarios honestos por un comportamiento propio de las redes móviles normales. Las seis verificaciones de este artículo ayudarán a diagnosticar rápidamente si estás perdiendo clientes debido a bloqueos falsos, y un ajuste puntual de las reglas del WAF puede recuperar la conversión sin disminuir el nivel de protección.
Si planeas probar regularmente el comportamiento del sitio y los embudos publicitarios como lo ven los verdaderos clientes móviles, recomendamos utilizar proxies móviles: proporcionan tráfico CGNAT real de los operadores y permiten identificar bloqueos falsos antes de que lo hagan tus clientes.