Hoppa till innehåll
DDoS-skydd · Peeryx · 15 Tbps+
Alla guider

GRE, reverse proxy eller BGP: välj rätt väg för skyddad trafik

GRE, reverse proxy och BGP löser olika delar av nätvägen. De är inte utbytbara skyddsknappar. Utgå från spelets protokoll, vem som förvaltar adresserna och hur trafik och svar ska passera innan du väljer teknik eller beställer ett skydd.

← Alla guiderCubixServ

Innan du börjar

Lista adresser, portar och protokoll. Fastställ ansvar för båda ändarna och behörighet till prefixen. Spara fungerande regler och vägar, ordna separat administrationsåtkomst och planera en återställning tillsammans med operatören.

Anpassa proxyn till protokollet

En HTTP reverse proxy behandlar konfigurerad HTTP-trafik. Den skyddar inte automatiskt ett spels UDP-anslutningar. NGINX stream kan vidarebefordra TCP eller UDP med rätt modul och inställningar, men innebär inte i sig HTTP-filtrering. Kontrollera portar, tidsgränser och publika adresser. Prova spelklienten och filhämtningen var för sig.

GRE kapslar in nätpaket

GRE över IPv4 använder IP-protokoll 47, inte TCP-port 47. Tunneln tillför inte ensam kryptering eller autentisering av motparten. Kontrollera tillåtna ändpunkter och filter på båda sidor. Att öppna en TCP-port hjälper inte om nätet blockerar själva GRE-protokollet. Testa också vidarebefordran efter att tunneln etablerats.

Kontrollera källadresser och returväg

När ursprungliga klientadresser bevaras måste svar kunna gå tillbaka genom rätt väg. NAT kan förenkla vissa upplägg men ändrar vad servern ser. Kartlägg båda riktningarna och kontrollera asymmetrisk routing. Annars kan anslutningar fastna trots att inkommande paket når fram och tunnelns status visar att den är uppe.

BGP kräver rätt att annonsera

BGP väljer vägar mellan nät, inte ett automatiskt filter för spelpaket. Prefix får bara annonseras enligt operatörens avtal och verifierade behörigheter. En vanlig VPS-adress ger inte den rätten. Dokumentera prefix, ursprung, annonseringspolicy och återställning; samordna ändringar med ansvariga operatörer innan någon produktionsväg flyttas.

Mät MTU med riktig trafik

Inkapsling tar plats i paketet. Fel MTU kan påverka större överföringar medan små ping fungerar. Kontrollera path MTU, nödvändiga kontrollmeddelanden och eventuell fragmentering längs vägen. Använd filhämtning och speltrafik som motsvarar produktion. Ändra inte flera MTU- och brandväggsvärden samtidigt; då blir resultatet svårt att tolka.

Testa stegvis och behåll återgången

Kontrollera anslutning, filer, UDP, administration och svar från oberoende nät. Jämför förlust och RTT före och efter under liknande belastning. Flytta först en avgränsad tjänst och skriv ned villkor för återgång. Ett lyckat tunneltest eller en öppen webbsida bekräftar inte att hela spelserverns trafik fungerar.

Vad gör du i din situation?

SituationNästa steg
Endast HTTP behöver mellanhandAnvänd en HTTP-proxy med avgränsad origin och testa spelets övriga protokoll separat.
UDP behöver skyddad vägUtred en lämplig TCP/UDP-proxy eller tunnel med verifierad returväg och MTU.
Eget behörigt prefix ska flyttasSamordna BGP-policy och återställning med operatören innan annonseringen ändras.

Officiella källor

Källorna beskriver protokoll och inställningar. Kontrollera dokumentationen för versionen du använder.

  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/