Proteger un servidor de DayZ frente a ataques DDoS

Un servidor de DayZ que por la noche expulsa a todos los jugadores en mitad de la partida y después desaparece durante minutos del navegador de servidores rara vez tiene un problema de hardware. Lo habitual es que haya un ataque en marcha, y justo cuando hay más jugadores conectados o cuando toca el reinicio programado. Si quieres proteger tu servidor de DayZ frente a ataques DDoS necesitas por eso las dos cosas: una apertura de puertos limpia en el servidor y un filtrado en la red que hay delante. Este artículo muestra primero qué puedes asegurar tú mismo sin coste añadido, después dónde acaban técnicamente esas medidas y, al final, qué tiene que pasar entonces delante del servidor.

Todos los datos se refieren a un servidor dedicado propio de DayZ con serverDZ.cfg, da igual si corre bajo Windows Server o bajo Debian y Ubuntu sobre una capa de compatibilidad. Bohemia Interactive no distribuye un programa de servidor nativo para Linux listo para producción en la rama estable, y la compilación experimental para Linux solo acepta clientes experimentales. Los comandos de Linux están escritos para root; si trabajas como usuario normal, antepón sudo.

Si el ataque está en marcha ahora mismo: no cambies nada en la serverDZ.cfg y no reinicies el servidor. Un reinicio de DayZ vuelve a cargar los mods y la economía central y te cuesta varios minutos en los que el servidor está fuera con toda seguridad. Guarda primero las mediciones (consulta el apartado "Registrar los datos"), porque cuando el ataque pase habrán desaparecido.

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

DayZ reúne varias características que convierten a un servidor en un objetivo cómodo. Primero, un servidor de comunidad publica su dirección por sí solo: para aparecer en el navegador de servidores del juego y en el DZSA Launcher tiene que responder a las consultas de Steam, y esa respuesta contiene la dirección IP y el puerto en texto claro. Un atacante no tiene por tanto que averiguar nada, solo tiene que leer una lista.

Segundo, la rutina diaria de un servidor de DayZ es pública. Prácticamente todos los proyectos se reinician de forma automática cada tres o cuatro horas, lo anuncian por mensaje de chat y escriben el plan en el Discord. Un ataque que cae justo en esa franja actúa por partida doble: el servidor no está accesible de todos modos, y los jugadores que se quedan en la sala de espera se van a otra parte.

Tercero, lo que se juegan los jugadores es mucho. Una caída en el minuto equivocado no significa en DayZ solo frustración, sino equipo perdido, raids interrumpidos y una base que se queda sin protección en el mundo. Justo por eso los encargos vienen casi siempre de jugadores baneados, de grupos enemistados y de proyectos competidores. Un ataque a través de uno de los servicios de booter habituales no le cuesta a quien lo lanza ni conocimientos ni un dinero digno de mención.

Cuarto, todo el tráfico de DayZ va por UDP. UDP no tiene un establecimiento de conexión que se pueda exigir, y la dirección de origen se puede falsificar. Por tanto, un atacante no necesita entrar en tu servidor ni dirigirse a él correctamente para generarle carga. Que ni siquiera el fabricante se libra lo demostró febrero de 2025: los servicios en línea de Bohemia Interactive para DayZ y Arma Reforger estuvieron más de una semana bajo fuego DDoS, confirmado el 3 de febrero de 2025 y todavía sin resolver el 6 de febrero de 2025, y los servidores de la comunidad se vieron afectados de paso. Qué es en detalle un ataque DDoS lo explica el artículo ¿Qué es un ataque DDoS?.

Los puertos de un servidor de DayZ: tabla de datos

Un servidor de DayZ habla exclusivamente UDP. No existe un puerto de juego TCP. El único valor que en DayZ está realmente fijado es 2302/UDP como puerto de juego; todo lo demás es configurable y cambia según el hoster. Mira por eso en tu propia línea de inicio y en tu propia serverDZ.cfg en lugar de fiarte de un valor estándar.

