Proteger tu servidor de RedM frente a ataques DDoS

Un servidor de RedM que desaparece por la noche en mitad de la sesión y vuelve a aparecer diez minutos después rara vez tiene un problema de hardware. Lo habitual es que haya un ataque en marcha contra el puerto 30120, y ocurre justo cuando hay más jugadores conectados. Este artículo muestra cómo proteger un servidor de RedM frente a ataques DDoS: primero lo que puedes asegurar tú mismo sin coste añadido, después el límite físico de esas medidas, y al final lo que tiene que ocurrir en la red que hay delante del servidor cuando el ataque es más grande que tu línea.

Todos los datos se refieren a un FXServer con gamename rdr3 sobre Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. Los comandos están escritos para root; si trabajas como usuario normal, antepón sudo. RedM es la modificación de Red Dead Redemption 2 de Cfx.re y el proyecto hermano de FiveM. Los dos funcionan sobre el mismo programa de servidor, por lo que una parte de la técnica de red es realmente idéntica. Donde eso ocurre, aquí lo tienes en una frase y la parte detallada en el artículo Proteger tu servidor de FiveM frente a ataques DDoS. Todo lo demás de este texto es específico de RedM.

Si el ataque está en marcha ahora mismo: no cambies nada en la server.cfg y no reinicies el servidor. Guarda primero las mediciones (consulta el apartado "Recoger mediciones"), porque cuando el ataque pase habrán desaparecido.

Por qué los servidores de RedM son tan a menudo objetivo de ataques DDoS

Un servidor de RedM es un objetivo más rentable de lo que su número de jugadores deja suponer. El motivo es el tamaño de la escena, no su pequeñez. En septiembre de 2026, los rastreadores públicos de listas de servidores contaban unos 2.000 servidores de RedM activos con unos 12.400 jugadores simultáneos, frente a unos 39.000 servidores de FiveM con unos 325.000 jugadores. Quien deja fuera de combate uno de los 2.000 servidores de RedM saca de la red una parte bastante mayor de toda la escena que quien golpea uno de los 39.000 servidores de FiveM. Para un atacante que quiere dañar a un proyecto de la competencia, la palanca es por tanto mucho mayor.

A eso se suma la estructura de las comunidades. El roleplay de RedM vive de sesiones fijas a horas fijas, muchas veces con inscripción y aprobación de personaje. Una caída a las ocho de la tarde no afecta a unos jugadores cualesquiera, sino justo a los que se habían apuntado para esa noche. Además, muchos proyectos funcionan como hobby con un presupuesto pequeño, dependen de un único servidor barato y no tienen una segunda instancia a la que cambiar. Casos documentados públicamente en la escena de RedM describen series de ataques durante meses con una frecuencia casi diaria, que golpearon a la vez al servidor de juego y al servidor de voz independiente.

A ello se añade un detalle técnico: el tráfico del juego va por UDP. UDP es un protocolo de transporte sin conexión: no hay un establecimiento de conexión que el servidor pueda exigir, y las direcciones de origen se pueden falsificar. Un atacante no necesita entonces entrar en tu servidor de RedM ni dirigirse a él correctamente para generarle carga. Qué es exactamente un ataque DDoS y cómo se monta lo explica el artículo ¿Qué es un ataque DDoS?.

Los puertos que de verdad importan

Un servidor de RedM se enlaza por defecto a un único puerto, y lo hace en los dos protocolos. En la server.cfg se indica así:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

La línea set gamename rdr3 es la única que distingue a un servidor de RedM de uno de FiveM. Si falta, ese mismo FXServer se registra como servidor de GTA V y un cliente de RedM no llega a conectarse. RedM no tiene un puerto de query propio ni un puerto RCON propio: la consulta del servidor, el establecimiento de la conexión, el tráfico del juego y RCON van todos por las mismas dos entradas en el 30120. Estos son los datos duros:

De los cuatro puertos mencionados, exactamente dos deben estar en la red abierta: 30120 TCP y 30120 UDP. El puerto 40120 y el puerto 3306 no pintan nada ahí, y SSH en el puerto 22 debería estar limitado a tus propias direcciones. Ese es el error evitable más frecuente en los servidores de RedM, porque muchos proyectos arrancan con una receta de txAdmin ya hecha y después no comprueban nunca qué ofrece el servidor hacia fuera.

Lo que puedes hacer tú mismo antes de gastar dinero

