Pular para o conteúdo
Proteção DDoS · Peeryx · 15 Tbps+
Todos os guias

GRE, reverse proxy ou BGP: escolher como receber tráfego protegido

GRE, reverse proxy e BGP resolvem tarefas diferentes. A escolha depende dos serviços, da operação da rede e do percurso nos dois sentidos. Nenhum método equivale, por si só, a proteção DDoS completa ou garante uma latência específica para todas as aplicações.

← Todos os guiasCubixServ

Antes de começar

Desenha endpoint público, origem, protocolos e retorno. Confirma permissões sobre endereços e redes e condições do operador. Guarda configuração, prepara manutenção e define a reposição antes de mudar rotas ou filtros que possam afetar outros serviços.

Definir a necessidade

Queres publicar uma aplicação HTTP, encaminhar um jogo TCP/UDP ou anunciar um prefixo autorizado? São tarefas diferentes. Indica também se a aplicação precisa de conhecer a IP original do cliente. O nome comercial não explica o retorno nem os serviços permitidos: confirma primeiro a topologia e quem é responsável por cada extremo do percurso.

Para FiveM, separe terminais de conexão, arquivos e jogabilidade. Verifique os endereços anunciados e os serviços que permanecem diretos. Estabeleça se os endereços dos clientes são preservados, quais informações chegam à origem e quais regras de confiança correspondem à sua versão.

Compreender um túnel GRE

GRE encapsula pacotes entre endpoints. Em IPv4 utiliza o protocolo IP 47, não a porta TCP 47. Pode transportar tráfego previamente filtrado quando ambos os extremos estão preparados. Não oferece, por si só, cifragem ou autenticação: restringe fontes e protege endpoints. A encapsulação acrescenta bytes e pode reduzir a MTU útil, pelo que deves testar transferências reais.

Verifique se os equipamentos e as redes permitem GRE. No IPv4 ele usa um número de protocolo IP, em vez de simplesmente uma porta TCP ou UDP para abrir. O encapsulamento adiciona cabeçalhos: adapta e testa o MTU efetivo, as rotas e o caminho de retorno. Uma conexão que trabalha com pacotes pequenos ainda pode falhar com pacotes maiores.

Distinguir HTTP e proxy de transporte

Um reverse proxy HTTP interpreta pedidos HTTP. Outros serviços precisam de encaminhamento TCP ou UDP adequado, como o módulo Stream do NGINX quando aplicável. Verifica duração de sessões, timeouts e comportamento UDP. Um site que responde não comprova o jogo. A conservação da IP do cliente depende dos mecanismos realmente suportados pela origem, não apenas da existência do proxy.

Você precisa de um contrato de roteamento, recursos autorizados e pré-requisitos do provedor. O anúncio de prefixos de terceiros requer autorização real. Os tamanhos de prefixo aceitos, filtros e processos de validação variam entre os operadores. Um endereço VPS não concede automaticamente o direito ou a capacidade de anunciar um prefixo na Internet.

Confirmar requisitos de BGP

BGP troca informação de encaminhamento. Anunciar uma rede requer recursos autorizados, acordos e políticas do operador; uma IP de VPS atribuída não é um prefixo livremente anunciável. BGP também não filtra ataques sozinho. Trânsito protegido combina rotas e filtragem. Esclarece dimensões de prefixos, condições, retorno e quem atende falhas de anúncio ou conectividade.

Identifique também caminhos de desvio: endereços antigos, DNS secundário, arquivos, voz ou ferramentas de administração. Antes de restringir uma origem, verifique as fontes legítimas e os serviços necessários. A proteção remota não elimina a necessidade de controlar a exposição direta do destino.

Medir MTU e ambos os sentidos

Testa dados de tamanhos representativos, não só pacotes pequenos ou uma porta isolada. Uma MTU incorreta pode quebrar transferências enquanto uma verificação simples funciona. Caminhos assimétricos podem influenciar componentes com estado: documenta ida e retorno. Não alteres MTU ou rotas globais sem avaliar os outros serviços e conservar uma reposição verificada para o estado anterior.

Altere um componente por vez com uma configuração de reversão disponível. Coordene e limite qualquer carga de teste. Alterar DNS, proxy, túnel e firewall simultaneamente torna difícil identificar por que um teste falha.

Escolher uma solução operável

Um serviço web isolado tem requisitos diferentes de vários protocolos ou de uma rede própria. Considera monitorização, recuperação e responsabilidades num incidente. A técnica mais abrangente não é automaticamente a mais adequada. Testa aplicações antes de migrar e regista ligações, perdas, atrasos e limites. Nenhum nome de método implica capacidade dedicada ou proteção L7 universal.

Compare responsabilidades, disponibilidade real, limites de tráfego e preços para o escopo escolhido. A combinação de mecanismos pode ajudar, mas cada camada adiciona configurações e requisitos de monitoramento. Mantenha uma descrição simples que sua equipe e fornecedor possam verificar juntos.

O que fazer no teu caso

SituaçãoPróximo passo
Uma aplicação HTTPConsidera um proxy HTTP com regras de origem e administração separada.
Vários serviços TCP/UDPCompara túnel e encaminhamento de transporte, incluindo MTU, IP do cliente e retorno.
Uma rede IP própria autorizadaCombina condições de BGP e trânsito com o operador. Um endereço VPS isolado não basta para anunciar um prefixo.

Fontes oficiais

Estas fontes explicam os protocolos e configurações referidos. Confirma sempre a documentação da tua versão.

  1. RFC Editor / IETF/rfc/rfc2784
  2. RFC Editor / IETF/rfc/rfc4271
  3. NGINX/en/docs/stream/ngx_stream_proxy_module.html
  4. Cfx.re/docs/server-manual/proxy-setup/