VPS con protección DDoS para servidores de juegos — Minecraft, CS2, Rust

Tick rate, cálculo de slots y realidad de los ataques para Minecraft, CS2 y Rust, con filtrado DDoS en la plataforma. VPS para juegos desde $4.80/mes anual.

La hoja de especificaciones miente sobre los juegos por omisión

Nada en la tabla de precios de un VPS predice cómo se sentirá un servidor de juegos, porque el número que decide esa sensación rara vez es un titular: la frecuencia de un solo hilo. La simulación del juego ejecuta su bucle de tick en un hilo, y cuando ese bucle se pasa de su presupuesto, el síntoma no es un fallo: es el rubber-banding, el registro de impactos que falla y una comunidad que se marcha en silencio. El número de núcleos vende planes; la frecuencia de reloj juega la partida. Esa inversión es lo primero que hay que interiorizar, porque todo lo que compres después depende de ella.

Los motores difieren en lo que consumen. CS2 está limitado por el tick rate: una frecuencia de un solo hilo potente vale más que el número de núcleos, y por eso el EPYC 9354P a 3.25-3.8 GHz o el Ryzen 9 9950X a 4.3-5.7 GHz importan más que un recuento de vCPU. Minecraft es el devorador de RAM: 8 GB es el mínimo en cuanto se forma una comunidad con mods, como insinúa su propia página del servidor y confirma cualquier modpack. Rust quiere memoria e I/O de disco para sus bucles de guardado y de expulsión de chunks: 16 GB y NVMe, que aquí llevan todos los planes de serie y no como mejora opcional.

La aritmética del tick hace concreto el argumento del reloj. Minecraft apunta a 20 TPS, lo que presupuesta 50 ms por tick para todo: la IA de entidades, la redstone, los ticks de chunks, los manejadores de plugins. Un núcleo lento que gasta 60 ms en un tick pesado no puede ser rescatado por siete núcleos ociosos, porque el bucle es serial y el presupuesto es por tick, no por segundo. Por eso un plan de 2 vCPU con reloj rápido gana a uno de 8 vCPU con reloj lento en servidores sensibles al tick, y por eso las gráficas de utilización engañan a quien las lee a pie de la letra.

El error típico es comprar por número de vCPU y luego ajustar la variable equivocada: añadir jugadores cuando el tick ya se está deslizando, o instalar un modpack de rendimiento para compensar un núcleo lento, lo que vuelve a subir el uso de CPU. El segundo error es creerse las cifras de reloj turbo sin la historia del sostenido: 5.7 GHz es un boost de un solo núcleo, y el comportamiento sostenido con todos los núcleos bajo un servidor lleno es distinto. Pregunta cuál es el presupuesto de tick, compra el reloj que lo cubra y deja que el número de núcleos siga a eso.

Con reloj, RAM e I/O asignados a cada motor, el resto es aritmética por juego. La siguiente sección dimensiona Minecraft, CS2 y Rust con números reales, y muestra dónde debe cortar la escalera de planes.

Dimensionar por juego, con los números

Una tabla de dimensionamiento no puede servir para tres motores porque estrangulan en recursos distintos, así que lo honesto es llevar tres tablas pequeñas en la cabeza. El resultado contraintuitivo: el plan correcto para un servidor vanilla de Minecraft de 40 jugadores puede ser el equivocado para uno con mods de 20, y un servidor de CS2 que va perfecto a la hora del almuerzo puede degradarse en la hora punta puramente por presión de tick. Dimensiona para la peor hora de la carga, no para su media, porque las comunidades juegan en la peor hora.

Minecraft: cuenta con 8 GB como mínimo en cuanto se forma una comunidad con mods — Prime, con 8 GB de DDR5 y 160 GB de NVMe, es el suelo realista, y Titan con 32 GB responde a los packs pesados. Pide Prime a $12/mes de lista — $9.60/mes en el término anual — cuando la lista de modpacks empieza a crecer, y sube a Titan a $24 de lista, $19.20 anual efectivo, para los packs que se comen vivos al nivel intermedio. Los servidores vanilla encajan bien en niveles inferiores; los mods no se quedan vanilla mucho tiempo.