Este apartado es el más largo, y es a propósito. Un servidor de RedM bien configurado aguanta por su cuenta los ataques pequeños y medianos, esté alojado donde esté. El orden está elegido a conciencia: primero mides, después cierras y solo entonces limitas.

1. Inventario: ¿qué está escuchando realmente?

Antes de escribir una sola regla, mira qué ofrece tu servidor hacia fuera. No lo adivines, compruébalo:

ss -lntup

La columna interesante es la de la dirección local. 0.0.0.0:30120 y [::]:30120 significan "accesible desde todo internet", 127.0.0.1:3306 significa "solo local" y no necesita ninguna regla de firewall. Junto al FXServer, en un servidor de RedM aparecen con regularidad txAdmin en el 40120, MariaDB en el 3306, un servidor web para la página del proyecto y de vez en cuando un servicio de voz. La vista del atacante te la da un escaneo de puertos desde fuera:

nmap -Pn -p- --min-rate 1000 IP.DE.TU.SERVIDOR

2. Dejar abiertos solo el 30120 TCP y el 30120 UDP

A RedM le bastan dos aperturas hacia fuera, todo lo demás se restringe o directamente no se publica. Con UFW queda así, y en este orden exacto para que no te quedes fuera de tu propio servidor:

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sustituye 203.0.113.10 por tu propia dirección. En una conexión con dirección cambiante esto resulta poco práctico; el camino mejor está en el apartado siguiente, el de txAdmin. La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor.

La base de datos no tiene nada que hacer en la red abierta bajo ningún concepto. VORP, RSGCore y RedEM:RP necesitan todos una MariaDB o MySQL, normalmente a través de oxmysql con una cadena de conexión en la server.cfg. Esa conexión es local, así que el puerto no tiene por qué ser accesible desde fuera. Comprueba en /etc/mysql/mariadb.conf.d/50-server.cnf que ahí ponga:

bind-address = 127.0.0.1

3. Asegurar los endpoints HTTP del FXServer

El FXServer responde en la parte TCP del 30120 a peticiones HTTP sin que nadie tenga que arrancar Red Dead Redemption 2. Mira qué entrega ahí tu servidor de RedM:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

/players.json lista los jugadores conectados junto con sus identificadores, /info.json la configuración del servidor y los recursos cargados, /dynamic.json la ocupación actual. Justo esos tres endpoints son la vía de ataque de capa 7 documentada contra los servidores de FiveM y RedM: son accesibles sin autenticación, se pueden consultar tantas veces como uno quiera, cada consulta le cuesta trabajo a tu servidor y el contenido le revela a un atacante cuándo merece la pena atacar. Dos contramedidas no cuestan nada. La primera: los endpoints de los jugadores no pintan nada en la respuesta, y para eso basta una línea en la server.cfg:

sv_endpointPrivacy true

Este ajuste oculta las direcciones IP de tus jugadores en las salidas públicas del servidor. La segunda: si tu bot de Discord o la página de tu proyecto muestran el número de jugadores, no consultes el endpoint desde el visitante, guarda el resultado en caché a intervalos fijos. Así, una página de estado muy visitada genera una consulta por intervalo en lugar de una por visitante. En una escena pequeña como la de RedM eso pesa el doble, porque un único bot de estado puede estar integrado a la vez en varios servidores de Discord.

4. Sacar txAdmin del puerto 40120 de la red abierta

txAdmin es la interfaz de administración que viene incluida en el build del FXServer para FiveM y RedM, y escucha por defecto en el 40120 TCP. Detrás está el acceso completo a tu servidor: reinicios, lista de baneos, base de datos de jugadores, gestión de recursos. Si no tienes una dirección IP fija para la regla de apertura, deja el puerto cerrado desde fuera y llega hasta él mediante un reenvío de puerto local con SSH; después abres en el navegador http://127.0.0.1:40120:

ssh -N -L 40120:127.0.0.1:40120 root@IP.DE.TU.SERVIDOR

Quien deja txAdmin a la vista de todos se lleva dos problemas de una vez: una pantalla de acceso contra la que se pueden lanzar floods de intentos de entrada, y un servicio que hace trabajo en cada petición aunque no tenga nada que ver con el juego. En caso de duda, enlaza txAdmin directamente en local, haciendo que el servicio escuche solo en 127.0.0.1.

5. Limitar las conexiones y las tasas de paquetes por dirección de origen

Contra los ataques pequeños y los bots mal hechos ayuda un límite superior por dirección de origen. Las dos reglas valen para el 30120, es decir, para los dos protocolos del juego:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

