RSS-Feed anzeigen

jahlives

Policy Based Routing aka Source Based Routing

Bewerten
Policy based Routing (PBR) oder auch Source Based Routing ermöglicht es Routing Entscheidungen aufgrund unterschiedlicher Kriterien zu treffen. Das "normale" Routing ist ein reines Destination Based Routing (DBR) d.h. die Routingentscheidung wird ausschliesslich auf Basis des Ziel eines Pakets getroffen. Das mag für den 0815-Homeuser genügen. Aber sobald das Netzwerksetup etwas komplexer wird, wird es ohne PBR irgendwann zu asymetrischem Routing führen und das gibt Probleme, sobald Router oder Firewalls involviert sind. Ein häufiges Einsatzgebiet für PBR ist wenn ein System Interfaces in mehreren Subnetzen hat. Sobald Traffic von einem nicht an den Interfaces anliegenden Subnetz kommt, muss der Kernel die Antworten entsprechend routen können.
Folgend mal ein Bildchen für ein Netzwerksetup wo PBR nötig sein kann

Auswahl_134.jpg

Dieser Server ist also mit 3 Interfaces ins Netz verbunden. Jedes Subnetz hat einen eigenen Gateway (Router).
Die entsprechenden Subnetze sind 192.168.199.0/25, 192.168.199.128/25 und 10.66.100.128/25. Die default Route geht via gw3
Solange der Traffic von einem bekannten Netz (192.168.199.0/25, 192.168.199.128/25 oder 10.66.100.128/25) kommt ist es unproblematisch, weil dies durch die Interface Routen anliegenden Subnetzes gehandhabt wird.
Kommt der Traffic von einem unbekannten Subnetz (z.B. 10.66.100.0/25), aber über gw3, dann ist das auch kein Problem, weil hier dann die default Route zum Zuge kommt.

Problematisch wird es erst wenn der Traffic des unbekannten Subnetzes (z.B. 10.66.100.0/25) via gw1 oder gw2 reinkommt.
Dann würde ohne PBR die Default Route zum Tragen kommen und das würde dann asymetrischen Traffic erzeugen.
Natürlich könnte man eine statische Route für das Netz anlegen.
Das geht aber nur dann sinnvoll, wenn der Traffic des fraglichen Netzes (10.66.100.0/25) immer via denselben Gateway (z.B. gw2) reinkommt.

In dem Fall würde folgendes reichen
Code:
ip route add -net 10.66.100.0/25 via 192.168.199.129
Kann der Traffic aber von allen Gateways kommen geht reines DBR nicht mehr. Denn die statische Route würde wiederum asymetrischen Traffic erzeugen.
Darum braucht man dann PBR, um sicherzustellen, dass das Ausgangsinterface immer gleich dem Eingangsinterface ist.

Also bedient man sich der Möglichkeit aktueller Kernel verschiedene Routing Tabellen zu haben und je nach Kriterium eine entsprechende Tabelle auf ein Paket anzuwenden.
Dazu verwendet man iproute2 und dessen Möglichkeiten. Die folgende Beschreibung ist für ein Linux System (v.a. die Pfade der Konfigs können bei der Syno unterschiedlich sein). Das Prinzip ist aber auch bei der Syno dasselbe.
Als erstes gibt man dem System bekannt, welche zusätzlichen Tabellen man nutzen möchte.
Code:
#/etc/iproute2/rt_tables
201    eth0
202    eth1
203    eth2
die erste Spalte legt die Priorität fest und die zweite definiert den Namen der Tabelle.
In den meisten Fällen wäre die Tabelle für eth2 eigentlich unnötig, weil hier ja die default Route greifen würde.
Wenn man aber ein Zielnetz hat, das an eth2 nicht via default GW gehen soll, braucht man auch diese. Drum der Vollständigkeit halber alle drei ;-)

Dann erstellt man die Regeln, welche festlegen nach welchem Kriterium eine bestimmte Tabelle verwendet werden soll. Wir machen es hier an der SRC Adresse eines Antwortpaketes fest
Code:
ip rule add from 192.168.199.52 table eth0 priority 201
ip rule add from 192.168.199.141 table eth1 priority 202
ip rule add from 10.66.100.186 table eth2 priority 203
Nun befüllen wir die entsprechenden Tabellen mit den passenden Regeln.
Zuerst die default Gateways der entsprechenden Tabellen
Code:
ip route add default table eth0 via 192.168.199.1 metric 500
ip route add default table eth1 via 192.168.199.129 metric 500
ip route add default table eth2 via 10.66.100.129 metric 500
Wer sich fragt, wieso eth2 auch einen def GW haben muss, hier die Antwort: sobald ein Paket durch eine eigene Routingtabelle geht werden die globalen Routen komplett ignoriert d.h.geht ein Paket durch Tabelle eth2 und dort steht kein default GW dann kann das Paket nicht geroutet werden. Das gilt übrigens auch für Netzwerke welche direkt am fraglichen Interface (eth2) anliegen. Dazu gleich mehr
Code:
ip route add 192.168.199.0/25 dev eth0 table eth0 metric 0
ip route add 192.168.199.128/25 dev eth1 table eth1 metric 0
ip route add 10.66.100.128/25 dev eth2 table eth2 metric 0
diese obigen Netzwerkrouten sind wichtig und werden gerne vergessen. Wie oben erwähnt werden keine Systemrouten angewendet sobald eine eigene Tabelle involviert ist.
Ohne diese Netzwerkrouten würde das Routing der Tabellen dann dazu führen, dass Traffic für direkt anliegende Netze via den def GW der Tabelle gehen.
Sprich ein Paket von 192.168.199.2 auf eth0 würde via 192.168.199.1 (def GW) retourniert werden und das mag keine Firewall und kein Router :-)
Man muss also in der Tabelle neben dem default GW auch das entsprechende Netz bekannt machen!

Wie weiter oben erwähnt ist die Tabelle für eth2 eigentlich unnötig, da hier die Systemrouten (default und Netzwerk) greifen. Damit wir diese Tabelle aber nicht umsonst angelegt haben nachfolgend ein Beispiel wo man es braucht. Sagen wir das SRC Netz 10.66.100.0/25 ist für eth2 nicht auf dem default GW des Systems erreichbar, sondern über den Gateway 10.66.100.155
Code:
ip route add 10.66.100.0/25 table eth2 via 10.66.100.155 metric 499
die metric muss in diesem Fall kleiner sein, als die Metric der default Route der Tabelle. Sonst kommt zuerst die default Route zum Zug.

Kommentare

  1. Avatar von Falkenfelser
    Danke für diesen Beitrag.
    Das hat meinem Arbeitskollegen sehr geholfen.