CS2: otra vez limitado por el tick rate, así que la pregunta de dimensionamiento es la calidad del reloj — el EPYC 9354P a 3.25-3.8 GHz sostiene un servidor comunitario concurrido, y el bare metal lo hace todavía mejor. Rust: dominan la memoria y la I/O de disco, 16 GB y NVMe siendo el suelo operativo, con la expulsión de chunks y los bucles de guardado golpeando el disco a ráfagas. El ancho de banda es la variable silenciosa en los tres: 1 Gbps sin límite de tráfico en el plan de entrada, 2.5 Gbps en Prime, 10 Gbps en Titan — las ráfagas de chunks hacia una multitud recién incorporada son el momento en que el puerto importa.

El folklore que rompe el dimensionamiento son las fórmulas por número de jugadores, diez jugadores por gigabyte y similares, que ignoran los mods, la distancia de renderizado, el número de entidades y la diferencia entre granjas AFK y granjas de 200 entidades. El segundo fallo es dimensionar para el día del lanzamiento: las comunidades crecen, los modpacks se acumulan, y el plan que valía para el tráiler no vale en el mes cuatro. Anota la RAM, el presupuesto de tick y el objetivo de slots; revísalo tras cada cambio de modpack; y cambia de nivel con evidencia de tick, no con vibras ni quejas del lobby.

Dimensionado correctamente, la máquina aún tiene que sobrevivir a la atención que atrae una IP pública. Los ataques son un cuándo, no un si, y la siguiente sección separa las dos capas de ese problema — la que es de la plataforma y la que es tuya.

Una IP pública es un cuándo, no un si

Los servidores de juegos públicos reciben golpes — de rivales, de bots que escanean rangos y de usuarios de servicios de booter gratuitos que atacan por diversión. La pregunta útil no es si sino en qué capa aterriza el golpe, porque las dos capas tienen dueños distintos: las inundaciones volumétricas son cosa de la plataforma, el abuso a nivel de aplicación es cosa tuya. Presupuestar lo primero y escribir scripts para lo segundo es toda la postura defensiva que necesita un servidor comunitario, y cuesta menos que una tarde de configuración.

El filtrado volumétrico L3/L4 está integrado en la plataforma en todos los niveles, sin interruptor y sin tarifa — por eso la historia del DDoS pertenece a la plataforma misma, nunca a un upsell por IP. Un producto de protección por IP tiene que desviar tu tráfico antes de filtrarlo, añadiendo latencia y una dependencia; el filtrado a nivel de plataforma está en el camino por construcción. Las inundaciones que antes tumbaban servidores de aficionados — la amplificación UDP, tormentas SYN de decenas de gigabits — se absorben en esa capa, y tus jugadores no notan ni un fotograma.

El abuso a nivel de aplicación pasa los filtros volumétricos precisamente porque parece jugadores: spam de votos que inunda tu ranking, floods de chat que ahogan la moderación, bucles de entrada-salida que llenan los slots, fuerza bruta RCON llamando al puerto de administración. Eso queda en territorio de plugins — los plugins de moderación y limitación de tasa de tu motor son el filtro real, y por eso el reflejo anti-abuso pertenece a tu runbook: saber qué plugin silencia qué flood es la diferencia entre una tarde y una semana.

Los errores clásicos se agrupan en torno a los puertos. Dejar el puerto RCON 25575 abierto al mundo invita a machacar contraseñas; publicar el puerto de query junto al del juego es necesario para los navegadores de servidores, pero dejar al lado un puerto de panel es superficie pura. Asumir que el filtro de plataforma también cazará una inundación L7 de conexiones con apariencia legítima es el segundo error — esas necesitan tu limitación de tasa, y el nivel superior de dedicated añade un scrubber L3/L7 para operadores que quieren que la plataforma cargue con más de ese peso.

Con los puertos recortados y las capas entendidas, queda la decisión de dónde vive la máquina. La ubicación sigue a los jugadores, y la física es menos negociable que el precio, como muestra la siguiente sección con milisegundos reales.

Coloca la máquina donde están los jugadores, no donde es barato