La primera regla descarta las conexiones TCP nuevas en cuanto una dirección tiene más de ocho abiertas a la vez; la segunda descarta los paquetes UDP a partir de más de 500 paquetes por segundo sostenidos desde el mismo origen. Los valores de partida son aquí algo más bajos que en un servidor de FiveM, porque un servidor de RedM con 32 slots genera sencillamente menos conexiones legítimas por dirección. Pero los valores de partida no son verdades absolutas: una noche de rol llena genera muchos más paquetes que un servidor vacío, y quien ajusta demasiado fino echa fuera a sus propios jugadores. Mide primero una semana de funcionamiento normal.

Dos avisos al respecto. Las reglas de iptables a secas desaparecen tras un reinicio; en Debian y Ubuntu se guardan así:

apt-get install -y iptables-persistent
netfilter-persistent save

Y con UFW, ese tipo de reglas van en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload. Otro cuello de botella que se pasa por alto a menudo es el seguimiento de conexiones del kernel: si se llena, el servidor descarta también los paquetes legítimos y en el registro aparece "nf_conntrack: table full". El valor actual y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. Asegurar los 32 slots frente a los floods de intentos de entrada

Un servidor de RedM tiene sin OneSync exactamente 32 slots. Con OneSync son 48, y por encima de eso hace falta una suscripción a Element Club para llegar hasta 1.024 plazas. Esa cifra es relevante para la seguridad, porque es el límite superior que un atacante tiene que llenar: quien mantiene 32 intentos de entrada abiertos a la vez ocupa por completo un servidor estándar, sin que un solo jugador llegue de verdad al juego. En un proyecto de FiveM con 128 plazas, ese mismo umbral es cuatro veces más alto.

Una ventaja propia de RedM lo compensa en parte: RedM exige una copia real de Red Dead Redemption 2, comprada en Steam, Epic Games o Rockstar, y además el launcher de Rockstar. Un flood de intentos de entrada con miles de cuentas desechables, como es habitual en los juegos gratuitos, cuesta aquí dinero de verdad. Por eso los ataques se desplazan al nivel de red y a los endpoints HTTP, donde no hace falta ninguna copia del juego.

Contra todo lo que usa la vía normal de entrada sigue funcionando una whitelist. Se implementa en el lado del servidor en el evento playerConnecting, donde retienes la conexión con las funciones de deferrals, compruebas el identificador y solo entonces das paso. A eso se suman una comprobación estricta de la cuenta y un límite de jugadores realista:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance es un valor de 1 a 5 e indica cuánto puede variar el identificador de un jugador en un proveedor; 1 es el ajuste más estricto. sv_authMinTrust va también de 1 a 5 y describe lo improbable que tiene que ser una identidad falsificada; aquí 5 es el valor más estricto. Pon una contraseña de RCON solo si de verdad necesitas RCON, porque ese acceso está en el mismo puerto abierto 30120. Y hay algo que tiene que quedar claro: una whitelist protege tu lógica de juego, no tu línea. Un atacante que inunda tu servidor no quiere entrar. Sus paquetes se rechazan, pero han llegado igualmente, y ese es justo el problema.

7. Valorar bien la entrada en la lista de servidores de RedM

Aquí conviene la honestidad antes que el pensamiento mágico: tu dirección IP no se puede mantener en secreto. RedM usa la misma infraestructura de servidores maestros de Cfx.re que FiveM, y la entrada de la lista contiene en el campo connectEndPoints el endpoint de conexión en texto claro. A través de la interfaz pública en servers-frontend.fivem.net se puede consultar la dirección asociada a cualquier código cfx.re, para RedM igual que para FiveM. Quien no necesite en absoluto la entrada pública, porque el proyecto funciona solo por Discord y conexión directa, puede llevar el servidor como privado con sv_master1 "": entonces ya no se puede entrar a través de la lista de servidores. Eso cuesta, eso sí, toda la visibilidad para los jugadores nuevos, y en una escena con 2.000 servidores la visibilidad es el verdadero motor de crecimiento.

Hay dos costumbres más eficaces. No publiques tú mismo la dirección IP en bruto en ninguna parte, ni en el canal de Discord ni en la página del proyecto. Y conecta a tus jugadores mediante un nombre de host, para poder cambiar la dirección llegado el caso sin que se rompan todas las referencias. El clásico aquí son los registros DNS antiguos: un registro A olvidado que apunte a la dirección anterior deja sin efecto cualquier cambio.

