Policy-Based Routing (PBR) unter Linux: Multiple Routing-Tabellen, ip rule & fwmark

Erstellt: 08.11.2026 · Zuletzt aktualisiert: 08.11.2026 · Nejat Hakan

Management Summary: Klassisches IP-Routing trifft Entscheidungen ausschließlich anhand der Ziel-IP-Adresse. Sobald ein Server über mehrere Internetanbindungen verfügt (Multi-WAN Multihoming), isolierte Mandantennetze betreibt oder bestimmte Dienste über ein VPN leiten soll, führt zielbasiertes Routing unweigerlich zu asymmetrischen Pfaden und Verbindungsabbrüchen. Policy-Based Routing (PBR) erschließt die Routing Policy Database (RPDB) des Linux-Kernels: Pakete werden flexibel nach Quell-IP, Eingangs-Schnittstelle oder Firewall-Markierungen (fwmark) über getrennte Routing-Tabellen gesteuert.

Die RPDB-Architektur

Die Routing Policy Database (ip rule), Prioritätsstufen (0–32767) und Standard-Tabellen (local, main, default) verstehen.
:material-table-split:{ .lg .middle } Eigene Routing-Tabellen

Benannte Tabellen in /etc/iproute2/rt_tables registrieren, um ISP-Gateways und VPN-Tunnels sauber von der Haupt-Routingtabelle zu isolieren.
Multi-WAN Multihoming

Das Problem asymmetrischer Rückpfade lösen: Antwortpakete für WAN-2 verlassen das System garantiert über das Gateway von WAN-2.
Firewall-Markierungen (fwmark)

Pakete in nftables nach Port, Protokoll oder Prozess markieren und gezielt über alternative Routingtabellen ins Netz leiten.

1. Das Dilemma des rein zielbasierten Routings

Im Standardbetrieb nutzt der Linux-Kernel eine einzige primäre Routingtabelle (main). Wenn ein Prozess Daten an 93.184.216.34 sendet, prüft der Kernel ausschließlich die Ziel-IP:

Ziel: 93.184.216.34 -> Treffer: default via 203.0.113.1 dev eth0 (ISP 1)

Die Falle des asymmetrischen Routings bei Multi-WAN

Betrachten wir einen Server mit zwei Provider-Anbindungen (Dual-WAN): * eth0 (ISP 1): 203.0.113.10 (Standard-Gateway: 203.0.113.1) * eth1 (ISP 2): 198.51.100.20 (Gateway: 198.51.100.1)

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    CLIENT["Internet-Client"] ==>|"1. SYN an eth1 (ISP 2)"| SRV["Multi-Homed Server"]
    SRV -.->|"2. Route zu ISP 1<br/>SYN-ACK verlässt eth0"| ISP1["ISP 1 Router"]
    ISP1 -->|"3. VERWORFEN (Anti-Spoof)"| BLACKHOLE["Paket verloren / Hang"]

Da die Standardroute des Kernels über ISP 1 zeigt, schickt der Server die Antwort (SYN-ACK) über eth0 heraus – jedoch mit der Quell-IP von eth1. Der Router von ISP 1 erkennt eine fremde IP und verwirft das Paket, oder Stateful-Firewalls blockieren den asymmetrischen Datenstrom.

2. Die Routing Policy Database (RPDB)

Linux löst dieses Problem über die Routing Policy Database (RPDB). Bevor der Kernel eine Routingtabelle konsultiert, prüft er eine priorisierte Liste von Regeln:

ip rule show

Standardausgabe auf einem frischen Debian-System:

0:     from all lookup local
32766: from all lookup main
32767: from all lookup default

Priorität 0 (local-Tabelle): Für Loopback-Verkehr, lokale IP-Adressen und Broadcasts. Unveränderlich.
Priorität 32766 (main-Tabelle): Die normale Routingtabelle, die durch ip route add oder DHCP befüllt wird.
Priorität 32767 (default-Tabelle): Historische Fallback-Tabelle; heute kaum noch genutzt.

3. Eigene Routingtabellen registrieren

Zusätzliche Tabellen werden intern über eine numerische ID (1 bis 2147483647) identifiziert. Um Konfigurationen lesbar zu halten, werden den IDs in /etc/iproute2/rt_tables sprechende Namen zugewiesen:

# Eigene Tabellen in /etc/iproute2/rt_tables eintragen
sudo bash -c 'echo "201 isp2" >> /etc/iproute2/rt_tables'
sudo bash -c 'echo "202 vpn_out" >> /etc/iproute2/rt_tables'

Inhalt überprüfen:

cat /etc/iproute2/rt_tables

