Antes de começar
Faz um inventário de IP públicas, portas, protocolos e origens. Identifica onde o tráfego é filtrado e encaminhado. Conserva medidas habituais e condições do serviço para comparar com um incidente. Antes de mudar regras, prepara cópia, manutenção e reposição.
L3: tráfego de rede
A camada de rede considera pacotes IP e padrões volumétricos. Um fluxo pode saturar a ligação antes de chegar à aplicação, pelo que a filtragem a montante é relevante. A capacidade total não equivale à do servidor: os 15 Tbps comunicados pela CubixServ descrevem capacidade agregada da rede de proteção, não a porta individual nem uma garantia contra todos os ataques.
L4: TCP e UDP
A camada de transporte distingue ligações TCP e tráfego UDP. Portas, estados e frequências podem fazer parte das regras. Um perfil para sites não é automaticamente adequado ao jogo. Confirma a porta atribuída e separa administração. Um teste TCP bem-sucedido não demonstra que o encaminhamento UDP permita a ligação efetiva dos jogadores ao longo de todo o percurso.
L7: compreender a aplicação
Um pedido aparentemente válido pode provocar trabalho dispendioso. Um proxy HTTP pode verificar e limitar HTTP, mas não compreende por isso todos os protocolos de jogo. Pede endpoints e funções concretos. Em FiveM, transferências HTTP e ligação de jogo têm de ser avaliadas separadamente: proteger uma parte não certifica todas as operações como protegidas ao nível da aplicação.
Proteger também a origem
Um endpoint protegido pode ser contornado se a origem desprotegida continua acessível. Revê DNS, transferências, administração e outras portas. Restringe fontes só depois de conhecer os caminhos autorizados. Confiança demasiado ampla pode permitir contornar controlos; regras demasiado estreitas podem bloquear utilizadores legítimos. O acesso administrativo precisa da sua própria configuração de segurança, distinta do serviço público de jogo.
Comparar rede e aplicação
Durante um incidente compara tráfego, pacotes rejeitados, ligações e carga. Uma tarefa principal ou base de dados bloqueada pode parar o jogo com uma rede aparentemente normal. Mais filtragem não corrige scripts dispendiosos. Um timeout isolado também não prova ataque: compara perdas, rotas, erros e diferenças face ao estado habitual com medidas de várias fontes.
Pedir condições verificáveis
Confirma âmbito, largura de banda atribuída, serviços permitidos, encaminhamento e apoio. Verifica se são necessários IP específico, túnel ou alterações na origem. Testa o percurso completo com utilizadores autorizados antes e depois. Um site acessível não valida todos os jogos; ensaios de carga ou ataque precisam de enquadramento expressamente autorizado e coordenado com os operadores envolvidos.
O que fazer no teu caso
| Situação | Próximo passo |
|---|---|
| Servidor de jogo UDP | Confirma porta real, protocolo e perfil de filtragem. Uma resposta HTTP não é validação completa. |
| Pedidos HTTP dispendiosos | Analisa aplicação, limites e proxy em conjunto. Reserva de rede não elimina trabalho por pedido. |
| Origem externa a proteger | Documenta fontes autorizadas e retorno antes de restringir acessos diretos. |
Fontes oficiais
Estas fontes explicam os protocolos e configurações referidos. Confirma sempre a documentação da tua versão.