Hay dos valores que provocan confusión con regularidad, así que aquí va la aclaración. El puerto de consulta de Steam: la configuración de ejemplo que entrega Bohemia pone steamQueryPort = 2305;, mientras que una buena parte de los hosters usa 27016/UDP. Los dos valores son válidos, lo único decisivo es el valor que esté en tu archivo. El puerto de RCon de BattlEye: aquí no hay absolutamente ningún estándar obligatorio. La regla empírica extendida es el puerto de juego más tres, es decir, 2305, y otros hosters ponen 2310. Desde DayZ 1.13, BattlEye evalúa de forma fiable el parámetro RConPort de la BEServer_x64.cfg; antes el puerto era difícil de prever.

De ahí se deriva una trampa que alcanza a muchos operadores: no pongas nunca steamQueryPort y RConPort en el mismo valor. Si tu configuración reserva 2305 para la consulta de Steam, RCon va en otro puerto, por ejemplo el 2310.

Por qué el puerto de consulta de Steam es el puerto más sensible

El puerto de consulta de Steam responde a las tres consultas A2S_INFO, A2S_PLAYERS y A2S_RULES. A2S_INFO entrega el nombre del servidor, el mapa, el número de jugadores y la versión; A2S_PLAYERS, los nombres de los jugadores conectados; A2S_RULES, las variables de servidor configuradas. Cada una de esas respuestas es claramente más grande que la petición que la ha provocado, y eso es justo lo que hace que el puerto sea peligroso por partida doble.

Para ti como objetivo significa: un atacante puede mantener ocupado tu puerto de consulta con unos pocos bytes por petición, mientras tu servidor construye y envía cada vez una respuesta completa. Para terceros significa: un atacante puede consultar tu servidor con dirección de origen falsificada y dirigir las respuestas hacia su verdadero objetivo. Tu servidor no es entonces solo víctima, sino amplificador. Por eso Valve amplió A2S_INFO en diciembre de 2020 con una consulta de desafío: el servidor responde primero con un número aleatorio que quien pregunta tiene que devolver. Eso desactiva buena parte de la amplificación, pero no la termina, porque ni mucho menos todas las consultas siguen ese camino.

DayZ tiene aquí una particularidad que otros juegos no tienen: te consultan dos listas de servidores distintas, el navegador de servidores de comunidad integrado y el muy extendido DZSA Launcher. Cerrar sin más el puerto de consulta no es por tanto una opción, porque entonces tu proyecto desaparece de las dos listas aunque la conexión directa siga funcionando. Limitar en lugar de cerrar es la respuesta correcta.

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 DayZ bien configurado aguanta por su cuenta los ataques pequeños y medianos, esté alojado donde esté.

1. Inventario: qué puertos abre realmente tu servidor de DayZ

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

ss -lnup
ss -lntup

En Windows Server, el símbolo del sistema da la misma imagen:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

Lo interesante es la columna con la dirección local. 0.0.0.0:2302 significa "accesible desde todo internet", 127.0.0.1:2310 significa "solo local" y no necesita ninguna apertura. Después lee los valores reales directamente de tus archivos de configuración, en lugar de fiarte de una guía:

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

La vista del atacante la da un escaneo de puertos UDP desde fuera, ejecutado desde otra máquina:

nmap -Pn -sU -p 2302-2310,27015-27020 IHRE.SERVER.IP.ADRESSE

2. Abrir solo lo que la línea de inicio y la serverDZ.cfg necesitan de verdad

A DayZ le bastan dos aperturas hacia fuera: el bloque del puerto de juego y el puerto de consulta. Todo lo demás se restringe a tu propia dirección 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 2302:2305/udp comment 'DayZ Spielport'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye RCon'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sustituye 203.0.113.10 por tu propia dirección y 27016 por el valor que esté realmente en tu línea steamQueryPort. La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor. En un servidor Windows vale el mismo principio: una regla de entrada por grupo de puertos, el escritorio remoto limitado a tu propia dirección y todo lo demás bloqueado.

3. Limitar el puerto de consulta de Steam en lugar de cerrarlo

Un límite superior por dirección de origen separa las listas de servidores reales de las inundaciones de consultas. Un navegador de servidores te pregunta al ritmo de un segundo, un atacante al ritmo de un milisegundo:

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

