Technische vergelijkingGepubliceerd op 18 april 2026Leestijd: 8 min
GRE, BGP of beschermde IP’s: welk model kies je om een dienst tegen DDoS te beschermen?
Eenvoudige GRE-tunnel, GRE + BGP of protected IP delivery: zo kies je het juiste model op basis van architectuur, routingcontrole en gewenste uitrolsnelheid.
Flexibele deployment
GRE / BGP delivery
Bescherming zonder volledige migratie
Public IPsOVH · HetznerMitigatieBGP optioneelDedicatedInfra behoudenGRE tunnelSchoon verkeer
Er is geen universeel model
De juiste keuze hangt af van IP-eigendom, routingbehoefte en productiebeperkingen.
GRE is vaak de snelste start
Voor veel klanten is een simpele tunnel al genoeg voor een nette livegang.
BGP geeft meer controle
Het wordt interessant wanneer je eigen prefixes of routingbeleid wilt behouden.
Beschermde IP’s maken onboarding eenvoudiger
Zo kun je snel testen zonder alles direct te verplaatsen.
Wie serieuze anti-DDoS-bescherming zoekt, zou eerst niet moeten vragen “welke provider?”, maar “welk delivery-model past echt bij mijn architectuur?”. Veel verkeerde keuzes ontstaan door een slechte afweging tussen simpele GRE, GRE met BGP en beschermde IP’s.
Deze drie modellen hebben in de praktijk niet dezelfde complexiteit en ook niet dezelfde operationele voordelen. Een goede keuze aan het begin voorkomt onnodige migraties, fragiele integraties en verkeerde verwachtingen.
De echte keuze: eenvoud, controle of snelheid van uitrol
Een veelgemaakte fout is vragen naar de “meest geavanceerde” oplossing zonder naar de echte behoefte te kijken. Veel klanten hebben op dag één geen BGP nodig. Andere omgevingen hebben juist baat bij het behouden van eigen prefixes en routinglogica.
De juiste keuze hangt vooral af van drie dingen: wie de publieke IP’s bezit, hoeveel routingcontrole nodig is en hoe snel de bescherming live moet.
Waarom het delivery-model zoveel verschil maakt
Het gekozen model beïnvloedt de uitroltijd, het onderhoud, het aantal wijzigingen in de bestaande omgeving en de ruimte om later door te groeien.
Een technisch sterke maar moeilijk integreerbare oplossing kan een project vertragen. Een heel simpel model kan juist perfect zijn voor één dienst, maar te beperkt voor een multi-site of multi-prefix omgeving.
Impact op productie
Hoe complexer het model, hoe belangrijker routing, retourverkeer, MTU en monitoring worden.
Impact op planning
GRE of beschermde IP’s gaan vaak sneller live dan een volledige BGP-integratie.
Impact op schaalbaarheid
BGP krijgt veel meer waarde zodra meerdere diensten of prefixes meespelen.
Impact op sales
Een eenvoudiger rollout verkort meestal de tijd tussen eerste contact en livegang.
Wanneer een simpele GRE-tunnel de beste keuze is
GRE-only is vaak de juiste aanpak wanneer een bestaande productiedienst snel beschermd moet worden en eigen prefixes niet aangekondigd hoeven te worden.
Het past goed bij dedicated servers, webdiensten, API’s, gameplatformen en omgevingen die anti-DDoS willen toevoegen zonder de publieke routinglaag volledig opnieuw op te zetten.
Eenvoudigere uitrol
Minder BGP-afhankelijkheden aan klantzijde
Handig voor snelle latency- en integratietests
Sterke optie als een bestaande OVH-, Hetzner- of andere dedicated server behouden moet blijven
Wanneer BGP aan de GRE-tunnel moet worden toegevoegd
BGP wordt logisch wanneer je eigen IP-ruimte, een eigen ASN of een architectuur met duidelijke routingcontrole hebt. Het maakt prefixbeheer netter en geeft meer flexibiliteit als de omgeving groeit.
Het is geen harde voorwaarde om beschermd te zijn. Het is een architectuurkeuze die extra controle geeft wanneer die controle echt waarde heeft.
Eigen prefixes behouden
Publieke addressing en announcements blijven onderdeel van je eigen architectuur.
Later netter schalen
Dit model past beter wanneer meerdere diensten of blokken beheerd moeten worden.
Meer werk aan het begin
De integratie is wel zwaarder dan bij een heel eenvoudige GRE-only setup.
Wanneer beschermde anti-DDoS-IP’s de beste keuze zijn
Beschermde IP’s zijn vaak de snelste manier om te starten. Verkeer komt eerst binnen op een publiek punt aan de mitigatiekant en schoon verkeer wordt daarna via een tunnel naar je server geleverd.
Dit is vooral nuttig wanneer je geen eigen blokken wilt announcen, wanneer je de dienst snel wilt valideren of wanneer je eerst een eenvoudig productiemodel wilt.
1. De dienst draait op een beschermde IP
Het publieke exposurepunt zit aan de mitigatiekant.
2. Kwaadaardig verkeer wordt upstream gefilterd
Het doel is de aanval te stoppen vóór levering aan je eigen omgeving.
3. Legitiem verkeer wordt doorgestuurd
Delivery kan via GRE of een ander passend model verlopen.
4. Later blijft ruimte om te evolueren
Als de behoefte groeit kan de architectuur later meer routingcontrole krijgen.
Hoe je snel tussen de drie modellen kiest
Wil je snel live, één specifieke dienst beschermen en complexiteit vermijden, dan is GRE-only of protected IP delivery meestal de beste start. Wil je vanaf het begin je eigen publieke ruimte behouden, dan is GRE + BGP logisch.
Het beste ontwerp beschermt snel zonder onnodige complexiteit op te bouwen. Het doel is niet om op papier indrukwekkend te lijken, maar om schoon, stabiel en beheersbaar te blijven.
Je wilt snelheid
GRE-only of beschermde IP’s.
Je wilt eigen IP’s behouden
GRE + BGP.
Je wilt eerst testen
Beschermde IP’s plus tunneldelivery.
Je beheert meerdere diensten en geavanceerde routing
Dan wordt BGP meestal consistenter.
Veelgemaakte fouten om te vermijden
De meest voorkomende fout is een model kiezen dat te zwaar is voor de echte behoefte, of juist te simpel voor een al complexe omgeving. Ook retourverkeer, MTU en de feitelijke publicatie van de dienst worden vaak onderschat.
Is BGP verplicht?
Nee. Veel diensten kunnen netjes beschermd worden met GRE en, als dat helpt, beschermde IP’s.
Is een tunnel alleen genoeg voor een dedicated server?
In veel gevallen wel, zeker wanneer het vooral gaat om snelle bescherming van een bestaande productiedienst.
Wanneer zijn beschermde IP’s het nuttigst?
Wanneer je snel live wilt, complexiteit wilt verminderen en niet meteen eigen blokken wilt announcen.
Kun je eenvoudig starten en later doorgroeien?
Ja. Dat is vaak de beste route: eerst valideren, daarna alleen verder uitbouwen als de architectuur dat echt vraagt.
Conclusie
GRE, GRE + BGP en protected IP delivery zijn geen tegenpolen. Het zijn drie bruikbare delivery-modellen die elk passen bij een andere productierealiteit.
Als je serieuze anti-DDoS-bescherming wilt toevoegen zonder de architectuur onnodig zwaarder te maken, is het beste startpunt het model dat snel beschermt, netjes blijft en later nog ruimte laat om te groeien.
Resources
Gerelateerde lectuur
Hieronder staan meer nuttige pagina’s en artikelen om dieper op het onderwerp in te gaan.
