Cómo mejorar la velocidad de la WiFi sin comprar nuevos puntos de acceso

Cómo mejorar la velocidad de la WiFi sin comprar nuevos puntos de acceso Un informe técnico de Purple — Aproximadamente 10 minutos --- INTRODUCCIÓN Y CONTEXTO (aprox. 1 minuto) --- Le damos la bienvenida a la serie de informes técnicos de Purple. Soy su anfitrión, y hoy abordamos una de las conversaciones más comunes que tengo con directores de TI y CTO de grandes instalaciones: el problema de la capacidad de la WiFi. Tienen un hotel, una red de tiendas, un centro de conferencias o un estadio. Sus invitados y el personal se quejan de que la WiFi va lenta. Su primer instinto —y, francamente, el instinto con el que cuenta su proveedor de infraestructura— es comprar más puntos de acceso. Hardware nuevo, mayor despliegue, factura más grande. Pero aquí está el detalle. En la mayoría de los casos que he analizado, el problema no son los puntos de acceso en absoluto. El problema es lo que circula a través de ellos. Y eso es un problema de software, lo que significa que tiene una solución de software. Hoy les voy a explicar exactamente cómo el filtrado de DNS y la optimización en la capa de software pueden recuperar un treinta por ciento o más de su ancho de banda actual, sin tocar un solo componente de hardware. Analizaremos la arquitectura técnica, escenarios de implementación en el mundo real y el caso de negocio que pueden presentar a su CFO. Comencemos. --- ANÁLISIS TÉCNICO DETALLADO (aprox. 5 minutos) --- En primer lugar, definamos el problema principal. Cuando se analiza qué consume realmente el ancho de banda en una red WiFi para invitados empresarial típica, el desglose resulta realmente sorprendente para la mayoría de la gente. Las redes de publicidad y los rastreadores de terceros —la telemetría en segundo plano que cada aplicación de cada dispositivo envía constantemente— representan entre el veinticinco y el cuarenta por ciento del volumen de consultas DNS en una red de invitados típica. Estas no son solicitudes que sus invitados realicen de forma consciente. Son automáticas. Cada vez que alguien abre una aplicación de noticias, una plataforma de redes sociales o una aplicación de compras en su teléfono, esa aplicación lanza docenas de búsquedas DNS a servidores de publicidad, plataformas de análisis y píxeles de seguimiento. Ninguno de esos datos aporta valor a sus invitados. Todo ello consume su capacidad de subida. Además, hay que sumar el tráfico de malware y redes de bots. Los dispositivos comprometidos —y en una gran red de invitados, siempre habrá dispositivos comprometidos— intentan constantemente comunicarse con servidores de comando y control. Ese tráfico no solo desperdicia ancho de banda, sino que representa un riesgo de seguridad y cumplimiento normativo. Así que, antes de que un solo byte de tráfico legítimo —una videollamada, una página web, una transacción de pago— llegue a su enlace de subida, ya se ha consumido entre un tercio y la mitad de la capacidad disponible en ruido de fondo. Ahora bien, el filtrado de DNS funciona en la capa de resolución. Cada solicitud de internet comienza con una consulta DNS, una búsqueda que traduce un nombre de dominio en una dirección IP. El filtrado de DNS intercepta esa consulta antes de que llegue a su enlace de subida. Si el dominio se resuelve en una red de publicidad, un host de malware conocido o una categoría restringida por políticas, la consulta se bloquea en la capa de DNS. El dispositivo recibe una respuesta nula. No se transfieren datos. No se consume ancho de banda. Esto es fundamentalmente diferente de un cortafuegos o un proxy. Un cortafuegos inspecciona los paquetes una vez que ya han llegado. Un proxy intercepta el tráfico a mitad de camino. El filtrado de DNS detiene la solicitud antes de que comience, razón por la cual la recuperación de ancho de banda es tan significativa. No se está limpiando el tráfico que ya ha llegado; se está evitando que se solicite en primer lugar. Desde el punto de vista de la arquitectura, la implementación es sencilla. Se configura el servidor DHCP para que dirija los dispositivos de los clientes a su resolutor de filtrado de DNS en lugar de al DNS predeterminado de su ISP. Normalmente, esto es un cambio de dos líneas en su configuración DHCP. Las reglas de filtrado se gestionan de forma centralizada —ya sea en la nube o de forma local, según sus requisitos de cumplimiento— y se aplican de manera uniforme en todos los dispositivos conectados, independientemente del punto de acceso al que estén asociados. Este es un punto crítico para los operadores multisitio. Una cadena de tiendas con doscientas tiendas, o un grupo hotelero con cincuenta propiedades, puede implementar una política de filtrado de DNS coherente en todo el patrimonio desde una única consola de gestión. Sin visitas de ingeniería sobre el terreno. Sin configuración por sitio. Los cambios de política se propagan en cuestión de minutos. Ahora, hay una consideración técnica importante aquí que quiero señalar para los arquitectos de sistemas. La aparición de DNS sobre HTTPS —DoH— plantea un desafío para el filtrado de DNS tradicional. Cuando un dispositivo utiliza DoH, cifra sus consultas DNS y las envía directamente a un resolutor específico —normalmente uno gestionado por un proveedor de navegadores—, eludiendo por completo el DNS a nivel de red. Esto significa que se esquivan sus reglas de filtrado. La solución es aplicar la interceptación de DoH a nivel de red. Esto implica identificar el tráfico DoH —que se ejecuta en el puerto 443 hacia rangos de IP de resolutores conocidos— y bloquearlo o redirigirlo a su propio resolutor de filtrado compatible con DoH. Esta es una configuración más avanzada, pero es esencial para mantener la eficacia del filtrado en las redes modernas, donde Chrome, Firefox e iOS utilizan cada vez más el DNS cifrado de forma predeterminada. Purple ha publicado una guía detallada sobre las implicaciones de DNS sobre HTTPS para el filtrado de WiFi pública, que recomiendo leer junto con este informe. Más allá del filtrado de DNS, existen varias optimizaciones complementarias en la capa de software que vale la pena implementar en paralelo. El band steering es una de las más eficaces. La mayoría de los puntos de acceso modernos admiten las bandas de 2,4 gigahercios y 5 gigahercios. La banda de 5 gigahercios ofrece un rendimiento significativamente mayor pero un alcance menor. Sin un band steering activo, los dispositivos suelen asociarse a la banda de 2,4 gigahercios por defecto —en particular los dispositivos más antiguos y el hardware IoT—, lo que genera congestión en una banda que ya está saturada con tráfico heredado. Habilitar el band steering en su controlador inalámbrico empuja a los dispositivos compatibles a la banda de 5 gigahercios, liberando la de 2,4 gigahercios para los dispositivos que realmente la necesitan. La consolidación de SSID es otra victoria rápida. Cada SSID que se emite consume tiempo de transmisión a través de las tramas beacon, un tráfico de gestión que todos los dispositivos dentro del alcance tienen que procesar. Un espacio que ejecute ocho o diez SSID para diferentes departamentos, contratistas y niveles de invitados está perdiendo un porcentaje medible de tiempo de transmisión en tareas de gestión. Consolidar en tres o cuatro SSID —invitados, personal, IoT y gestión— y utilizar el etiquetado VLAN para la segmentación en lugar de SSID independientes puede recuperar ese tiempo de transmisión de inmediato. La aplicación de políticas de QoS —Calidad de Servicio— es la tercera palanca. Sin QoS, un solo invitado que transmita vídeo en 4K puede saturar una celda de radio, degradando la experiencia de todos los demás dispositivos en ese punto de acceso. Implementar la limitación de velocidad por cliente y la priorización del tráfico —elevando el tráfico de VoIP y de transacciones de POS por encima de la transmisión masiva de vídeo— garantiza que el tráfico crítico para el negocio esté protegido incluso en momentos de máxima carga. Por último, la planificación de canales y la optimización de la potencia de transmisión. A menudo, estos parámetros se configuran una vez durante la implementación inicial y nunca se vuelven a revisar. A medida que cambia el entorno de RF —nuevos edificios, nuevas fuentes de interferencia, cambios en la densidad de dispositivos—, sus asignaciones de canales pueden estar creando interferencias cocanal que degradan significativamente el rendimiento. Realizar un estudio pasivo de RF y volver a optimizar las asignaciones de canales es una intervención sin coste que puede generar mejoras sustanciales en el rendimiento. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES (aprox. 2 minutos) --- Permítanme ofrecerles una secuencia práctica de implementación para un espacio de tamaño mediano, por ejemplo, un hotel de doscientas habitaciones o un centro de distribución minorista regional. Comiencen con una medición de referencia. Antes de cambiar nada, configuren su red para registrar el volumen de consultas DNS por categoría, el consumo de ancho de banda por cliente y la utilización del enlace de subida por hora del día. Esto les proporcionará el estado previo para el cálculo del ROI. La mayoría de las plataformas de análisis de WiFi empresarial muestran estos datos de forma nativa; la plataforma de análisis de Purple, por ejemplo, proporciona visibilidad a nivel de dispositivo, lo que facilita enormemente este ejercicio de referencia. Paso dos: implementen el filtrado de DNS en modo de monitorización. La mayoría de las soluciones de filtrado de DNS empresariales admiten un modo pasivo en el que las consultas se registran y categorizan pero no se bloquean. Ejecuten esto durante cuarenta y ocho a setenta y dos horas para comprender la composición de su tráfico antes de aplicar cualquier política. Esto evita que los falsos positivos interrumpan el tráfico legítimo desde el primer día. Paso tres: habiliten el bloqueo por fases. Comiencen con las categorías de mayor confianza: dominios de malware conocidos, comando y control de redes de bots y redes de publicidad. Estos son bloqueos de bajo riesgo con un alto impacto en el ancho de banda. Revisen los registros diariamente durante la primera semana para detectar cualquier bloqueo inesperado. Paso cuatro: incorporen QoS y band steering. Una vez que el filtrado de DNS sea estable, implementen la limitación de velocidad por cliente y el band steering. Prueben estos cambios durante las horas de menor actividad y validen que los terminales POS, los teléfonos VoIP y otros dispositivos críticos para el negocio funcionen correctamente. Paso cinco: documenten y midan. Después de treinta días, extraigan sus métricas de utilización de ancho de banda y compárenlas con su línea de referencia. En la mayoría de las implementaciones, verán una reducción del veinte al cuarenta por ciento en la utilización del enlace de subida. Esa es su cifra de ROI. Ahora, los errores comunes. El más habitual que veo es el exceso de bloqueo. Si habilitan categorías agresivas de filtrado de contenido sin revisar primero los registros, bloquearán servicios legítimos. El almacenamiento en la nube, las aplicaciones SaaS empresariales e incluso algunos dominios de procesamiento de pagos pueden aparecer en bloques de categorías generales. Empiecen siempre de forma conservadora y vayan ampliando. El segundo error es ignorar la elusión por DoH. Si implementan el filtrado de DNS sin abordar el DoH, verán disminuir la eficacia de su filtrado con el tiempo a medida que más dispositivos utilicen el DNS cifrado de forma predeterminada. Aborden esto a nivel de política de red desde el primer día. El tercer error es no segmentar el tráfico de IoT. Los dispositivos IoT —televisores inteligentes, sistemas de gestión de edificios, señalización digital— suelen generar un tráfico DNS significativo hacia los servidores de telemetría del fabricante. Si no segmentan el IoT en una VLAN independiente con su propia política de filtrado, podrían bloquear involuntariamente funciones del dispositivo al endurecer sus reglas de filtrado. --- PREGUNTAS Y RESPUESTAS RÁPIDAS (aprox. 1 minuto) --- Repasemos las preguntas que recibo con más frecuencia. «¿Afectará el filtrado de DNS a la experiencia del invitado?» En la práctica, los invitados nunca lo notan. Los dominios que se bloquean son telemetría en segundo plano, no contenido que estén solicitando activamente. En todo caso, su experiencia mejora porque hay más ancho de banda disponible para las cosas que realmente intentan hacer. «¿Requiere esto cambios en nuestros puntos de acceso?» No. El filtrado de DNS se configura en la capa de DHCP y del resolutor de DNS. Sus puntos de acceso no se tocan. «¿Cumple esto con el GDPR?» El filtrado de DNS registra consultas de dominio, no contenido. No se realiza una inspección profunda de paquetes. Siempre que dispongan de políticas de retención de datos adecuadas y su aviso de privacidad cubra la monitorización de la red —algo que debería hacer en cualquier caso—, el filtrado de DNS es totalmente compatible con el GDPR. Para implementaciones en el sector público y sanitario, a menudo es un requisito de cumplimiento normativo más que una opción. «¿Qué pasa con PCI DSS?» El filtrado de DNS en realidad refuerza su postura de PCI DSS al evitar que los entornos de datos de titulares de tarjetas se comuniquen con dominios maliciosos conocidos. Es un control positivo, no un riesgo. --- RESUMEN Y PRÓXIMOS PASOS (aprox. 1 minuto) --- Para resumir: la mayoría de los problemas de rendimiento de la WiFi empresarial no son problemas de hardware. Son problemas de software, específicamente, la ausencia de una gestión inteligente del tráfico en la capa de DNS. Al implementar el filtrado de DNS, pueden recuperar un treinta por ciento o más de su ancho de banda actual, prolongar la vida útil operativa de su infraestructura actual de puntos de acceso de dos a cuatro años y, al mismo tiempo, mejorar su seguridad y cumplimiento normativo. El plazo de implementación se mide en horas, no en meses. El gasto de capital es una fracción de lo que costaría una renovación de hardware. Los siguientes pasos prácticos son sencillos. Realicen una auditoría del tráfico DNS en su red esta semana; la mayoría de las plataformas empresariales les proporcionarán estos datos sin necesidad de herramientas adicionales. Identifiquen las categorías de dominios que más ancho de banda consumen. A continuación, evalúen una solución de filtrado de DNS frente a esas categorías. Si gestionan una red WiFi para invitados a gran escala —hostelería, comercio minorista, eventos, sector público—, la plataforma de Purple integra el filtrado de DNS con la gestión y el análisis de la WiFi para invitados en una única implementación. Eso significa que obtienen la recuperación de ancho de banda, los controles de cumplimiento y la información de los datos de los invitados desde una sola plataforma en lugar de tres. Gracias por escuchar el informe técnico de Purple. La guía de implementación completa, los diagramas de arquitectura y los ejemplos prácticos están disponibles en la guía escrita que acompaña a este audio. Hasta la próxima.