La primera regla descarta las consultas de Steam a partir de más de diez por segundo sostenidas desde la misma fuente; la segunda, los paquetes de juego a partir de más de 600 por segundo. Las dos cifras son puntos de partida, no verdades absolutas. Un servidor lleno con 60 jugadores genera bastantes más paquetes que uno vacío, y quien ajusta demasiado fino echa fuera a sus propios jugadores o se cae de la lista de servidores. Mide primero una semana de funcionamiento normal.

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

Con UFW, ese tipo de reglas van en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload. Además, la biblioteca de servidor de Steam tiene su propio freno para los paquetes sin conexión: la variable de entorno STEAM_GAMESERVER_RATE_LIMIT_200MS descarta todos los paquetes A2S de una dirección en cuanto en una ventana de 200 milisegundos llegan más del valor fijado.

El tercer punto no cuesta nada: si tu bot de Discord o tu página de proyecto muestran el recuento de jugadores, no consultes el servidor 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.

4. Sacar el RCon de BattlEye de la red abierta

BattlEye es el componente anti-cheat de DayZ y se activa en la serverDZ.cfg con BattlEye = 1;. La administración remota, en cambio, está en un archivo propio, la BEServer_x64.cfg del directorio de BattlEye, junto a BEServer_x64.dll, que la línea de inicio fija con -BEpath=:

RConPassword EinLangesZufallspasswort
RConPort 2310
RestrictRCon 0

Tres reglas al respecto. Primera: el puerto de RCon es UDP, no TCP. Una regla de firewall que por descuido diga proto tcp no filtra nada y al mismo tiempo deja a las herramientas de administración sin llegar a ninguna parte. Segunda: limita el puerto a las direcciones de tus administradores. Quien no tenga una dirección fija deja el puerto cerrado del todo desde fuera y arranca la herramienta de administración directamente en el servidor, accesible por SSH o escritorio remoto. Tercera: RestrictRCon 1 limita los comandos ejecutables por RCon y es el ajuste correcto en cuanto tiene acceso más de una persona.

Un puerto de RCon abierto es dos cosas a la vez: una invitación a ir probando contraseñas y un puerto UDP más que se puede inundar. Las dos desaparecen en cuanto la apertura vale solo para un puñado de direcciones.

5. Cola de acceso, whitelist y agotamiento de plazas

DayZ no atiende todas las conexiones a la vez, sino mediante una cola. Cinco valores de la serverDZ.cfg la controlan:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

loginQueueConcurrentPlayers establece cuántos jugadores entran a la vez (valor por defecto 5), y loginQueueMaxPlayers limita la cola en sí (valores habituales entre 100 y 500). Justo ahí ataca el agotamiento de plazas: un atacante no necesita ancho de banda, solo necesita suficientes cuentas o intentos de conexión para ocupar la cola. Los jugadores reales ya no pasan, aunque el servidor funcione técnicamente sin un fallo. guaranteedSlots reserva plazas para tu equipo, para que en esa situación exacta aún puedas entrar tú mismo al servidor.

Contra eso sirve la whitelist integrada. Se activa con enableWhitelist = 1; y lee a continuación el archivo profiles/whitelist.txt, con un Steam64 ID por línea. Cada ID que no esté listado se rechaza en la conexión. El archivo se lee al arrancar el servidor, así que los cambios necesitan un reinicio. Una password adicional en la serverDZ.cfg funciona de forma parecida, pero es más débil, porque una contraseña se pasa de mano en mano y un Steam64 ID no.

Una cosa tiene que quedar clara: una whitelist protege tus plazas de jugador, 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 punto.

6. Mods, verificación de firmas y la franja posterior al reinicio

En DayZ los mods no son solo una cuestión de comodidad, son una parte de la superficie de ataque. Cuatro ajustes de la serverDZ.cfg deben estar puestos en cualquier caso:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

