Más allá de la congestión: cómo desenmascaré a mi ISP limitando Netflix con TCPDump

Eran las 21:45 de un martes de mayo de 2026. Acababa de llegar a casa y me dispuse a ver el estreno de la nueva temporada de "Arcane" en calidad 4K HDR. Tenía contratada una simétrica de 600 Mbps con fibra hasta el hogar (FTTH), teóricamente sobrada para cualquier streaming. A los tres minutos, la imagen se pixeló, el sonido se desincronizó y el reproductor de Netflix cayó a 240p. Reinicié el router, comprobé la conexión WiFi —que funcionaba a 5 GHz sin interferencias— e incluso lancé una prueba de velocidad desde Fast.com. El resultado: 550 Mbps de bajada.

Fue en ese momento cuando mi instinto técnico me dijo que no se trataba de un fallo aleatorio. Si la tubería está abierta para medir 550 Mbps en una prueba genérica, pero se ahoga cuando se trata de un flujo constante de video UDP/TCP, hay algo más en medio. No era congestión; era gestión de tráfico. Y necesitaba las pruebas para demostrarlo.

El escenario del crimen: aislando variables

Descarté de inmediato que el problema fuera mi red interna. Mis dispositivos están cableados mediante Cat 6a a un switch gestionado Gigabit, y el punto de acceso WiFi es un modelo reciente de alta gama que soporta Wi-Fi 7. El cuello de botella no estaba en mi casa.

Para asegurarme, conecté un portátil antiguo que tengo reservado para labores de diagnóstico directamente al puerto ONT de la fibra, saltándome el router del operador. Asigné una IP estática y lancé un ping continuo a los servidores DNS de Google (8.8.8.8). La latencia se mantuvo estable en 12 ms durante diez minutos. Sin jitter, sin pérdida de paquetes.

Acto seguido, inicié una descarga directa de una ISO de Linux desde un servidor de la universidad de Chile. La descarga se estabilizó en 58 MB/s (aprox. 464 Mbps), una cifra razonable considerando la sobrecarga de protocolos. Sin embargo, en cuanto abrí Netflix y pulsé "reproducir", el throughput de la descarga de la ISO se desplomó a 4 MB/s y el video seguía haciendo buffering.

Este comportamiento es la firma clásica del Traffic Shaping discriminado por aplicación o protocolo. El ISP no estaba limitando mi velocidad total, sino que estaba restringiendo agresivamente el ancho de banda disponible para ciertos flujos de tráfico identificados como streaming de video.

Armando el laboratorio: TCPDump al rescate

Para no depender de suposiciones, necesitaba inspeccionar el tráfico a nivel de paquete. Aquí es donde entra en juego tcpdump, la herramienta estándar de oro para la captura de paquetes en redes Unix/Linux. A diferencia de las herramientas visuales que pueden abstraer detalles, tcpdump te da la cruda realidad de lo que cruza la tarjeta de red.

Mi objetivo era capturar el tráfico mientras intentaba reproducir contenido y compararlo con el tráfico de una descarga estándar. Abrí una terminal en mi portátil Linux y ejecuté el siguiente comando con permisos de superusuario (sudo):

sudo tcpdump -i eth0 -w netflix_investigation.pcap -n 'host 45.57.22.111 or port 443'

Aquí, eth0 es mi interfaz de red, -w volca la captura a un archivo para análisis posterior y -n evita que tcpdump resuelva nombres de DNS constantemente, lo cual ralentiza la captura. El filtro host era una IP conocida de un nodo de Netflix en la región (que identifiqué previamente haciendo un nslookup a los dominios de Netflix), aunque en la práctica real Netflix usa múltiples CDN, por lo que ajusté el filtro para capturar todo el tráfico SSL/TLS (port 443) durante intervalos de 5 minutos.

Dejé la captura corriendo y simulé el uso normal: abrí Netflix, esperé a que cargara la barra de progreso, dejé que se degradara la calidad y, simultáneamente, mantuve una descarga de fondo activa.

Autopsia del tráfico: lo que revelaron los paquetes

Una vez terminada la prueba, cerré la captura y abrí el archivo .pcap con Wireshark para facilitar la lectura, aunque gran parte del análisis se puede hacer con líneas de comandos. Lo que encontré confirmó mis sospechas y añadió una capa de sofisticación preocupante.

