Auf dieser Seite
Das operative Problem
Im klassischen Modell werden Konnektivität und Mitigation getrennt gekauft. Im Angriff stellt sich heraus, dass der Transit vor der Scrubbing-Schicht sättigt oder der Provider nur Blackhole anbietet.
Für einen Hoster ist das Ändern vieler Kunden-IPs in der Krise unrealistisch. Für Gaming kann falsch platzierter Schutz Latenz und False Positives erhöhen. Geschützter Transit vermeidet Mitigation als nachträglichen Zusatz.
Warum es vor dem Angriff zählt
Der wichtigste Nutzen ist Vorhersagbarkeit. Vor dem Incident lässt sich klären, wo Traffic eintritt, welche Präfixe akzeptiert werden, welche Kapazität den Handoff schützt und wie Commit und Overage funktionieren.
Der zweite Nutzen ist operative Geschwindigkeit. BGP, Tunnel, Post-Filter-Regeln und Eskalation sind bereits definiert. Im Angriff muss kein neuer Pfad improvisiert werden.
Mögliche technische Ansätze
Reverse Proxy passt zu einem konkreten Endpoint. On-Demand-Scrubbing hilft, wenn Diversion akzeptabel ist. Lokale Firewalls bleiben nach Volumenreduktion wichtig. Für netzwerkweite Exposition ist geschützter Transit aber oft die sauberste Basis.
Die Architektur kann geschützten Transit, Tunnel zu entfernten Servern, Router-VM für BGP-Kontrolle und Gaming-Filter kombinieren, wenn UDP besonders sensibel ist.
Konkreter Anwendungsfall
Eine Hosting-Plattform erhält wiederholt Angriffe auf verschiedene Kunden-IPs. Eine lokale Firewall hilft nicht, wenn der Upstream-Port voll ist. Geschützter Transit reinigt den Traffic, bevor er den Kundenrand überlastet.
Bei Gaming reicht es nicht, den Link nur am Leben zu halten. Spieler müssen verbunden bleiben. Deshalb braucht die Transitschicht Raum für speziellere Logik, wenn das Protokoll empfindlich ist.
Häufige Fehler vermeiden
- Provider-Grenzen ignorieren.
