Auf dieser Seite
Das Wichtigste
- Den Weg vor dem Host schützenEin lokaler Filter stellt keine Pakete wieder her, die bereits auf einem überlasteten Upstream verloren gingen.
- Für jede Entscheidung eine Zuständigkeit festlegenÜberlappende Filter und unabhängige Zustände können widersprüchliche Ergebnisse erzeugen.
- Wiederherstellung beobachtbar haltenZähler, Versionen und eine geprüfte Rücknahme müssen dem Verkehrsweg folgen.
Jeder Ebene eine Aufgabe zuweisen
Eine eigene Filterkette ist eine Folge von Entscheidungen, keine Liste installierter Produkte. Beginnen Sie mit der Ressource, die jede Ebene schützt. Vorgeschaltete Mitigation kann Verkehr reduzieren, bevor der Anschluss überlastet ist. Frühe lokale Prüfungen können ungeeignete Pakete vor teurerer Verarbeitung verwerfen. Zustandsabhängige Kontrollen setzen Verbindungsregeln durch; die Anwendung prüft Identität, Berechtigung und Anfrageverhalten.
Diese Funktionen können in einer oder mehreren Plattformen liegen, ihre Grenzen müssen aber verständlich bleiben. Ein zusätzlicher Filter ohne klaren Zweck erschwert die Suche nach Fehlalarmen. Verwalten zwei Ebenen Verbindungszustände, müssen Sichtbarkeit von Hin- und Rückweg sowie das Verhalten bei einem anderen Worker oder Knoten geklärt sein.
| Ebene | Zweck | Aufzubewahrende Nachweise |
|---|---|---|
| Vorgeschalteter Pfad | Verkehr vor einem begrenzten Übergabelink reduzieren. | Upstream-Entscheidung, Eingangs- und Übergabezähler sowie Umleitungszustand. |
| Frühe Paketverarbeitung | Eng definierten unerwünschten Verkehr mit begrenztem Aufwand verwerfen. | Trefferzähler, Verluste der Empfangswarteschlangen und genaue aktive Regelversion. |
| Verbindungsrichtlinie | Zugriffs- und Zustandsverhalten für unterstützten Verkehr durchsetzen. | Erfolgreiche Verbindungen, Allokationsfehler und Beobachtungen des Rückwegs. |
| Anwendung | Nutzer und Anwendungsanfragen prüfen. | Erfolgreiche Aktionen, Fehlerarten, Antwortzeit und Backend-Last. |
Frühe Prüfungen am tatsächlichen Ausführungspunkt platzieren
Ein XDP-Programm kann früh in einem unterstützten Empfangspfad laufen; der Einhängemodus ist jedoch entscheidend. Treiberunterstützung, nativer oder generischer Betrieb sowie vorgesehene Umleitung oder Weiterleitung müssen an der realen Schnittstelle geprüft werden. Dass der eBPF-Verifier ein Programm akzeptiert, beweist weder korrekte Klassifikation noch eine bestimmte Paketrate des Hosts.
Ein Userspace-Weiterleitungspfad kann die Schnittstelle anders verwalten. Software mit DPDK oder einer bestimmten NIC-Bindung muss zusammen mit der übrigen Hostkonfiguration qualifiziert werden. Gehen Sie nicht davon aus, dass jede Kernel-Funktion im Paketpfad bleibt. Prüfen Sie das dokumentierte Betriebsmodell des Produkts, bevor Sie es mit einer weiteren Datenebene kombinieren.
Beginnen Sie mit wenigen erklärbaren Regeln. Begrenzen Sie den Geltungsbereich auf eigenen Verkehr, benennen Sie legitime Pakete, die einem Treffer ähneln, und behalten Sie eine Abschaltmöglichkeit. Ein breites zustandsloses Muster unterscheidet nicht jede legitime Anfrage von einem Angriff, nur weil es früh ausgeführt wird.
Den Verarbeitungspfad statt nur das NIC-Etikett dimensionieren
Pakete pro Sekunde, Bytes auf der Leitung, Flow-Verteilung und Zustandserzeugung beeinflussen die Last. RSS verteilt anhand der von der NIC unterstützten Felder und Hashes; eine gleichmäßige Verteilung jedes Angriffs ist nicht garantiert. Eine einzelne überlastete Warteschlange kann Pakete verlieren, während andere Kerne untätig wirken. Prüfen Sie reale Queue- und Interrupt-Zuordnung, Worker-Platzierung und NUMA-Beziehung zu den Schnittstellen.
Bei Inline-Übergabe durchläuft Verkehr Eingangs- und Ausgangsressourcen. Anzahl der Ports, Richtung und Reserve sind deshalb ebenso wichtig wie gemessene Filterleistung. Ein zweiter Server als Ersatz verdoppelt nicht automatisch die unter dem geforderten Ausfallszenario nutzbare Kapazität. Kalkulieren Sie die Konfiguration, die weiterarbeiten muss, und messen Sie mit aktiver Zielrichtlinie.
Zustandsabhängige Kontrollen mit dem Routing abstimmen
Connection Tracking, SYN-Proxy und protokollbewusste Filter benötigen die Sichtbarkeit, die ihre Implementierung voraussetzt. Umgeht der Rückverkehr den Zustandsinhaber, kann eine legitime Verbindung unvollständig erscheinen. Mehrere aktive Pfade können konsistentes Hashing, Zustandssynchronisierung oder eine unterstützte zustandslose Alternative benötigen. Zwei BGP-Sitzungen stellen diese Eigenschaften nicht automatisch her.
Änderungen an Kapselung, ECMP, NAT oder Lastverteilung können ebenfalls ändern, welcher Knoten einen Flow sieht. Dokumentieren Sie dies vor dem Aktivieren einer neuen zustandsabhängigen Funktion. Prüfen Sie bei Defense Fabric die dokumentierten Routinganforderungen des gewählten TCP-Modus und qualifizieren Sie Redundanz mit aktivem Modus. Leiten Sie daraus keine beliebige Unterstützung asymmetrischer Zustandsprüfung ab.
Anwendungsentscheidungen der passenden Komponente überlassen
Ein Netzfilter kann unerwünschte Pakete reduzieren und unterstützte Protokollprüfungen anwenden. Er wird nicht allein durch seine Position vor einem Server zum Autorisierungssystem. Belassen Sie Anmeldekontrollen, Anfragebudgets, Ursprungszugriff und Anwendungsüberwachung dort, wo der nötige Kontext verfügbar ist.
Unterscheiden Sie beim Spielehosting das tatsächlich unterstützte Protokoll von einer allgemeinen UDP-Freigabe. Minecraft Java und FiveM haben unterschiedliche Übergabewege und Prüfschritte. Testen Sie normalen Verbindungsaufbau und Spielverhalten, nicht nur die Erreichbarkeit einer Adresse. Aktivieren Sie kein fremdes Profil, nur weil sein Name ähnlich klingt.
Dasselbe Beobachtungsintervall durch die Filterkette verfolgen
Beschriften Sie jedes Diagramm mit Messpunkt, Richtung, Stichprobenverfahren und Zeitraum. Angebotenes Upstream-Verkehrsvolumen, gesampelte Flow-Schätzungen, NIC-Zähler und Anwendungsanfragen sind unterschiedliche Messungen. Ein Rückgang kann erfolgreiche Filterung, frühere Verluste, eine Routingänderung oder einen ausgefallenen Collector bedeuten. Verknüpfen Sie die Nachweise, bevor Sie eine Ursache benennen.
Erfassen Sie aktive Konfigurationsversionen und den Zeitpunkt jeder Änderung. Nutzen Sie begrenzte Zähler, statt während einer Flut jedes verworfene Paket zu protokollieren. Unterscheiden Sie bei ausgefallener Telemetrie „keine Beobachtung“ von „kein Verkehr“. Prüfen Sie die Wiederherstellung von Collector und Weiterleitung getrennt.
Änderungen schrittweise qualifizieren
Defense Fabric, geschützter Transit IP und Flow Collector können an unterschiedlichen Stellen dieses Aufbaus beteiligt sein. Softwarelizenzierung, Transport und Telemetrieerfassung benötigen weiterhin getrennte Qualifikation. Ein erfolgreicher Test auf einem Host belegt diesen Host und diese Last, nicht eine allgemeine Kapazitätsgarantie für alle Kunden.
Den bestehenden Weg erfassen
Schnittstellen, Routing, Regelverantwortliche und Anwendungserfolg vor der Änderung dokumentieren.
Eine Kontrolle testen
Repräsentativen Verkehr in einer freigegebenen isolierten Umgebung verwenden; legitimes Verhalten und verworfene Pakete prüfen.
Ausfall und Rücknahme erproben
Vereinbarten Knoten- oder Pfadausfall testen und Zustandsverhalten sowie Wiederherstellung bestätigen.
Ein versioniertes Abnahmeprotokoll führen
Geprüfte Software, Hardware, Regeln, Beobachtungen und verbleibende Grenzen zusammen aufbewahren.
Fragen zum Aufbau
Kann ich XDP vor jede DPDK-Anwendung setzen?
Gehen Sie nicht davon aus. Schnittstellenverwaltung, Treibermodus und tatsächlicher Empfangspfad hängen vom Aufbau ab. Prüfen Sie die unterstützte Architektur vor dem Kombinieren von Datenebenen.
Verbessert ein zweiter Filter den Schutz immer?
Nein. Er braucht eine definierte Aufgabe und kompatibles Routing- und Zustandsverhalten. Andernfalls kann er Latenz, Fehlalarme oder unklare Zuständigkeiten hinzufügen.
Was belegt die Betriebsbereitschaft der Kette?
Ein Abnahmeprotokoll, das realen Verkehrsweg, legitime Anwendungstests, repräsentative isolierte Last, Ausfallverhalten und Rücknahme verbindet — nicht allein die Portgeschwindigkeit.
