Antes de empezar
Haz un inventario de IP públicas, puertos, protocolos y orígenes. Identifica dónde se filtra y dónde se reenvía el tráfico. Conserva medidas normales y condiciones del servicio para compararlas con un incidente, y prepara un mantenimiento si vas a cambiar reglas.
L3: tráfico de red
La capa de red considera paquetes IP y patrones volumétricos. Un flujo puede saturar la conexión antes de llegar a la aplicación, por lo que interesa filtrar aguas arriba. La capacidad total de una red no equivale a la del servidor: los 15 Tbps comunicados por CubixServ son una capacidad agregada de protección, no tu puerto individual.
L4: TCP y UDP
La capa de transporte diferencia conexiones TCP y tráfico UDP. Puertos, estados y tasas pueden formar parte de las reglas. Un perfil diseñado para una web no es automáticamente adecuado para el juego. Confirma el puerto de juego asignado y separa la administración. Un test TCP exitoso no demuestra que el recorrido UDP permita jugar correctamente.
L7: comportamiento de la aplicación
Una petición aparentemente válida puede provocar mucho trabajo. Un proxy HTTP puede examinar y limitar solicitudes HTTP, pero no entiende por ello todos los protocolos de juego. Pide endpoints y funciones concretas. En FiveM hay que diferenciar descargas HTTP y conexión del juego: proteger una parte no certifica automáticamente todas las operaciones como protegidas en L7.
Cerrar caminos directos al origen
Una dirección protegida pierde eficacia si el origen sin protección sigue accesible. Revisa DNS, descargas, administración y otros puertos. Restringe fuentes solo después de conocer todos los caminos autorizados. Un permiso de confianza demasiado amplio puede permitir saltarse el control; uno demasiado estrecho puede expulsar a usuarios legítimos. La gestión administrativa necesita una protección propia.
Contrastar red y aplicación
Durante un incidente compara tráfico entrante, filtrado, conexiones y carga del servicio. Un hilo principal o una base de datos bloqueados pueden detener el juego con una red aparentemente normal. Más capacidad de filtrado no corrige scripts costosos. Un timeout aislado tampoco prueba un ataque: comprueba pérdidas, rutas, errores y diferencias respecto al estado habitual.
Pedir condiciones verificables
Confirma alcance, banda asignada, servicios permitidos, reenvío y asistencia. Averigua si hacen falta una IP específica, un túnel o cambios en el origen. Prueba el recorrido completo con usuarios autorizados antes y después de la configuración. Una web que responde no valida cualquier juego; las pruebas de carga o ataque necesitan un marco explícitamente autorizado y coordinado.
Qué hacer en tu caso
| Situación | Próximo paso |
|---|---|
| Juego por UDP | Confirma puerto real, protocolo y perfil de filtrado. No uses una respuesta HTTP como validación completa. |
| Peticiones HTTP costosas | Revisa aplicación, límites y proxy juntos. Una reserva de red no elimina el trabajo por petición. |
| Origen externo protegido | Documenta fuentes autorizadas y retorno antes de restringir accesos directos. |
Fuentes oficiales
Estas fuentes explican los protocolos y ajustes mencionados. Comprueba siempre la documentación de tu versión.