Notwendige Cookies
Anforderungen an den Aufbau
DDoS-Schutz für Hosting- und Serveranbieter
Ein angegriffener Kunde sollte nicht zu einem unerklärlichen Ausfall eines ganzen Racks oder Virtualisierungsclusters führen. Klären Sie gemeinsame Ressourcen, kundenspezifische Richtlinien und den Eintrittspunkt des geschützten Verkehrs.
Bei den für Kunden unsichtbaren Hostinggrenzen beginnen
- Ein gemeinsamer Engpass hinter isolierten Gästen
- VM-Isolation trennt nicht die Kapazität von Uplink, NIC-Warteschlangen oder Hypervisor. Ein Host kann seine Paketverarbeitung auslasten, obwohl die Bandbreite gering wirkt. Halten Sie Beobachtungen an physischer Schnittstelle, Host und Gast getrennt.
- Unterschiedliche Lasten im selben Netz
- VPN, Maildienst, Gameserver und öffentliche Website haben unterschiedliche legitime Paketmuster. Eine pauschale Regel kann Überlast durch Fehlalarme ersetzen. Definieren Sie betroffenes Präfix oder Dienst und die Freigabe von Änderungen.
- Verantwortung entlang der Wiederverkaufskette
- Hoster, Endkunde und Upstream können jeweils Teile von Adressierung, Routing und Störungsbehandlung besitzen. Vereinbaren Sie, wer Ankündigungen prüft, Fehlalarme meldet und die Wiederherstellung dem Kunden mitteilt.
Den Betreiber der Filterschicht bestimmen
Ein geschützter Netzdienst kann an den Rand des Hostingnetzes übergeben werden. Betreiber geeigneter Hardware können zusätzlich Defense Fabric für lokale Filterung prüfen. Softwarelizenz, Transport und Dienst gegenüber dem Endkunden bleiben getrennte Verantwortungen.
Den gemeinsamen Eingang schützen
Definieren Sie Präfixe oder öffentliche Endpunkte, gelieferte Bandbreite und Umfang des vorgeschalteten Schutzes.
Eine verantwortete lokale Richtlinie anwenden
Qualifizieren Sie bei nötiger lokaler Filterung Hardware, Portanordnung, Verkehrsverteilung und ausgewählte Regeln.
Das Kundenerlebnis prüfen
Testen Sie echte Verbindungen aus dem unterstützten Lastmix und behalten Sie einen Weg zur vorherigen Richtlinie.
Beispielhafter Ablauf. Angebot und Abnahmeprotokoll bestimmen den gelieferten Dienst.
Fragen, die das Design verändern
- Möchten Sie verwaltete Übergabe oder eigene Filterserver betreiben?
- Vergleichen Sie Betriebsumfang statt nur Lizenz- und Transitpreise. Lokale Filterung braucht kompatible Hardware, Wartung, Beobachtung und ein vereinbartes Reaktionsverfahren.
- Welcher Verkehr darf mehrere Filterknoten durchlaufen?
- Definieren Sie Eingang, Rückweg, Zustandsinhaber und Ausfallverhalten. Zusätzliche Knoten oder Schnittstellen schaffen nicht automatisch nutzbare Kapazität beim Verlust eines Knotens.
- Wie werden Kunden im Betrieb unterschieden?
- Pflegen Sie die Zuordnung freigegebener Präfixe oder Endpunkte zu Dienstverantwortlichen und Richtlinien. Nutzen Sie sie bei Vorfällen. Eine gemeinsame Adresse oder breite Regel identifiziert nicht zwangsläufig einen einzelnen Kunden.
Einen repräsentativen Mix gehosteter Dienste testen
- Erfassen Sie erfolgreiche Verbindungen der tatsächlich verkauften Dienste, einschließlich gemeinsam genutzter Quelladressen.
- Beobachten Sie Hostwarteschlangen, Verluste, Regelzähler und Anwendungserfolg im selben Zeitraum.
- Erproben Sie vereinbarte Richtlinienrücknahme und Ersatzpfad, und prüfen Sie danach die Dienste unbetroffener Kunden.
Fragen zu diesem Aufbau
Enthält eine Defense-Fabric-Lizenz geschützten Transit und Server?
Nein. Kompatible Hardware, Hosting und Transport sind separat zu kalkulieren. Ein optionaler Peeryx-Netzdienst erscheint als eigene Komponente.
Deckt ein Spielprofil alle gehosteten Anwendungen ab?
Nein. Nutzen Sie dokumentierte Funktionen für das tatsächliche Protokoll und testen Sie legitimen Verkehr. FiveM- und Minecraft-Java-Übergaben benötigen jeweils eine Kompatibilitätsprüfung.