Al analizar los flujos TCP hacia los servidores de Netflix, observé un patrón sistemático de TCP Retransmissions (retransmisiones). Normalmente, en una conexión sana, el emisor envía una ventana de datos y el receptor envía un ACK (acuse de recibo). Si el paquete se pierde, se reenvía.

En mi captura, los ACKs llegaban, pero el tamaño de la ventana de recepción (TCP Window Size) se estaba manipulando. Los paquetes ACK que enviaba mi portátil indicaban que tenía espacio para recibir más datos, pero los paquetes que llegaban desde el servidor de Netflix tenían ventanas de transmisión ridículamente pequeñas (en ocasiones de menos de 1000 bytes) justo después de los primeros 10 segundos de conexión. Esto obligaba a una negociación lenta y constreñía el flujo de datos.

Por el contrario, el tráfico HTTPS hacia los servidores de descarga de la ISO de Linux mostraba un escalado de ventana agresivo y optimizado (TCP Window Scaling), llenando el enlace de datos eficientemente. La discriminación no era por "video", sino por la firma de la handshake inicial o por el rango de IPs destino pertenecientes a los CDN de video más populares.

Este fenómeno es técnicamente posible gracias a inspectores de paquetes profundos (DPI) que operan en los enlaces de troncal del proveedor. Identifican el flujo SNI (Server Name Indication) en la negociación TLS —aunque el contenido esté encriptado, el SNI viaja en texto claro a menos que se use ECH— y aplican políticas de QoS (Calidad de Servicio) inversa, degradando intencionadamente el servicio para ahorrar ancho de banda en horas pico.

La solución técnica: enmascarar el tráfico

Saber el problema es la mitad de la batalla. La otra mitad es sortearlo sin tener que llamar a atención al cliente —una vía que suele resultar en diagnósticos de guion prefabricados como "reinicie su deco" o "cambie el cable coaxial".

Mi solución inmediata fue desviar el tráfico de video a través de un túnel VPN. Configuré un servidor WireGuard en un VPS barato que tengo en Frankfurt y redirigí todo el tráfico de mis dispositivos de streaming a través de ese túnel.

El resultado fue inmediato y drástico. Al encapsular el tráfico TCP dentro del paquete UDP cifrado de WireGuard, el equipo de DPI del ISP ya no podía "ver" que se trataba de una conexión hacia Netflix. Para el operador, solo veía un flujo UDP encriptado hacia una IP genérica en Alemania. Al no activarse la política de limitación, la ventana TCP interna del túnel se expandió libremente y Netflix volvió a funcionar en 4K HDR sin interrupciones.

Este trade-off tiene un coste: el tráfico ahora viaja a mi router, va encriptado a Frankfurt, vuelve a salir a internet hasta el servidor de Netflix de mi región, y luego hace el camino de vuelta. Esto añade latencia (el ping subió de 12 ms a unos 45 ms), lo cual es imperceptible para el streaming de video, pero sería terrible para videojuegos competitivos. Por eso, solo redirijo el tráfico de los dominios de video y mantenemos el resto del tráfico local.

Reflexiones sobre la neutralidad de la red en 2026

Lo que viví no es un caso aislado. Muchos usuarios creen erróneamente que si tienen fibra óptica de 1 Gbps, el streaming funcionará siempre fluido. Sin embargo, la realidad de la gestión de redes en 2026 implica que los proveedores gestionan activamente el tráfico para optimizar sus márgenes, priorizando velocidades pico en test de velocidad (que suelen usar servidores caché dentro de su propia red) sobre la calidad de uso real.

Es fundamental que los usuarios sepan distinguir entre una red congestionada y una intervención artificial. Si el video funciona perfectamente de madrugada o usando una VPN, pero falla en horario estelar, el problema no es tu infraestructura, es la política de tu proveedor. Herramientas como tcpdump o incluso simples extensiones de navegador que muestren la resolución y el bitrate en tiempo real pueden ser tus mejores aliados para detectarlo.

Cambiar de operador puede ser una solución, pero no garantiza que el siguiente no haga lo mismo. La verdadera independencia radica en controlar tu propio enrutamiento. Al final del día, logré "arreglar" mi conexión pagando 5 euros额外 por un servidor VPS y configurando un túnel, una solución técnica "fea" pero efectiva que me devolvió el control sobre una banda ancha por la que ya pago una prima mensual. La neutralidad de la red puede estar muriendo lentamente en las troncales de los operadores, pero en nuestra última milla, todavía podemos luchar por cada paquete.