So richten Sie Policy Routing für getrennten Backup- und Benutzerverkehr ein

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Set Up Policy Routing for Separate Backup and User Traffic - Zima Store Online

Trennen Sie den Backup-Datenverkehr mit einer expliziten Quelladresse oder Paketmarkierung, einer dedizierten Routing-Tabelle und einer eng gefassten Regel. Ersetzen Sie nicht die zentrale Standardroute und gehen Sie nicht davon aus, dass Schnittstellenmetriken zwei Workloads desselben Hosts klassifizieren können.

Dieses Design ist nützlich, wenn interaktive Benutzer die schnelle oder latenzarme Verbindung benötigen, während geplante Backups ein sekundäres Gateway verwenden. Das Risiko besteht in asymmetrischem Routing: Antworten verlassen den Host über eine andere Schnittstelle als die Anfrage, wodurch zustandsbehaftete Firewalls oder entfernte Peers die Sitzung ablehnen können. Behalten Sie den Konsolenzugriff bei, dokumentieren Sie die ursprünglichen Regeln und erstellen Sie den alternativen Pfad, bevor Sie Datenverkehr dorthin leiten.

Wählen Sie einen stabilen Klassifizierer

Verwenden Sie eine dedizierte Quell-IP-Adresse, wenn der Backup-Dienst an eine bestimmte Adresse gebunden werden kann. Sie lässt sich leichter überprüfen und übersteht Dienstneustarts besser als Regeln, die auf sich ändernden Zieladressen basieren.

Wenn beide Workloads dieselbe Adresse verwenden, klassifizieren Sie Backup-Verbindungen mit einer Firewall-Markierung und übernehmen Sie diese Markierung für die Verbindung. Das Linux-Policy-Routing wertet Regeln aus, bevor es die ausgewählte Tabelle konsultiert; die Routing-Policy-Datenbank ist daher die Entscheidungsebene, während jede Tabelle Routen enthält.

Klassifizieren Sie nicht ausschließlich anhand des IP-Bereichs eines Cloud-Anbieters, es sei denn, Sie kontrollieren und pflegen diese Liste. Wenn keine stabile Quelle, kein stabiles Ziel, kein Port, kein Benutzer und kein Namespace den Backup-Datenfluss identifiziert, halten Sie an und trennen Sie den Workload zunächst auf Container- oder Netzwerkschnittstellenebene.

Erstellen Sie die Backup-Tabelle, bevor Sie ihre Regel hinzufügen

Erstellen Sie eine benannte Tabelle mit der Route für das direkt verbundene Subnetz und der Standardroute des Backup-Gateways. Ohne die Route für das direkt verbundene Subnetz ist möglicherweise sogar das Gateway selbst nicht erreichbar, obwohl der Standardeintrag korrekt aussieht.

Prüfen Sie die geplante Entscheidung mit einer Routensuche, bei der dieselbe Quelladresse oder Markierung angegeben wird, die der Dienst verwenden soll. Zeigt das Ergebnis die Backup-Schnittstelle und die erwartete Quelle, ist die Prüfung erfolgreich. Fällt die Suche auf die Haupttabelle zurück, sind der Klassifizierer oder die Priorität falsch.

Fügen Sie die eng gefasste Regel mit einer Priorität hinzu, die vor der allgemeinen Regel für die Haupttabelle liegt, aber lokale Routen nicht überschreibt. Halten Sie im selben Terminalfenster einen expliziten Rollback-Befehl bereit und testen Sie niemals zuerst über den Pfad, den Sie gerade ändern.

Bewahren Sie Antwortsymmetrie und lokalen Zugriff

Stellen Sie sicher, dass der Upstream-Router weiß, wie Datenverkehr zum ausgewählten Quellnetz zurückgeleitet wird, oder wenden Sie Source NAT nur an der richtigen Ausgangsgrenze an. Eine Policy-Regel kann eine ausgehende Route auswählen, aber sie kann ein entferntes Gateway nicht dazu bringen, ein unbekanntes privates Subnetz zu verstehen.

Prüfen Sie die Reverse-Path-Filterung, wenn gültige Antworten über eine Schnittstelle eintreffen, die Linux anhand der Haupttabelle nicht auswählen würde. Verwenden Sie einen für das Multihoming-Design geeigneten Modus, anstatt die Validierung global zu deaktivieren, und überprüfen Sie die Entscheidung mit Paketaufzeichnungen auf beiden Schnittstellen.

Belassen Sie Verwaltungs-, DNS- und LAN-Datenverkehr in der Haupttabelle, sofern eine Trennung nicht erforderlich ist. Der ZimaSpace-Leitfaden zur zuverlässigen Nutzung von Netzwerkfreigaben ist eine nützliche Ergänzung, wenn das geroutete Backup ebenfalls von einem eingebundenen Speicherpfad abhängt.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Testen Sie auch Fehlerfälle

Starten Sie eine interaktive Übertragung und ein Backup und überprüfen Sie anschließend die Schnittstellenzähler und den Verbindungsstatus. Die Backup-Datenmenge sollte nur am Backup-Ausgang steigen, während die Benutzersitzung auf dem primären Pfad bleibt.

Blockieren oder trennen Sie das Backup-Gateway vorübergehend während eines kontrollierten Zeitfensters. Wenn das Design ausfallsicher im Sinne von fail-closed ist, sollte das Backup anhalten, ohne stillschweigend auf die Benutzerverbindung zu wechseln. Wenn ein Failover vorgesehen ist, dokumentieren Sie dieses Verhalten und begrenzen Sie seine Bandbreite.

Starten Sie den Host einmal neu und wiederholen Sie die ursprüngliche parallele Auslastung, damit die dauerhafte Gültigkeit von Regelreihenfolge und Markierungen nachgewiesen ist. Beenden Sie den Test, sobald Routensuchen, Paketaufzeichnungen und Anwendungsprotokolle übereinstimmen. Führen Sie ein Rollback durch, wenn sich der Verwaltungszugriff ändert, Antworten asymmetrisch werden oder nicht zugehöriger Datenverkehr in die Backup-Tabelle gelangt.