4. Multi-WAN Multihoming in der Praxis

Um das asymmetrische Routing bei zwei Internetanbindungen zu beheben, setzen wir eine klare Regel durch: Verkehr, der mit der IP von ISP 2 antwortet, muss zwingend über die Routingtabelle von ISP 2 abgewickelt werden.

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    A["Ausgehendes Paket"] --> B{"ip-Regeln prüfen"}
    B -->|"Src: 198.51.100.20"| C["Tabelle 'isp2'<br/>Default via eth1"]
    B -->|"Alle anderen Pakete"| D["Tabelle 'main'<br/>Default via eth0"]

Schritt 1: Tabelle `isp2` befüllen

Tabelle isp2 erhält ein eigenes Standard-Gateway sowie das lokale Subnetz:

# Eigenes Default-Gateway für ISP 2 in Tabelle isp2 anlegen
sudo ip route add default via 198.51.100.1 dev eth1 table isp2

# Lokales Subnetz eintragen, damit direkt erreichbare Hosts gefunden werden
sudo ip route add 198.51.100.0/24 dev eth1 src 198.51.100.20 table isp2

Schritt 2: Richtlinie (Policy Rule) anlegen

# Jedes Paket mit der Absender-IP 198.51.100.20 nutzt Tabelle isp2
sudo ip rule add from 198.51.100.20 table isp2 priority 1000

Schritt 3: Pfadauswahl des Kernels verifizieren

Mit ip route get lässt sich die Entscheidung des Kernels direkt überprüfen:

# Route für Ziel-IP mit Absenderadresse von ISP 2 abfragen
ip route get 8.8.8.8 from 198.51.100.20
# Ausgabe: 8.8.8.8 from 198.51.100.20 via 198.51.100.1 dev eth1 table isp2

# Route ohne Angabe der Quell-IP abfragen (fällt auf die Haupttabelle zurück)
ip route get 8.8.8.8
# Ausgabe: 8.8.8.8 via 203.0.113.1 dev eth0 table main

5. Wegesteuerung über Firewall-Markierungen (`fwmark`)

Wenn die Quell-IP vor dem Routing noch nicht feststeht, kann der Verkehr anhand von Ziel-Ports oder Protokollen gesteuert werden (z. B. S3-Backups über das VPN leiten, regulären Webverkehr über WAN-1):

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    A["App S3-Backup-Verkehr<br/>TCP Port 9000"] --> B["nftables OUTPUT Hook<br/>Setzt fwmark 100"]
    B --> C["RPDB: fwmark 100<br/>lookup vpn_out"]
    C --> D["Tabelle vpn_out routet<br/>über wg0-Tunnel"]

1. Tabelle `vpn_out` befüllen

sudo ip route add default dev wg0 table vpn_out

2. `fwmark`-Regel zur RPDB hinzufügen

# Pakete mit der Markierung 100 (hex 0x64) nutzen Tabelle vpn_out
sudo ip rule add fwmark 100 table vpn_out priority 2000

3. Pakete in `nftables` markieren

Füge die Mangle-Regel in /etc/nftables.conf ein:

table inet pbr_mangle {
    chain output {
        type route hook output priority mangle; policy accept;

        # Markiert ausgehenden TCP-Verkehr an Port 9000 mit 100
        tcp dport 9000 meta mark set 100
    }
}

6. Persistente Konfiguration mit `systemd-networkd`

Befehle, die im Terminal direkt mit ip rule gesetzt werden, gehen bei einem Neustart verloren. Die dauerhafte Konfiguration erfolgt in /etc/systemd/network/:

# Datei: /etc/systemd/network/20-wan-isp2.network
[Match]
Name=eth1

[Network]
Address=198.51.100.20/24

# 1. Default-Route für Tabelle 201 (isp2) anlegen
[Route]
Gateway=198.51.100.1
Table=201

# 2. Richtlinie anlegen: Verkehr von dieser IP nutzt Tabelle 201
[RoutingPolicyRule]
From=198.51.100.20/32
Table=201
Priority=1000

Aktivieren:

sudo networkctl reload
ip rule show

7. Nächste Schritte

Nachdem der Datenverkehr über mehrere Routingtabellen und Richtlinien gesteuert werden kann, folgt die physische Bündelung und logische Segmentierung von Netzwerkkarten:

802.1Q VLAN-Trunks & 802.3ad LACP-Bonding

Netzwerkkarten im Aktiv-Aktiv-Verbund bündeln (LACP) und getrennte Sicherheitszonen über 802.1Q-VLANs isolieren.

Zum LACP- & VLAN-Leitfaden