Praxisnaher Leitfaden, um einen bereits produktiven Dedicated Server bei OVH, Hetzner oder einem anderen Anbieter ohne Komplettmigration zu schützen – mit GRE, mit oder ohne BGP.
Schutz ohne Komplettmigration
Eine Anti-DDoS-Schicht lässt sich hinzufügen, ohne die gesamte Produktion neu aufzubauen.
Ein GRE-Tunnel ist oft schneller eingeführt als eine komplette Migration.
Nur Tunnel, GRE + BGP oder geschützte IPs: die passende Architektur hängt vom realen Setup ab.
MTU, Rückweg, Routing und reale Serverkapazität müssen sauber geprüft werden.
Viele Unternehmen, Gaming-Betreiber, SaaS-Plattformen und Internet-exponierte Dienste betreiben ihre Infrastruktur bereits auf Dedicated Servern bei OVH, Hetzner oder ähnlichen Providern. Wenn DDoS-Angriffe beginnen, hört man oft zuerst: Alles muss migriert werden. In der Praxis ist das weder die einzige noch immer die beste Option.
In vielen Fällen ermöglicht ein Anti-DDoS-Design mit GRE, mit oder ohne BGP, den Schutz des Dienstes, während der Server dort bleibt, wo er bereits produktiv läuft. Die Frage ist also nicht nur, wie man den Angriff stoppt, sondern wie man ein realistisches, stabiles und produktionsfähiges Übergabemodell wählt.
Das häufigste Szenario ist klar: Der Kunde hat bereits einen Dedicated Server bei Hetzner, OVH oder einem ähnlichen Anbieter. Die Dienste laufen produktiv, die IPs werden bereits genutzt, Backups und Monitoring existieren und oft hängen weitere Systeme an dieser Umgebung.
Wenn DDoS-Angriffe wiederkehrend werden, ist das Problem nicht nur applikativ. Die Anbindung kann gesättigt sein, bevor die Anwendung reagieren kann, die Latenz steigt, die Nutzererfahrung leidet und eine überstürzte Migration erzeugt oft mehr Risiko als Stabilität.
Genau für solche Fälle ist ein Schutz via GRE, mit oder ohne BGP, sinnvoll: Eine Mitigationsschicht wird vorgelagert, ohne den bestehenden Produktions-Stack aufzubrechen.
Eine Komplettmigration klingt auf dem Papier logisch, in der Produktion sieht die Realität anders aus. Kunden müssen häufig Netzwerkabhängigkeiten, Betriebsabläufe, Skripte, Lizenzen, Inter-Server-Flows und manchmal auch vertragliche oder geschäftliche Vorgaben erhalten.
Das vernünftige Ziel ist daher nicht, standardmäßig alles zu verlagern. Ziel ist es, wirksamen Schutz hinzuzufügen, ohne unnötiges Betriebsrisiko zu erzeugen.
Eine komplette Architektur während Angriffs- oder Instabilitätsphasen neu aufzubauen, ist selten die beste Entscheidung.
Der Kunde behält Server, Betriebsabläufe, Storage, Monitoring und lokale Abhängigkeiten.
Ein sauber integrierter GRE-Tunnel ist oft schneller produktiv als ein kompletter Umzug.
Man kann mit einem exponierten Dienst beginnen und das Modell später erweitern.
Ein GRE-Tunnel kapselt sauberen Traffic zwischen der Mitigationsinfrastruktur und Ihrem Dedicated Server oder Router. Der öffentliche Traffic erreicht zuerst die Anti-DDoS-Schicht, wird gefiltert und nur legitimer Traffic wird über den Tunnel zurückgegeben.
In diesem Modell bleibt der Zielserver bei OVH, Hetzner oder einem anderen Anbieter. Er empfängt nicht mehr direkt rohen Internet-Traffic, sondern bereinigten Traffic – so bleibt die bestehende Umgebung erhalten und eine ernsthafte Netzschutzschicht kommt hinzu.
Das ist besonders nützlich für bereits produktive Dienste, Gaming-Workloads, Geschäftsanwendungen oder Infrastrukturen, die nicht über Nacht umgezogen werden können.
Geschützte IPs oder angekündigte Präfixe landen zuerst auf der Anti-DDoS-Infrastruktur.
Ziel ist es, bösartigen Traffic zu stoppen, bevor er Ihre Produktion erreicht.
Bereinigter Traffic wird via GRE an Ihren Dedicated Server oder Router geliefert.
Ihre Anwendung bleibt beim bisherigen Provider, aber hinter einer dedizierten Mitigationsschicht.
BGP ist vor allem dann sinnvoll, wenn der Kunde eigene IP-Präfixe announcen, Routing-Kontrolle behalten oder den Schutz in eine weitergehende Netzarchitektur integrieren möchte. Für einige Profile ist das sehr wichtig, aber nicht in jedem Deployment zwingend notwendig.
In vielen Fällen können wir auch eigene geschützte Anti-DDoS-IP-Adressen nutzen und den bereinigten Traffic über den GRE-Tunnel zum Dedicated Server bei OVH oder Hetzner zurückführen. In diesem Szenario muss der Kunde nicht zwingend seine eigenen Präfixe announcen, um zu starten.
Anders gesagt: BGP ist ein Werkzeug für Architektur und Flexibilität. Es ist keine absolute Voraussetzung, um einen extern gehosteten Dienst zu schützen.
Ideal bei eigenem ASN, eigenen Präfixen oder wenn feinere Routing-Kontrolle gewünscht ist.
Der einfachere Weg, wenn schneller Schutz wichtiger ist als zusätzliche Routing-Komplexität.
Der Traffic landet auf geschützten IPs und wird über den Tunnel an den Dedicated Server geliefert.
Man kann einfach starten und später zu einem BGP-Design wechseln, wenn sich die Anforderungen ändern.
Die richtige Entscheidung hängt vom gewünschten Grad an Netzwerkkontrolle, von der gewünschten Umsetzungsgeschwindigkeit und davon ab, ob eigene IP-Präfixe genutzt werden. Es gibt kein Einheitsmodell für alle Kunden.
Oft die beste Wahl, um einen produktiven Dedicated Server schnell zu schützen – ohne ASN und ohne BGP-Ankündigungen.
Passender, wenn Sie eigene IPs besitzen, Ihre Announcements behalten und mehr Netzwerkflexibilität wünschen.
Sehr praktisch für einen schnellen Start, um Latenz und Integration zu validieren und sofortige Umadressierung zu vermeiden.
Relevant für größere Umgebungen oder Kunden mit direkter Datacenter-Präsenz und strengeren Handoff-Anforderungen.
Eine gute Schutzlösung sollte nicht als Magie verkauft werden. Wichtig ist zu verstehen, was diese Architektur wirklich löst und was auf Kundenseite weiterhin geprüft werden muss.
Der wichtigste Punkt ist, vorhandene Server weiter zu nutzen, statt einen Komplettumzug zu erzwingen.
Zuerst lässt sich ein einzelner Dienst schützen, dann kann das Modell erweitert werden.
MTU, Rückrouting, Firewall-Regeln, lokale Policies und die tatsächliche Maschinenkapazität müssen ernsthaft geprüft werden.
Wenn Anwendung, Server oder internes Design bereits ohne Angriff überlastet sind, reicht Netzschutz allein nicht aus.
Bei Peeryx geht es nicht darum, standardmäßig eine Vollmigration zu verkaufen. Zuerst betrachten wir die bestehende Infrastruktur, die sinnvollste Übergabemethode und das tatsächlich benötigte Maß an Netzwerkkontrolle.
Je nach Fall kann das geschützte IPs bedeuten, die via GRE an Ihren Dedicated Server geliefert werden, ein BGP-basiertes Design für eigene Announcements oder einen schrittweisen Rollout, der sich zuerst auf die exponiertesten Dienste konzentriert.
Stellen wir uns einen Kunden vor, der bereits einen Game-Server oder ein Application-Backend bei Hetzner betreibt. Er möchte diese Maschine behalten, weil die gesamte Umgebung bereits vorbereitet ist, aber wiederkehrende Angriffe machen den Dienst instabil und eine komplette Migration ist kurzfristig nicht wünschenswert.
Der sauberste Weg besteht oft darin, den öffentlichen Traffic zuerst auf eine dedizierte Anti-DDoS-Schicht zu führen, den Angriff zu filtern und nur legitimen Traffic per GRE an den Hetzner-Server zurückzuliefern. Besitzt der Kunde eigene IPs oder benötigt mehr Routing-Kontrolle, kann BGP ergänzt werden. Andernfalls kann er direkt mit geschützten IPs auf Mitigationsseite starten.
Geprüft werden Diensttyp, Latenzempfindlichkeit, Betriebsmodell und die Fähigkeit des Servers, bereinigten Traffic aufzunehmen.
Nur Tunnel, Tunnel + BGP oder geschützte IPs – je nach gewünschtem Kontrollniveau.
GRE, Rückweg, MTU und Gesamtstabilität werden vor dem echten Cutover validiert.
Der Kunde behält die bestehende Infrastruktur und gewinnt eine Mitigationsschicht, die zum realen Use Case passt.
Die meisten Probleme entstehen nicht durch GRE oder BGP selbst, sondern durch schwaches Scoping oder eine Architektur, die auf dem Papier einfacher aussieht als in der Produktion.
Ja. Das ist einer der häufigsten Fälle: Der Server bleibt bei Hetzner und erhält legitimen Traffic via GRE nach upstream Mitigation.
Nein. BGP ist für manche Kunden sinnvoll, aber GRE mit geschützten IPs reicht für viele Deployments aus.
Ja. Der Traffic wird upstream bereinigt und dann über ein passendes Design zum OVH-Server zurückgeliefert.
Ja. Das ist oft der sauberste Weg: einfach beginnen, Produktion validieren und BGP später ergänzen, wenn es Mehrwert bringt.
Ja, gerade weil sich Schutz hinzufügen lässt, ohne von Anfang an eine Vollmigration zu erzwingen.
Einen Hetzner- oder OVH-Dedicated-Server gegen DDoS zu schützen, bedeutet nicht automatisch, alles umzuziehen. In vielen Fällen ergänzt ein GRE-basiertes Design – mit oder ohne BGP – eine ernsthafte Mitigationsschicht, während die bestehende Produktionsumgebung erhalten bleibt.
Das richtige Modell hängt von der technischen Realität ab: Bedarf an eigenen IPs, Wunsch nach Routing-Kontrolle, Fokus auf schnelle Einführung oder der Bedarf, mit bereits betriebenen geschützten IPs zu starten.
Das eigentliche Ziel ist also nicht nur, einen Angriff zu stoppen, sondern eine glaubwürdige, saubere und produktionsfähige Architektur zu wählen.
Beschreiben Sie uns Ihre aktuelle Infrastruktur, Ihren Hosting-Provider, die Netzanforderungen und den gewünschten Kontrollgrad. Wir sagen Ihnen, ob ein einfacher GRE-Tunnel, GRE + BGP oder eine Übergabe über geschützte IPs am sinnvollsten ist.
