Op deze pagina
Kernpunten
- GRE is niet de mitigatielaag zelfHet is vooral een model om schoon verkeer te leveren na upstream-mitigatie.
- Het voorkomt vaak een gedwongen migratiePast goed als je een bestaande server bij een andere provider wilt houden.
- De grenzen zijn vooral operationeelMTU, tunnel-overhead, retourpad en endpoint-capaciteit tellen allemaal mee.
- De use case bepaalt allesGaming, SaaS, APIs en netwerk-frontends hebben niet hetzelfde handoff-model nodig.
Probleemdefinitie
Wanneer een dienst aan het internet is blootgesteld, is de uitdaging niet alleen het filteren van de DDoS-aanval. Je hebt ook een betrouwbare manier nodig om legitiem verkeer terug te leveren aan de echte bestemming. Veel teams draaien al een productieserver, proxy, cluster of frontend ergens anders en willen bescherming toevoegen zonder alles opnieuw op te bouwen.
Daar komt een GRE-tunnel in beeld. Verkeer bereikt eerst de mitigatielaag, wordt daar opgeschoond en vervolgens worden de legitieme stromen ingekapseld en teruggestuurd naar het endpoint van de klant. Het doel is eenvoudig: de ruis upstream stoppen en bruikbaar verkeer aan de productie leveren.
Waarom het ertoe doet
In veel echte incidenten valt niet de applicatie het eerst uit. De link raakt verzadigd, de latency stijgt, wachtrijen groeien en de frontend wordt instabiel voordat de businesslogica kan reageren. Daarom is het leveren van schoon verkeer zo belangrijk. Nuttige mitigatie draait niet alleen om het filteren van de aanval, maar om het stabiel en beheersbaar terugleveren van legitiem verkeer.
Het doet er ook toe omdat veel klanten een al werkende omgeving niet onder druk willen verplaatsen. GRE wordt vaak de praktische middenweg tussen niets doen en alles migreren.
- Behoud de bestaande stack
- Houd de server of proxy waar die al draait.
- Verminder wrijving
- Voeg netwerkbescherming toe voordat je een grotere herinrichting bespreekt.
- Verminder risico
- Een clean handoff is vaak veiliger dan een noodmigratie.
- Sneller uitrollen
- Een goed gepland GRE-leveringsmodel kan snel live gaan.
Mogelijke modellen
GRE is niet het enige leveringsmodel na mitigatie. De juiste keuze hangt af van wie de IP-ruimte aankondigt, waar het schone verkeer moet eindigen en hoeveel routingcontrole de klant wil behouden.
| Model | Voordelen | Grenzen | Typische fit |
|---|---|---|---|
| Eenvoudige GRE-tunnel | Snel uit te rollen en weinig wrijving | Minder routingflexibiliteit dan een volledige BGP-opzet | Dedicated servers, gaming, APIs, SaaS |
| GRE + BGP | Meer controle over aankondigingen en routing | Geavanceerder integratiewerk | Operators en klanten met eigen prefixen |
| Beschermde IPs + GRE-handoff | Goede manier om snel te starten | Behoudt in het begin mogelijk niet de originele adressering | Proeven en gefaseerde uitrol |
| Cross-connect / directe handoff | Zeer schoon voor gecolokeerde omgevingen | Minder relevant voor externe third-party hosting | Datacenteraanwezigheid en operator-achtige designs |
- RFC 2784 — GRE
GRE-basisspecificatie.
- RFC 2890 — GRE-uitbreidingen
Key- en sequence-uitbreidingen voor GRE.
Wanneer GRE relevant is — en wanneer niet
GRE is zeer relevant als je een bestaande server wilt beschermen, je productie wilt houden waar die al draait en een schone L3-handoff accepteert. Het is minder relevant als je vooral een lokaal datacenter cross-connect-model nodig hebt of als het uiteindelijke endpoint zelf te zwak is om het schone verkeer aan te kunnen.
- Relevant
- Bestaande server bij third-party hosting, snelle integratie, schone L3-levering.
- Zeer relevant
- Productiedienst al online en moeilijk snel te migreren.
- Minder relevant
- Je hebt vooral een directe lokale datacenter-handoff nodig.
- Op zichzelf niet genoeg
- De uiteindelijke server is al onderbemeten of het retourpad is niet begrepen.
Onze aanpak
- Snelle review van IPs, routes, MTU en endpoint-capaciteit.
- Keuze van het leveringsmodel: GRE, GRE + BGP, beschermde IPs of een andere handoff.
- Validatie voor de productie-omschakeling.
- Gefaseerde uitrol waar nodig.
Concrete use case
Een gaming-operator draait alles al op een dedicated server bij een andere provider. Het hoofddoel is te voorkomen dat herhaalde DDoS-aanvallen de link verzadigen, terwijl de huidige server en applicatiestack behouden blijven. In dat scenario is het terugleveren van schoon verkeer via GRE na mitigatie vaak het beste compromis.
Begrijp de dienst
Poorten, latencygevoeligheid en gewenst leveringsmodel worden bepaald.
Bereid het GRE-endpoint voor
MTU, firewall, retourpad en NIC-gedrag worden gevalideerd.
Filter en lever dan af
Alleen legitiem verkeer wordt via GRE teruggeleverd.
Evolueer later indien nodig
De opzet kan eenvoudig blijven of naar een rijker routingmodel groeien.
Veelgemaakte fouten
De grootste fout is denken dat GRE de volledige Anti-DDoS-strategie is. Het is alleen een leveringsmethode na mitigatie. Een andere veelgemaakte fout is MTU, fragmentatie, retourpadgedrag en endpoint-dimensionering negeren.
- GRE uit gewoonte kiezen zonder alternatieven te valideren.
- MTU- en fragmentatieproblemen negeren.
- Het retourpad vergeten.
- Aannemen dat de tunnel een onderbemeten endpoint oplost.
FAQ
Is GRE verplicht voor Anti-DDoS?
Nee. Het is een veelgebruikt en nuttig handoff-model, maar niet het enige.
Kan ik een dedicated server beschermen zonder hem te migreren?
Ja. Dat is een van de belangrijkste sterktes van een GRE-handoff-model.
Wanneer heb ik GRE + BGP nodig?
Vooral wanneer je meer routingcontrole nodig hebt of je eigen prefixen wilt aankondigen.