8. Comprobar en el lado del servidor los eventos de VORP, RSGCore y RedEM

Muchas caídas que se comunican como ataque DDoS se deben a un único script. Los recursos de RedM se comunican mediante eventos de red, y un evento que el servidor ejecuta sin comprobarlo es una puerta abierta: quien lance desde el cliente un TriggerServerEvent con valores arbitrarios puede generar dólares, hacer aparecer caballos o disparar consultas a la base de datos en bucle hasta que el servidor se pare. Eso afecta por igual a los tres frameworks extendidos: VORP Core, que desde 2020 tiene la mayor base de scripts, RSGCore y el más antiguo RedEM:RP.

Especialmente sensibles son los recursos de inventario y de personaje, porque escriben en la base de datos en cada llamada. Un bucle de eventos que guarda diez veces por segundo el estado del inventario carga un servidor de RedM más que muchas avalanchas de paquetes, y viene desde dentro, donde ningún firewall actúa.

Tres reglas atajan la mayor parte. Registra con RegisterNetEvent únicamente los eventos que de verdad deban venir del cliente. No te fíes nunca de los valores que manda el cliente, determina el jugador en el lado del servidor a partir de source. Y limita cuántas veces puede un jugador disparar el mismo evento, sobre todo en todo lo que consulte la base de datos. Si el servidor va a tirones mientras la línea está tranquila, resmon 1 en la consola del cliente muestra el tiempo de proceso por recurso, y el culpable suele estar arriba del todo.

9. Recoger mediciones antes de necesitarlas

El paso más importante es el que casi nadie da antes de tiempo: crear una base de comparación mientras todo funciona con normalidad. Sin un valor normal no puedes decir, después de un incidente, si 40.000 paquetes por segundo eran muchos o simplemente un martes por la noche con buena afluencia. Con apt-get install -y vnstat sysstat la medición corre de forma permanente. Durante un incidente bastan cuatro comandos: tasas de paquetes por segundo, tasa de descartes de la interfaz, mensajes del kernel y una muestra breve del tráfico.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

Con tcpdump vale una norma: limítalo siempre con -c, porque una captura a plena carga añade trabajo a un servidor que ya está saturado. Fíjate además en si la carga está en la parte UDP o en la parte TCP del 30120. La carga en UDP apunta a una avalancha de paquetes contra el tráfico del juego, la carga en TCP a una avalancha contra los endpoints HTTP, y las dos necesitan contramedidas distintas. Cómo interpretar los valores lo explica Detectar un ataque DDoS.

El punto en el que estas medidas dejan de servir

Llega ahora la parte que ninguna server.cfg puede resolver. Todas las medidas anteriores corren en tu servidor, es decir, al final de la línea. Una regla de firewall decide sobre un paquete que ya ha pasado por el cable. Puedes descartarlo, pero no puedes hacer que no se haya enviado.

Echa cuentas una vez. Un servidor de juego típico está conectado a 1 Gbit/s, o sea, 125 megabytes por segundo, y la línea se llena en cuanto alguien manda más. Los ataques contra proyectos de roleplay se mueven normalmente entre 5 y 50 Gbit/s, es decir, entre cinco y cincuenta veces tu línea. Que tu regla de iptables por detrás sea buena o no ya da igual, porque los paquetes de tus jugadores dejan de pasar mucho antes.

La segunda magnitud es la tasa de paquetes, y golpea a menudo antes que el ancho de banda. Con paquetes pequeños de 64 bytes caben en una línea de 1 Gbit/s unos 1,49 millones de paquetes por segundo. Un kernel de servidor normal procesa, según la CPU y la tarjeta de red, unos cientos de miles antes de empezar a descartar. Así que un ataque que no llena ni un tercio de tu línea puede dejar tu servidor de RedM fuera de combate igualmente, porque el tiempo de proceso se va en descartar. Los operadores lo viven como "pero si la carga no era ni alta y aun así se cayó todo". Justo esos lag spikes sin carga visible en el servidor son la imagen típica de un ataque por tasa de paquetes.

Para hacerse una idea de las magnitudes que se dan de verdad: en servidores de KernelHost se han filtrado, entre otros, un ataque de más de 473,4 Gbit/s con más de 41,5 millones de paquetes por segundo contra un servidor de voz y un flood UDP de más de 112,2 Gbit/s contra un servidor de juego. Para eso no existe ningún ajuste local. Los ataques volumétricos tienen que terminar en la red que hay delante del servidor.

