Salta al contingut
Protecció DDoS · Peeryx · 15 Tbps+
Totes les guies

GRE, reverse proxy o BGP: tria el camí adequat del trànsit

GRE, reverse proxy i BGP resolen parts diferents del camí del trànsit. No són interruptors DDoS intercanviables. La tria depèn de protocols, administració d’adreces i de com peticions i respostes passen per una ruta protegida sense trencar connexions legítimes ni perdre accés de gestió.

← Totes les guiesCubixServ

Abans de començar

Enumera adreces, ports i protocols. Verifica responsabilitats als dos extrems i autorització dels prefixos. Desa regles funcionals, mantén una via de gestió separada i planifica restauració amb l’operador abans de canviar rutes de serveis actius.

El proxy ha de coincidir amb el protocol

Un HTTP reverse proxy tracta HTTP configurat, no automàticament l’UDP del joc. NGINX stream pot reenviar TCP o UDP amb mòdul i configuració adequats, però no és un filtre HTTP d’aplicació. Revisa adreces, ports i timeouts. Prova client real i fitxers per separat; una pàgina no confirma tot el servei.

GRE encapsula paquets

GRE sobre IPv4 utilitza protocol IP 47, no port TCP 47. Per si mateix no proporciona xifratge ni autenticació de l’altre extrem. Verifica punts permesos i filtres a tots dos costats. Un túnel actiu no prova trànsit del joc; comprova servei real i respostes al client, no només un estat verd al panell.

Confirma fonts i retorn

Mantenir les adreces originals dels clients requereix una ruta de resposta adequada. NAT pot canviar la font que veu el servidor i el retorn. Descriu ambdues direccions i encaminament asimètric. Els paquets poden arribar a l’origen mentre la connexió falla perquè la resposta surt per una interfície incorrecta o els filtres de l’altra ruta no encaixen.

BGP requereix drets verificats

BGP intercanvia rutes entre xarxes; no és un filtre de paquets del joc per si mateix. Anuncia només prefixos autoritzats pel contracte i els permisos. Una IP de VPS no dona automàticament dret a anunciar tota una xarxa. Coordina origen, política, anunci i retorn amb els operadors responsables abans de modificar rutes públiques.

Prova MTU amb trànsit representatiu

L’encapsulació ocupa espai addicional. Una MTU incorrecta pot trencar transferències grans mentre un ping petit funciona. Revisa path MTU, missatges de control necessaris i possible fragmentació. Utilitza fitxers i joc autoritzats semblants a l’ús normal. Canvia una configuració cada vegada per identificar la correcció que elimina realment l’error i poder reproduir-la.

Valida progressivament

Comprova TCP, UDP, fitxers, administració i respostes des de xarxes independents. Compara RTT i pèrdues amb càrrega similar. Mou primer un servei delimitat i anota condicions de retorn. Un túnel verd o una web accessible no proven el joc complet i les seves dependències; calen connexions reals dels clients després de la migració.

Què cal fer en el teu cas?

SituacióPas següent
Només HTTP necessita intermediariRestringeix origen i prova HTTP proxy sense pressuposar cobertura UDP.
UDP necessita camí protegitValora proxy de transport o túnel amb MTU i retorn verificats.
Trasllades un prefix propi autoritzatPlanifica política BGP i restauració amb l’operador responsable.

Fonts oficials

Les fonts descriuen protocols i configuracions. Consulta la documentació de la versió que utilitzes.

  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/