verifySignatures = 2 comprueba cada archivo PBO contra la firma .bisign correspondiente y necesita para ello los archivos .bikey adecuados en la carpeta keys. forceSameBuild = 1 exige exactamente la misma versión del juego que la del servidor. allowFilePatching = 0 rechaza a los clientes que arrancan con archivos de juego modificados. Ninguno de estos ajustes detiene un ataque volumétrico, pero los tres cierran la vía por la que un cliente manipulado descoloca tu servidor.

El segundo punto es el más importante y casi siempre se pasa por alto: la fase de arranque. Un servidor de DayZ carga al arrancar primero su lista de mods desde la línea de inicio y después la economía central con todas las tablas de loot. En un servidor muy modificado eso son con facilidad varios minutos en los que el servidor no responde a una sola consulta de Steam:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@IhrMod;@NochEinMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Como prácticamente todos los proyectos se reinician cada tres o cuatro horas y encima anuncian ese plan, la franja es trivial de acertar para un atacante. Tres contramedidas son eficaces y no cuestan nada. Mantén la lista de mods lo más corta posible, porque cada mod adicional alarga exactamente esa franja. Pon las horas de reinicio en valores poco redondos en lugar de en la hora en punto. Y mide una vez cuánto dura realmente tu arranque, en lugar de estimarlo: con timeStampFormat = "Full"; y un logFile definido, la duración queda después en el registro.

7. Seguimiento de conexiones, búferes de recepción y parámetros del kernel

Un cuello de botella que se pasa por alto a menudo es el seguimiento de conexiones del kernel. UDP no conoce conexiones, pero el kernel crea de todos modos una entrada por cada par de dirección de origen y dirección de destino. Si la tabla se llena, el servidor descarta también los paquetes legítimos y en el registro aparece "nf_conntrack: table full". El estado actual y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Para un servidor de juego puro, la solución limpia es no dejar que el tráfico del juego llegue siquiera a seguirse, y además ampliar los búferes de recepción y la cola de la tarjeta de red:

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

Atención: NOTRACK y las reglas con estado se excluyen mutuamente. Quien saca el puerto de juego del seguimiento no puede usar ya para ese puerto ninguna regla con -m conntrack --ctstate, porque entonces la apertura deja de aplicarse. De forma permanente, los valores de sysctl van en /etc/sysctl.d/, porque si no desaparecen con el siguiente reinicio.

8. Tu dirección IP está en el navegador de servidores

Aquí conviene la honestidad antes que el pensamiento mágico: la dirección IP de un servidor público de DayZ no se puede mantener en secreto. Cualquier jugador que se haya conectado una vez la conoce, el navegador de servidores la publica y el DZSA Launcher la guarda en caché. Cambiar de dirección te da horas, rara vez días.

Más eficaces son dos costumbres. No publiques la dirección IP en bruto en ningún sitio más, ni en el mensaje fijado del Discord ni en la página del proyecto. Y ordena tus registros DNS: un registro A olvidado que apunte a la dirección anterior deja sin efecto cualquier cambio, y en eso fracasan la mayoría de los cambios. Quien deje además un servicio de estado corriendo en el servidor antiguo revela la dirección nueva de paso.

9. Registrar los datos para no tener que adivinar durante el ataque

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 sábado por la noche. Del lado del servidor activas para eso los registros integrados:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

logAverageFps es el valor más honesto que entrega DayZ. Si la tasa de fotogramas del servidor se hunde mientras el número de jugadores se mantiene, es un problema de mods o de economía. Si la tasa de fotogramas se mantiene estable mientras los jugadores salen despedidos, es cosa de la red. Del lado del sistema, las mediciones corren de forma permanente con apt-get install -y vnstat sysstat, y durante un incidente bastan cuatro comandos:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp port 2302 -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. Cómo interpretar los valores lo explica Detectar un ataque DDoS en el servidor.

Dónde acaba la protección propia: ancho de banda y tasa de paquetes

Llega ahora la parte que ningún archivo de configuración 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.

En DayZ, la tasa de paquetes golpea a menudo antes que el ancho de banda, y tiene un motivo sencillo: el tráfico del juego consiste en muchos paquetes UDP pequeños, no en pocos grandes. Por eso, un ataque que no llena ni un tercio de tu línea puede dejar tu servidor 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í todos tenían picos de lag y fueron saliendo uno tras otro".