Qué es distinto en RedM respecto a FiveM

La respuesta corta: la técnica de red es idéntica, el entorno no. Los dos funcionan sobre el mismo FXServer, los dos usan el 30120 TCP y UDP, los dos se administran con txAdmin en el 40120. Todo lo que lees arriba sobre puertos, tasas y endpoints vale para los dos. Lo que cambia son las condiciones del entorno, y son justo ellas las que deciden con qué rapidez surte efecto un ataque:

Tres puntos de esta tabla son decisivos para la defensa. Primero, la escena más pequeña hace que cada servidor de RedM valga más como objetivo, porque una caída afecta a una parte mayor de los jugadores. Segundo, el límite estándar de 32 slots baja el umbral a partir del cual un flood de intentos de entrada cierra el servidor. Y tercero, para RedM hay en la red menos recetas de protección ya hechas que para FiveM, por lo que muchos proyectos funcionan con una configuración estándar sin tocar. La defensa es la misma, el punto de partida es peor.

Lo que KernelHost pone frente a esos ataques

La protección permanente incluida en todos los servidores

La protección DDoS de KernelHost está estructurada en dos niveles y activa de forma permanente, sin que tengas que activar, pedir ni configurar nada:

• Nivel 1: 17 Tbps de capacidad de mitigación en la red global de scrubbing. Los ataques volumétricos se limpian cerca de su origen, antes de que lleguen al centro de datos.
• Nivel 2: filtrado Arbor en tiempo real con 3,2 Tbps en Fráncfort del Meno. Justo delante del servidor se reconocen y se descartan los patrones propios de cada protocolo, paquete a paquete.

Dos propiedades marcan la diferencia. La protección funciona de forma permanente y no tiene que reaccionar primero a un ataque, así que no hay unos minutos iniciales en los que el servidor de RedM esté fuera. Y no se utiliza null-routing: tu dirección IP se queda en la red y solo se descartan los paquetes dañinos. Quien retira la dirección IP de la red consigue para ti el mismo resultado que el atacante. La ubicación del filtrado es Frankfurt am Main. Qué juegos y protocolos están cubiertos lo detalla Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para proyectos bajo fuego continuo

Algunos proyectos no reciben ataques de vez en cuando, sino de forma dirigida y durante semanas. Para esos existe la Advanced DDoS Protection desde 50,00 € al mes, PrePaid y sin permanencia mínima. La diferencia no está en más capacidad, sino en el control:

• IP de protección dedicada del núcleo de red de Fráncfort, a la que se cambia tu servidor dentro de nuestra propia red. En tu lado no hace falta ninguna modificación.
• Reglas de protección autogestionables por puerto y protocolo en el área de cliente: defines por separado qué se permite en 30120 UDP y qué en 30120 TCP, sin tener que abrir un ticket para ello. En RedM esa separación resulta especialmente útil, porque el tráfico del juego y los endpoints HTTP comparten el mismo número de puerto y tienen patrones completamente distintos.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso.
• Perfil de protección adaptado a la aplicación. Para servidores Cfx.re en el 30120 hay un perfil adecuado, igual que para aplicaciones modificadas y propias en cualquier puerto TCP o UDP.

Las dos cosas valen para servidores alojados en KernelHost. Si tu proyecto de RedM funciona ahora mismo en otro sitio y lo sacan de la red con regularidad, la recomendación es el traslado, no un producto adicional.

Los dos niveles, comparados

Para la mayoría de los proyectos de RedM basta con la protección permanente incluida junto a una configuración limpia del servidor. La Advanced DDoS Protection es la respuesta a que alguien se lo tome como algo personal.

Errores frecuentes y sus soluciones

"Mi servidor no aparece en la lista de servidores de RedM, sospecho de un ataque": comprueba primero la configuración. Si falta set gamename rdr3, el FXServer se registra como servidor de GTA V y no sale en la lista de RedM. Si falta la clave de licencia de portal.cfx.re o no es correcta, tampoco llega a crearse la entrada. Un ataque tiene otro aspecto: la entrada sigue ahí y lo que falla es la conexión.

"Cientos de jugadores reciben un error al entrar, parece una avalancha": normalmente es un problema de build del juego. Si sv_enforceGameBuild no encaja con lo que esperan tus recursos, el cliente avisa con "server specified an invalid game enforcement". Pon el valor que exija tu framework, habitualmente 1436 o 1491, y reinicia el servidor por completo.