En servidores de juegos, la latencia es el producto: una bandera barata que añade 80 ms a cada golpe pierde una comunidad más rápido que cualquier caída, porque los jugadores te comparan con el servidor de la pestaña de al lado. Los compradores educados por el hosting web en optimizar el precio por gigabyte lo ven al revés. La pregunta de ubicación es primero la geografía de los jugadores y segundo el precio — y la física que la decide no es configurable, no es ajustable y no está a la venta en ningún nivel.

La aritmética es honesta: la luz en fibra viaja a unos 200,000 km/s, así que 100 km son unos 1 ms de ida y vuelta antes de que el enrutamiento, el peering o las colas añadan su impuesto. Tokio para JP y KR, Singapur para el Sudeste Asiático, Hong Kong para la Gran Área de la Bahía, Fráncfort para la UE — no son eslóganes de marketing, sino donde están los puntos de peering: JPIX y JPNAP en Tokio, SGIX en Singapur, HKIX en Hong Kong, AMS-IX y DE-CIX en Fráncfort y Ámsterdam. La tabla de ubicaciones lista el nivel, el uplink, el peering y la ley aplicable de cada bandera.

Los presupuestos de latencia enmarcan todo lo demás: un tick puede esconder 30 ms de jitter, pero no puede esconder una ruta de fibra que nunca se construyó. 12 ubicaciones a un mismo precio de SKU cambian la historia del crecimiento: una comunidad que supera su región se muda por re-despliegue — máquina nueva, copiar el mundo, cortar el DNS — no por renegociación. La predicción del cliente y la interpolación pueden enmascarar el jitter, pero no pueden esconder 200 ms de distancia honesta, y por eso los jugadores de la UE en una máquina de Tokio hacen rubber-banding por muy bueno que sea el tick.

El error clásico es elegir la bandera por el precio de la etiqueta o por moda jurisdiccional cuando la comunidad vive en otro sitio — una comunidad del Sudeste Asiático en una máquina europea lo siente cada segundo de juego. El segundo es olvidar la ruta de mudanza: mundos copiados con rsync -a, límites de guardado respetados y DNS cambiado con un TTL corto hacen que el re-despliegue sea aburrido; sin eso, la mudanza se convierte en una semana de comunidades partidas discutiendo cuál es el servidor de verdad.

Bandera elegida y plan dimensionado, la primera hora en la máquina nueva decide cuánto abuso va a invitar tu dirección pública. El plan de puertos viene después, y es la mitigación más barata que configurarás jamás.

Bloqueo de primera hora: el plan de puertos

La mitigación DDoS más barata que ejecutarás jamás es un firewall de denegación por defecto, porque la mayor parte de lo que llega a la dirección pública de un servidor de juegos no es un ataque: son escáneres, y los escáneres no te cuestan nada si no encuentran nada que les responda. Cada puerto que no publicas es un puerto que nadie puede inundar, sondear ni atacar por fuerza bruta; cada panel que mantienes fuera de la lista pública es un formulario de login que jamás recoge intentos. La lista de cinco minutos de abajo no tiene glamour, y previene más incidentes que cualquier extra de pago.

Publica solo lo que el juego necesita: el puerto UDP del juego y el puerto de query. Minecraft responde en 25565 con query en el mismo puerto si está activado; CS2 usa 27015 para el tráfico de juego y de query; el RCON en 25575 debe enlazarse solo a loopback o a la interfaz VPN. Mantén el panel y el SSH fuera de la lista pública — accede a ellos por WireGuard en 51820, siguiendo la guía rápida oficial — y deniega por defecto todo lo demás con nftables: ufw default deny incoming es la versión en dos palabras de la misma idea.

Haz snapshot antes de las actualizaciones de modpack. Los snapshots se contratan como add-on en el checkout, y un snapshot previo a la actualización revierte un modpack roto en minutos en lugar de una reconstrucción — conviértelo en el ritual que precede a cada actualización, no en un parche tardío tras el primer desastre. Esto se combina con el bucle de copias fuera de la máquina más adelante en la guía: los snapshots responden rápido a las malas actualizaciones, las copias responden lenta y a fondo a los desastres. Trabajos distintos, ambos programados, ninguno opcional cuando una comunidad depende del mundo.

