Praktische gids om een productie-dedicated server bij OVH, Hetzner of een andere provider te beschermen zonder de hele infrastructuur te migreren, met GRE met of zonder BGP.
Bescherming zonder volledige migratie
Je kunt een anti-DDoS-laag toevoegen zonder de volledige productieomgeving opnieuw op te bouwen.
Een GRE-tunnel is vaak sneller te implementeren dan een volledige migratie.
Alleen tunnel, GRE + BGP of beschermde IP’s: het beste ontwerp hangt af van de echte architectuur.
MTU, retourpad, routing en de werkelijke servercapaciteit moeten goed worden gevalideerd.
Veel bedrijven, game-operators, SaaS-platforms en internetgerichte diensten draaien hun infrastructuur al op dedicated servers bij OVH, Hetzner of vergelijkbare providers. Wanneer DDoS-aanvallen beginnen, is de eerste reflex vaak: alles moet worden gemigreerd. In de praktijk is dat niet de enige optie en ook lang niet altijd de beste.
In veel gevallen maakt een anti-DDoS-architectuur op basis van GRE, met of zonder BGP, het mogelijk om de dienst te beschermen terwijl de server blijft staan waar hij al in productie draait. De vraag is dus niet alleen hoe je de aanval stopt, maar hoe je een realistisch, stabiel en productiegeschikt leveringsmodel kiest.
Het meest voorkomende scenario is duidelijk: de klant heeft al een dedicated server bij Hetzner, OVH of een vergelijkbare provider. Diensten draaien live, IP’s zijn al in gebruik, back-ups en monitoring bestaan en andere systemen kunnen al van die omgeving afhankelijk zijn.
Wanneer DDoS-aanvallen terugkerend worden, ligt het probleem niet alleen op applicatieniveau. De verbinding kan verzadigd raken voordat de applicatie kan reageren, de latency loopt op, de gebruikerservaring verslechtert en een haastige migratie creëert vaak meer risico dan stabiliteit.
Precies voor dat soort situaties is bescherming via GRE, met of zonder BGP, relevant: er wordt een upstream mitigatielaag toegevoegd zonder de bestaande productie-stack open te breken.
Een volledige migratie lijkt op papier logisch, maar productie heeft andere eisen. Klanten moeten vaak netwerkafhankelijkheden, operationele werkwijzen, scripts, licenties, inter-server-verkeer en soms ook commerciële of contractuele randvoorwaarden behouden.
Het verstandige doel is daarom niet om standaard alles te verplaatsen. Het doel is effectieve bescherming toevoegen zonder onnodig operationeel risico te creëren.
Een volledige architectuur opnieuw opbouwen tijdens aanvallen of instabiliteit is zelden de beste zet.
De klant behoudt servers, workflows, storage, monitoring en lokale afhankelijkheden.
Een goed geïntegreerde GRE-tunnel is vaak sneller live dan een volledige productiemigratie.
Je kunt beginnen met één blootgestelde dienst en het model later uitbreiden.
Een GRE-tunnel kapselt schoon verkeer in tussen de mitigatie-infrastructuur en je dedicated server of router. Openbaar verkeer komt eerst op de anti-DDoS-laag binnen, wordt gefilterd en alleen legitiem verkeer wordt via de tunnel teruggeleverd.
In dit model blijft de uiteindelijke server bij OVH, Hetzner of elders staan. Hij ontvangt niet langer direct ruw internetverkeer, maar alleen verkeer na reiniging. Zo blijft de bestaande omgeving behouden terwijl er een serieuze netwerkbeschermingslaag wordt toegevoegd.
Dat is vooral nuttig voor diensten die al in productie zijn, gaming-workloads, bedrijfsapplicaties of infrastructuren die niet van de ene op de andere dag kunnen worden verplaatst.
Beschermde IP’s of geannonceerde prefixes komen eerst op de anti-DDoS-infrastructuur binnen.
Doel is kwaadaardig verkeer te stoppen voordat het de productieomgeving bereikt.
Schoon verkeer wordt via GRE naar de dedicated server of router gestuurd.
De applicatie blijft bij de huidige provider, maar achter een dedicated mitigatielaag.
BGP is vooral nuttig wanneer de klant eigen IP-prefixes wil announcen, controle over routing wil behouden of de bescherming wil opnemen in een geavanceerdere netwerkarchitectuur. Voor sommige profielen is dat belangrijk, maar het is niet in elk deployment verplicht.
In veel gevallen kunnen we ook onze eigen beschermde anti-DDoS-IP’s gebruiken en schoon verkeer via de GRE-tunnel terugleveren naar de dedicated server bij OVH of Hetzner. In dat scenario hoeft de klant niet per se eigen prefixen te announcen om te starten.
Met andere woorden: BGP is een hulpmiddel voor architectuur en flexibiliteit. Het is geen absolute voorwaarde om een elders gehoste dienst te beschermen.
Ideaal als je een ASN, eigen prefixes of fijnmazige routingcontrole hebt of wilt.
De eenvoudigere aanpak wanneer snelle bescherming belangrijker is dan extra routingcomplexiteit.
Verkeer landt op beschermde IP’s en wordt via de tunnel teruggeleverd aan de dedicated server.
Je kunt eenvoudig starten en later overstappen op een BGP-architectuur als de behoefte verandert.
De juiste keuze hangt af van het gewenste niveau van netwerkcontrole, de gewenste implementatiesnelheid en of je eigen IP-prefixes gebruikt. Er bestaat geen universeel model dat voor elke klant werkt.
Vaak de beste keuze om snel een productie-dedicated server te beschermen zonder ASN en zonder BGP-announcements.
Beter geschikt wanneer je eigen IP’s hebt, je announcements wilt behouden en meer netwerkflexibiliteit nodig hebt.
Zeer handig om snel te starten, latency en integratie te valideren en directe hernummering te vermijden.
Relevant voor grotere omgevingen of klanten met eigen datacenter-aanwezigheid en directere handoff-eisen.
Een goede beschermingsoplossing moet niet als magie worden verkocht. Belangrijk is te begrijpen wat deze architectuur echt oplost en wat aan klantzijde nog steeds moet worden gevalideerd.
De belangrijkste waarde is dat bestaande servers behouden blijven in plaats van een volledige verhuizing af te dwingen.
Je kunt eerst één dienst beschermen en later het model uitbreiden.
MTU, retourrouting, firewallregels, lokale policies en de echte machinecapaciteit moeten serieus worden gecontroleerd.
Als applicatie, server of intern ontwerp al zonder aanval overbelast zijn, lost netwerkbescherming alleen niet alles op.
Bij Peeryx is het doel niet om standaard een volledige migratie te pushen. We kijken eerst naar de bestaande infrastructuur, de meest coherente aflevermethode en het werkelijk benodigde niveau van netwerkcontrole.
Afhankelijk van de situatie kan dat betekenen: beschermde IP’s die via GRE aan je dedicated server worden geleverd, een BGP-gebaseerd ontwerp wanneer je je eigen announcements wilt behouden, of een gefaseerde uitrol die zich eerst richt op de meest blootgestelde diensten.
Stel je een klant voor die al een game-server of applicatie-backend bij Hetzner host. De klant wil die machine behouden omdat de hele omgeving al klaarstaat, maar terugkerende aanvallen maken de dienst instabiel en een volledige migratie is op korte termijn niet wenselijk.
De netste aanpak is vaak om publiek verkeer eerst op een dedicated anti-DDoS-laag te laten landen, de aanval te filteren en alleen legitiem verkeer via GRE terug te sturen naar de Hetzner-server. Als de klant eigen IP-ruimte heeft of meer routingcontrole nodig heeft, kan BGP worden toegevoegd. Anders kan men vanaf dag één met beschermde IP’s aan mitigatiezijde starten.
We bekijken het type dienst, latency-gevoeligheid, operationeel model en het vermogen van de server om schoon verkeer te ontvangen.
Alleen tunnel, tunnel + BGP of beschermde IP’s afhankelijk van het gewenste controleniveau.
GRE, retourpad, MTU en algemene stabiliteit worden gevalideerd vóór echte cutover.
De klant behoudt de bestaande infrastructuur en krijgt een mitigatielaag die past bij het echte gebruiksscenario.
De meeste problemen komen niet door GRE of BGP zelf, maar door zwakke afbakening of een architectuur die op papier eenvoudiger lijkt dan in productie.
Ja. Dat is een van de meest voorkomende scenario’s: de server blijft bij Hetzner en ontvangt legitiem verkeer via GRE na upstream mitigatie.
Nee. BGP is nuttig voor sommige klanten, maar GRE met beschermde IP’s is voor veel deployments voldoende.
Ja. Verkeer wordt upstream gereinigd en vervolgens via een geschikte architectuur naar de OVH-server teruggeleverd.
Ja. Dat is vaak de netste aanpak: eenvoudig starten, productie valideren en later BGP toevoegen als dat nuttig wordt.
Ja, juist omdat er bescherming kan worden toegevoegd zonder vanaf het begin een volledige migratie af te dwingen.
Een Hetzner- of OVH-dedicated server tegen DDoS beschermen betekent niet automatisch alles verplaatsen. In veel gevallen voegt een GRE-gebaseerd ontwerp – met of zonder BGP – een serieuze mitigatielaag toe terwijl de bestaande productieomgeving behouden blijft.
Het juiste model hangt af van de technische realiteit: behoefte aan eigen IP’s, wens om routingcontrole te houden, focus op snelle uitrol of de noodzaak om te starten met al beheerde beschermde IP’s.
Het echte doel is dus niet alleen een aanval stoppen, maar een geloofwaardige, nette en productiegeschikte architectuur kiezen.
Vertel ons over je huidige infrastructuur, hostingprovider, netwerkbeperkingen en gewenst controleniveau. We zeggen je of een eenvoudige GRE-tunnel, GRE + BGP of levering via beschermde IP’s het meeste zin heeft.
