Desvío por la protección DDoS y falsos positivos DDoS scrubbing latency, false positives
ID de la causa dc-ddos · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Para frenar un ataque, el tráfico se desvía a un centro de depuración (scrubbing), lo que alarga la ruta, y a veces se bloquea a jugadores legítimos tomándolos por atacantes.
Por qué Tras detectar un ataque (o de forma permanente), el tráfico entrante se desvía a un centro de depuración → Efecto La ruta se alarga y algunos paquetes legítimos se clasifican como ataque → En pantalla El ping sube para todos; en ciertas regiones o ISP el juego no conecta
Cuando se junta mucha gente, De vez en cuando, al azar
Responsable
Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Documentar el patrón de tráfico del juego (puertos, tamaño de los paquetes, paquetes por segundo) y compartirlo con el equipo de infraestructura, mantener los paquetes UDP en 1,200 bytes o menos.
Tareas (Equipo de infraestructura)
Ajustar las reglas de protección al patrón de tráfico del juego, usar puntos de depuración regionales, reducir el tamaño de los paquetes TCP en los tramos con túnel (ajuste del MSS), detectar falsos positivos con la tasa de fallos de conexión por región y por ISP.
Cifras de referencia
Si el punto de depuración está en el mismo país, se suman unos pocos ms; si se pasa por un punto de otro país, se suman 30–100 ms o más. Normalmente solo el tráfico entrante da el rodeo y las respuestas del servidor salen directamente. Si el tráfico filtrado vuelve por un túnel, también se reduce el tamaño máximo que se puede enviar de una vez (MTU), lo que puede acabar en el problema de que solo desaparecen los paquetes grandes.
En el gráfico
Salto en escalón · RTT (ping), tasa de fallos de conexión por región/ISP
Dónde mirar
Poner en el mismo eje de tiempo los registros de inicio y fin del desvío (scrubbing) y los logs de bloqueo del dispositivo o servicio de protección, el gráfico de RTT y la tasa de fallos de conexión por región y por ISP. Desde la región afectada, comprobar con mtr o traceroute si aparece un punto de depuración en la ruta
Se confirma si
El RTT sube un escalón cuando se activa el desvío, se mantiene y vuelve a bajar cuando se desactiva. O aparecen direcciones de jugadores legítimos en el log de bloqueo y solo en esa región o ISP sube la tasa de fallos de conexión
Se descarta si
Si el RTT sube en momentos sin registros de desvío ni de bloqueo, apunta a “Enrutamiento con rodeos” o “Cambios de ruta BGP y convergencia”. Si solo desaparecen los paquetes grandes, a “Desajuste de MTU (solo desaparecen los paquetes grandes)”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
Maximum transmission unit and maximum segment sizeCloudflare Tras el filtrado, el tráfico entrante se entrega por un túnel GRE (MTU 1,476) y las respuestas salientes van directas a internet (DSR); se recomienda limitar el MSS de TCP a 1,436 o menos, y si no se ajusta, los paquetes grandes se descartan o se fragmentan
Azure network round-trip latency statisticsMicrosoft Azure Latencia de ida y vuelta según la ubicación del punto de presencia: Seúl–zona de Busan 8 ms, Seúl–Tokio 30 ms, Seúl–Singapur 68 ms