Los fallos recurrentes: RCON enlazado a 0.0.0.0 con una contraseña débil, porque el valor por defecto de la configuración lo decía; un panel web publicado por comodidad que se convierte en la superficie de ataque real; y el servidor de staging olvidado — una vieja instancia de prueba de modpack todavía escuchando en sus puertos por defecto, ejecutando un set de plugins con una vulnerabilidad conocida. Inventa los listeners con ss -tulpen, cierra lo que los jugadores no puedan nombrar y anota qué queda abierto y por qué, para que la lista sea una decisión y no un accidente.

Con la superficie recortada, la pregunta continua es cómo está aguantando realmente la máquina bajo carga. La respuesta es el tick, no la gráfica de CPU, y la siguiente sección lo defiende con números.

Vigila el tick, no el porcentaje de CPU

Cuando la gráfica de CPU de un servidor de juegos ya asusta, la comunidad lo lleva sintiendo días — la degradación del tick va por delante, la utilización llega tarde. Un servidor al 40% de CPU con un tick rate degradándose ya está sobresuscrito para sus jugadores, porque el bucle de tick es serial y sus fallos se manifiestan como rubber-banding antes de que cualquier gráfica se ponga roja. La pregunta de monitorización es por tanto: cuánto tardó el peor tick, no lo ocupada que parece la máquina a un transeúnte.

Minecraft hace explícito el presupuesto: 20 TPS significan 50 ms por tick para todo — IA de entidades, ticks de chunks, manejadores de plugins — y el servidor reporta su propio desfase en la consola. El modelo sub-tick de CS2 aprieta la misma lógica a mayor frecuencia. Mira el tiempo de tick y los TPS directamente, en percentil y no en media: el tick p95 es el que desconecta a un jugador en mitad de un combate. Lo que muestra top, según su manual, son medias; y las medias son exactamente de lo que no muere un servidor limitado por el tick.

Cambia de nivel con evidencia de tick. Cuando el tiempo de tick p95 supera el presupuesto durante una semana entera, alquila Forge a $49/mes de lista — $39.20/mes en el término anual — y pasa el directorio del mundo con rsync en una ventana de mantenimiento; sus 16 núcleos del 9950X a 4.3-5.7 GHz son otra clase de margen de tick. El puerto también importa: 1 Gbps sin límite de tráfico en el plan de entrada, 2.5 en Prime, 10 en la cima de la escalera VPS — sin límite significa que la ráfaga no cuesta nada más que el propio switch.

Esperar al 100% de CPU es el error clásico — en un servidor limitado por el tick nunca llega, porque el bucle se bloquea sobre sí mismo mientras otros núcleos están ociosos. Leer la CPU media en lugar de los percentiles del tick es el segundo; contar la swap como margen de RAM es el tercero, y un servidor que vive en la swap ya perdió la carrera del tick diga lo que diga el panel. Vigila el tick, su p95 y el uplink durante las ráfagas de entradas — en ese orden, cada semana.

Vigilado el tick y siendo honestos con los niveles, el último deber operativo es el mundo en sí: guardados que cambian cada segundo y se corrompen fácilmente si se tratan con descuido. El bucle de copias de la siguiente sección los trata como lo que son — una base de datos.

Los mundos guardados son el estado; trátalos como una base de datos

Un mundo de juego cambia más a menudo que la mayoría de bases de datos de producción y recibe menos copias de seguridad, porque es solo un juego hasta que 400 horas de construcción comunitaria se evaporan en un guardado corrupto. El directorio del mundo es el estado más puro de la máquina: nada de él es reproducible, ningún script puede reconstruirlo, y el delta entre dos guardados es la tarde de los jugadores. Un archivo de región corrupto no es un incidente de caída; es un proyecto de arqueología. Trátalo con la disciplina que le darías a una tabla de pedidos.

La consistencia ante fallos es el enemigo: copiar un mundo en vivo a mitad de un guardado produce archivos de región rotos que puede que carguen, puede que carguen a medias, o puede que envenenen el nivel en el próximo arranque. Minecraft te da la palanca: save-off, save-all, ejecutar la copia, save-on — unos segundos de escrituras en pausa a cambio de un conjunto consistente. Programa esa ventana en el trabajo de copias en lugar de archivar el directorio a ciegas a las 4 de la mañana esperando que el motor estuviera justo entre escrituras esa noche.