Los ataques volumétricos tienen que terminar en la red que hay delante del servidor. Eso no es una afirmación comercial, es física.

Protección DDoS para DayZ: lo que KernelHost pone frente a esos ataques

La protección permanente que corre 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 Frankfurt am Main. 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 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. 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 2302/UDP, qué en el puerto de consulta y qué en el puerto de RCon. Justo esa separación es la palanca en DayZ, porque el tráfico del juego y el tráfico de consulta no se parecen en nada.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso en lugar de esperar a un ticket.
• Perfil de protección adaptado al juego, también para servidores muy modificados y aplicaciones propias en cualquier puerto TCP o UDP.

Los dos niveles, comparados

Para la mayoría de los proyectos de DayZ 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. Quien tenga ahora mismo su servidor de DayZ en otro sitio no puede añadir esta protección después: forma parte de la red y vale para los servidores que están en KernelHost. El camino hasta ahí es una mudanza, no un producto adicional.

Errores frecuentes y sus soluciones

"Mi servidor ha desaparecido del DZSA Launcher y del navegador de servidores, pero por conexión directa entro": en la mayoría de los casos no es un ataque, sino el puerto de consulta. O bien en steamQueryPort hay un valor distinto del que está en el firewall, o bien una limitación de tasa demasiado estrecha descarta las consultas de la lista de servidores. Comprueba los dos valores el uno contra el otro antes de sospechar de un ataque.

"RCon ya no conecta desde que filtré los puertos": el RCon de BattlEye va por UDP. Una apertura con proto tcp en el mismo puerto no sirve de nada. Comprueba además si RConPort y steamQueryPort están por descuido en el mismo valor.

"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 el navegador de servidores, un bot de estado de Discord o un registro DNS viejo. Cambiar de dirección da tiempo, no es una solución.

"El ataque llega todos los días exactamente en el reinicio": eso no es casualidad. El plan de reinicios está en el Discord y se anuncia dentro del juego, y mientras cargan los mods y la economía el servidor no responde de todos modos. Una lista de mods más corta, horas de reinicio poco redondas y un filtrado que corre de forma permanente en lugar de reaccionar primero a un ataque le quitan el efecto a ese patrón.

"Todos los jugadores tienen picos de lag, pero la red está tranquila": entonces no era un ataque DDoS. Mira primero en logAverageFps si la tasa de fotogramas del servidor se ha hundido, y después en la economía central y en la lista de mods. Si sar -n DEV 1 10 no muestra nada llamativo, no es cosa de la red.

"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.

"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 DayZ necesita hacia fuera exactamente dos cosas: el bloque del puerto de juego a partir de 2302/UDP y el puerto de consulta de Steam que esté en tu línea steamQueryPort. Todo lo demás va restringido o cerrado.
• El puerto de RCon de BattlEye no tiene ningún estándar obligatorio, va por UDP y se fija en la BEServer_x64.cfg con RConPort. Nunca pertenece a la red abierta y nunca debe tener el mismo valor que el puerto de consulta.
• El puerto de consulta se limita en lugar de cerrarse: quien lo cierra desaparece del navegador de servidores y del DZSA Launcher aunque la conexión directa siga funcionando.
• La whitelist, guaranteedSlots y la cola de acceso protegen tus plazas de jugador contra el agotamiento de plazas, pero no tu línea contra el ancho de banda.
• La franja más peligrosa de un servidor de DayZ es el reinicio programado cada tres o cuatro horas, porque los mods y la economía central tardan minutos en cargar y el momento es de dominio público.
• A partir de aproximadamente 1 Gbit/s de volumen de ataque o de unos cientos de miles de paquetes por segundo decide únicamente la red que hay delante del servidor, ya no tu firewall.
• En KernelHost, la protección permanente en dos niveles está incluida en cada paquete de servidor, sin recargo y sin null-routing. La Advanced DDoS Protection desde 50,00 € al mes se añade cuando quieres dirigir tú mismo las reglas por puerto.

Si tu proyecto 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 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.