"Cambié la dirección IP y dos horas después estaba otra vez fuera": el atacante ha sacado la dirección nueva de la misma fuente que la antigua, normalmente la entrada de la lista, un bot de Discord o un registro DNS viejo. Cambiar de dirección da tiempo, no es una solución.

"Mis reglas de iptables no hacen nada": hay tres causas frecuentes. Las reglas están detrás de las cadenas de UFW y no se alcanzan nunca, se perdieron con el último reinicio (entonces ayudan netfilter-persistent save o una entrada en /etc/ufw/before.rules), o el ataque es volumétrico y la regla trabaja correctamente en una línea que ya está llena. Comprueba con iptables -L INPUT -n -v si suben los contadores de aciertos. Si se quedan a cero, la regla no se alcanza.

"El servidor funciona, pero todos los jugadores tienen rubber banding": eso suele ser un script antes que un ataque. Mira primero con resmon 1 si algún recurso se está comiendo el tiempo de proceso, y revisa los recursos de inventario y de personaje de tu framework. Si sar -n DEV 1 10 no muestra nada llamativo, no era un ataque DDoS.

"txAdmin muestra cientos de intentos de conexión fallidos": eso es un flood de intentos de entrada y golpea a la lógica del juego, no a la línea. Contra eso funcionan la whitelist, la comprobación de la cuenta con sv_authMinTrust y el límite de conexiones por dirección de origen.

"Mi proveedor anterior bloqueó mi dirección IP": eso es null-routing. Con ello el proveedor protege su propia red; para ti el resultado es idéntico al de un ataque con éxito, normalmente durante horas después. En caso de duda, pregunta si se filtra o si se hace null-routing. La respuesta dice más sobre tu disponibilidad que cualquier dato de hardware.

"En el tcpdump no veo nada llamativo": si el tráfico ya se filtra en la red anterior, al servidor no llega nada, como cabe esperar. Ese es el caso normal cuando el filtrado funciona. Al revés también vale: si la línea está saturada, puede que ni siquiera te llegue la sesión SSH con la que querías medir. Usa entonces la consola VNC del área de cliente, que funciona con independencia de la red del sistema huésped.

En resumen

• Un servidor de RedM necesita exactamente dos puertos abiertos: 30120 TCP y 30120 UDP, definidos con endpoint_add_tcp y endpoint_add_udp. No existe un puerto de query propio ni un puerto RCON propio.
• txAdmin en el 40120 TCP y la base de datos en el 3306 TCP no pintan nada en la red abierta: su sitio es tu propia dirección y, respectivamente, 127.0.0.1.
• sv_endpointPrivacy true saca las direcciones IP de los jugadores de las salidas públicas, y un estado del servidor guardado en caché quita carga de /players.json, la vía de ataque de capa 7 documentada contra los servidores Cfx.re.
• Un servidor de RedM tiene 32 slots sin OneSync, 48 con OneSync y hasta 1.024 con Element Club. Cuanto menor es el número de slots, más barato sale un flood de intentos de entrada, y más importantes son la whitelist y la comprobación de la cuenta.
• RedM y FiveM funcionan sobre el mismo FXServer y se distinguen solo por set gamename rdr3. La defensa de red es por eso idéntica, el entorno no: unos 2.000 servidores de RedM frente a unos 39.000 de FiveM convierten cada proyecto de RedM en un objetivo más valioso.
• Las reglas de firewall locales se acaban donde la línea está llena: 1 Gbit/s son 125 megabytes por segundo, y con paquetes de 64 bytes caben ahí unos 1,49 millones de paquetes por segundo. Todo lo que pase de ahí tiene que terminar en la red que hay delante del servidor.
• En KernelHost, la protección permanente en dos niveles está incluida en cada paquete de servidor, activa desde el aprovisionamiento y sin null-routing. Quien quiera dirigir él mismo el filtrado recibe con la Advanced DDoS Protection, desde 50,00 € al mes, una IP de protección dedicada y reglas propias por puerto y protocolo.

Si tu proyecto de RedM ya está en KernelHost, el filtrado está activo sin que tengas que hacer nada. Si aun así notas algo raro, abre un ticket de soporte para que ajustemos con más precisión las reglas de filtrado de tu dirección IP. Durante un ataque en curso puedes localizarnos además en el chat de emergencia de WhatsApp en el +43 650 8209883.