El estado completo es más ancho que el overworld: las dimensiones del Nether y del End, playerdata con inventarios y posiciones, y los almacenes de plugins — las bases de datos de permisos y de economía guardan sus propios archivos o esquemas y son justo lo primero que los jugadores notan cuando faltan. La pata fuera de la máquina sigue el patrón 3-2-1 de la guía de copias: un borg create o restic backup programado hacia una segunda máquina, cifrado en el origen, con retención en escalera. Los snapshots cubren la reversión previa a actualizaciones; la copia fuera de la máquina cubre todo lo demás, que es peor.

Los errores recurrentes: copiar solo la carpeta del overworld mientras Nether y playerdata se quedan atrás; probar las restauraciones por número de archivos en vez de arrancando una copia de prueba del mundo; y asumir que la base de datos de plugins está dentro del directorio del mundo cuando vive en un esquema aparte. Una restauración que pierde los inventarios es un desastre de soporte aunque el terreno esté perfecto — copia el conjunto completo y verifica arrancando, cada trimestre, como cualquier base de datos por la que te paguen.

Puertos, tick y guardados forman juntos todo el ritmo operativo de un servidor comunitario. La sección final encadena cada paso en un orden de lanzamiento que puedes ejecutar esta misma tarde, en una sola máquina y sin improvisar.

El lanzamiento del servidor de juegos, en el orden de ejecución

El orden de lanzamiento existe para que nada dependa de un paso sin terminar. Primero, ubica por geografía: elige la bandera donde vive la comunidad — Tokio para JP/KR, Singapur para el Sudeste Asiático, Hong Kong para la Gran Área de la Bahía, Fráncfort para la UE — y comprueba el ping desde la perspectiva de un jugador, unos 1 ms por 100 km de distancia honesta. Segundo, dimensiona por juego con los números de arriba: 8 GB como suelo de Minecraft con mods en el nivel intermedio, CS2 en el mejor reloj que puedas justificar, Rust con 16 GB y NVMe debajo.

Tercero, pide y arranca: plan, término, ubicación y el SO que prefiera tu motor — el playbook de checkout sin KYC cubre identidad y pago si ese lado te importa. Cuarto, cierra antes de exponer nada en público: ufw default deny incoming, los puertos de juego y de query abiertos, RCON y SSH detrás de WireGuard, y un inventario de listeners con ss -tulpen para demostrar que la lista es honesta. Quinto, toma un snapshot como línea base — el add-on del checkout te da el ritual previo a cambios para cada actualización de modpack que venga.

Sexto, instala y prueba de carga: levanta el motor, aplica el modpack y observa el tick bajo una tarde simulada — el informe de TPS de la consola es el honesto, p95 y no media. Séptimo, cablea el bucle de copias: save-off, save-all, copiar, save-on en un horario diario, enviado fuera de la máquina con Borg o Restic hacia la segunda máquina, retención en escalera, y una prueba de restauración que realmente arranque una copia de prueba del mundo en lugar de contar archivos.

Octavo, escribe el reflejo anti-abuso antes del primer ataque: qué plugin silencia los floods de chat, cuál limita la tasa de los votos, dónde vive la contraseña del RCON y a quién avisas cuando la tarde se pone ruidosa. El filtrado L3/L4 de la plataforma absorbe la parte volumétrica; el reflejo se encarga de la parte que parece jugadores. Noveno, programa las revisiones: tendencia del tick cada semana, prueba de restauración cada trimestre, ritual de snapshot antes de cada actualización de modpack — tres entradas de calendario que mantienen todo el stack aburrido.

Ejecutado en ese orden, el lanzamiento no deja nada a la memoria: la ubicación y el dimensionamiento están por escrito, la superficie está cerrada, el tick tiene una línea base, el mundo tiene copias en dos sitios, y la primera mala tarde de la comunidad es una entrada de runbook y no una crisis. Esa es toda la diferencia entre un servidor que aloja a una comunidad y uno que solo escucha en un puerto.