Auf dieser Seite
Das Wichtigste
- GRE ist nicht die Mitigation-Schicht selbstEs ist vor allem ein Modell zur Zustellung von sauberem Traffic nach der Upstream-Mitigation.
- Oft vermeidet es eine erzwungene MigrationPasst gut, wenn ein bestehender Server bei einem anderen Anbieter bleiben soll.
- Seine Grenzen sind vor allem betrieblichMTU, Tunnel-Overhead, Rückweg und Endpunkt-Kapazität sind entscheidend.
- Der Anwendungsfall entscheidet allesGaming, SaaS, APIs und Netzwerk-Frontends brauchen nicht dasselbe Handoff-Modell.
Problemdefinition
Wenn ein Dienst dem Internet ausgesetzt ist, besteht die Herausforderung nicht nur darin, den DDoS-Angriff zu filtern. Man braucht auch einen zuverlässigen Weg, legitimen Traffic an das eigentliche Ziel zurückzugeben. Viele Teams betreiben bereits einen Produktionsserver, Proxy, Cluster oder ein Frontend an anderer Stelle und wollen Schutz hinzufügen, ohne alles neu aufzubauen.
Genau hier kommt ein GRE-Tunnel ins Spiel. Der Traffic erreicht zuerst die Mitigation-Schicht, wird dort bereinigt, dann werden die legitimen Flows gekapselt und an den Kunden-Endpunkt zurückgeschickt. Das Ziel ist einfach: den Lärm upstream stoppen und nutzbaren Traffic an die Produktion liefern.
Warum es wichtig ist
In vielen realen Vorfällen fällt nicht die Anwendung zuerst aus. Der Link läuft voll, die Latenz steigt, Warteschlangen wachsen und das Frontend wird instabil, bevor die Geschäftslogik reagieren kann. Deshalb ist die Zustellung von sauberem Traffic so wichtig. Nützliche Mitigation bedeutet nicht nur, den Angriff zu filtern, sondern legitimen Traffic stabil und betreibbar zurückzugeben.
Es ist auch wichtig, weil viele Kunden eine bereits funktionierende Umgebung nicht unter Druck verschieben wollen. GRE wird oft zum praktischen Mittelweg zwischen Nichtstun und einer Komplettmigration.
- Bestehenden Stack erhalten
- Server oder Proxy dort belassen, wo sie bereits laufen.
- Reibung reduzieren
- Netzwerkschutz hinzufügen, bevor ein größerer Umbau besprochen wird.
- Risiko reduzieren
- Ein Clean Handoff ist oft sicherer als eine Notfallmigration.
- Schneller ausrollen
- Ein gut geplantes GRE-Zustellmodell kann schnell live gehen.
Mögliche Modelle
GRE ist nicht das einzige Zustellmodell nach der Mitigation. Die richtige Entscheidung hängt davon ab, wer den IP-Raum ankündigt, wo der saubere Traffic enden soll und wie viel Routing-Kontrolle der Kunde behalten möchte.
| Modell | Vorteile | Grenzen | Typische Eignung |
|---|---|---|---|
| Einfacher GRE-Tunnel | Schnell ausrollbar und reibungsarm | Weniger Routing-Flexibilität als ein vollständiges BGP-Setup | Dedicated Server, Gaming, APIs, SaaS |
| GRE + BGP | Mehr Kontrolle über Ankündigungen und Routing | Aufwendigere Integration | Betreiber und Kunden mit eigenen Präfixen |
| Geschützte IPs + GRE-Handoff | Guter schneller Einstieg | Bewahrt anfangs evtl. nicht die ursprüngliche Adressierung | Tests und schrittweise Rollouts |
| Cross-Connect / direkter Handoff | Sehr sauber für kolokierte Umgebungen | Weniger relevant für entferntes Drittanbieter-Hosting | Datacenter-Präsenz und Betreiber-Designs |
- RFC 2784 — GRE
GRE-Basisspezifikation.
- RFC 2890 — GRE-Erweiterungen
Key- und Sequence-Erweiterungen für GRE.
Wann GRE relevant ist — und wann nicht
GRE ist sehr relevant, wenn man einen bestehenden Server schützen, die Produktion dort belassen will, wo sie bereits läuft, und einen sauberen L3-Handoff akzeptiert. Es ist weniger relevant, wenn man vor allem ein lokales Datacenter-Cross-Connect-Modell braucht oder wenn der finale Endpunkt selbst zu schwach ist, um den sauberen Traffic zu bewältigen.
- Relevant
- Bestehender Server bei Drittanbieter, schnelle Integration, saubere L3-Zustellung.
- Sehr relevant
- Produktionsdienst bereits online und schwer schnell zu migrieren.
- Weniger relevant
- Man braucht vor allem einen direkten lokalen Datacenter-Handoff.
- Allein nicht genug
- Der finale Server ist bereits unterdimensioniert oder der Rückweg ist unklar.
Unser Ansatz
- Schnelle Prüfung von IPs, Routen, MTU und Endpunkt-Kapazität.
- Wahl des Zustellmodells: GRE, GRE + BGP, geschützte IPs oder anderer Handoff.
- Validierung vor der Produktionsumstellung.
- Schrittweiser Rollout bei Bedarf.
Konkreter Anwendungsfall
Ein Gaming-Betreiber betreibt bereits alles auf einem Dedicated Server bei einem anderen Anbieter. Das Hauptziel ist, wiederholte DDoS-Angriffe daran zu hindern, den Link zu sättigen, während der aktuelle Server und Anwendungs-Stack erhalten bleiben. In diesem Szenario ist die Rücklieferung von sauberem Traffic über GRE nach der Mitigation oft der beste Kompromiss.
Den Dienst verstehen
Ports, Latenz-Sensibilität und gewünschtes Zustellmodell werden ermittelt.
Den GRE-Endpunkt vorbereiten
MTU, Firewall, Rückweg und NIC-Verhalten werden validiert.
Filtern und dann zustellen
Nur legitimer Traffic wird über GRE zurückgeliefert.
Später bei Bedarf weiterentwickeln
Das Setup kann einfach bleiben oder sich zu einem reicheren Routing-Modell entwickeln.
Häufige Fehler
Der größte Fehler ist zu glauben, GRE sei die komplette Anti-DDoS-Strategie. Es ist nur eine Zustellmethode nach der Mitigation. Ein weiterer häufiger Fehler ist, MTU, Fragmentierung, Rückweg-Verhalten und Endpunkt-Dimensionierung zu ignorieren.
- GRE aus Gewohnheit wählen, ohne Alternativen zu prüfen.
- MTU- und Fragmentierungsprobleme ignorieren.
- Den Rückweg vergessen.
- Annehmen, der Tunnel behebe einen unterdimensionierten Endpunkt.
FAQ
Ist GRE für Anti-DDoS zwingend?
Nein. Es ist ein verbreitetes und nützliches Handoff-Modell, aber nicht das einzige.
Kann ich einen Dedicated Server schützen, ohne ihn zu migrieren?
Ja. Das ist eine der Hauptstärken eines GRE-Handoff-Modells.
Wann brauche ich GRE + BGP?
Vor allem, wenn man mehr Routing-Kontrolle braucht oder eigene Präfixe ankündigen möchte.
