Policy Based Routing - Versionsgeschichte

Gehrke: /* Beispielhafte Konfiguration - Unterschiedliches Routing für verschiedene Dienste */ interne Verlinkung

2013-11-23T16:06:03Z

‎Beispielhafte Konfiguration - Unterschiedliches Routing für verschiedene Dienste: interne Verlinkung

Yehudi: Policy Based Routing mit Linux wurde nach Policy Based Routing verschoben: Policy Based Routing - kurzen knappen Titel, wir befinden uns im Linux-Club, da geht es eh um Linux. ;-)

2007-06-10T20:18:09Z

Policy Based Routing mit Linux wurde nach Policy Based Routing verschoben: Policy Based Routing - kurzen knappen Titel, wir befinden uns im Linux-Club, da geht es eh um Linux. ;-)

Yehudi: /* Konfiguration von PBR unter Linux */ Das Bild sollte ein Link sein, es ist zu groß, und nacher bekommen wir auch Ärger.

2007-06-10T20:16:59Z

‎Konfiguration von PBR unter Linux: Das Bild sollte ein Link sein, es ist zu groß, und nacher bekommen wir auch Ärger.

Jengelh: alles mögliche

2007-06-10T20:07:53Z

alles mögliche

Änderungen zeigen

TomcatMJ: Wettbewerbsbaustein entfernt da die Gewinner feststehen

2007-06-10T16:18:28Z

Wettbewerbsbaustein entfernt da die Gewinner feststehen

Nbkr am 22. Mai 2007 um 17:33 Uhr

2007-05-22T17:33:51Z

Nbkr am 22. Mai 2007 um 09:30 Uhr

2007-05-22T09:30:51Z

Nbkr am 22. Mai 2007 um 05:57 Uhr

2007-05-22T05:57:50Z

Nbkr: /* Die Praxis */

2007-05-20T17:30:59Z

‎Die Praxis

Nbkr am 20. Mai 2007 um 17:29 Uhr

2007-05-20T17:29:41Z

@@ Zeile 174: / Zeile 174: @@
 Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet, d.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN-Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP-Adresse 10.0.0.10 über das Interface tun0 (tun0 ist das VPN-Interface) eingetragen.
-Da <code>ip rule add</code> keine Möglichkeit bietet, das TCP Destination Port Feld als Kriterium auszuwählen, kann man keine direkte Regel erzeugen. Stattdessen muss man mit iptables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:
+Da <code>ip rule add</code> keine Möglichkeit bietet, das TCP Destination Port Feld als Kriterium auszuwählen, kann man keine direkte Regel erzeugen. Stattdessen muss man mit [[iptables]] die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:
    iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2

@@ Zeile 43: / Zeile 43: @@
 Vorweg eine kurze Anmerkung. Ich verwende nachfolgend sowohl die Begriffe Router und Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist dies für das Policy Based Routing vorerst nicht von Interesse.
-Das klassische Destination-based Routing arbeitet folgendermaßen: Ein Datenpaket erreicht den Router/die Firewall und durchläuft erstmal die PREROUTING-Kette (in Netfilter heißen sie ''chain''s) des Firewallsystems (vergleiche: http://www.imagestream.com/~josh/PacketFlow-new.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PREROUTING-Kette steht die Routing-Entscheidung an, d.h. der Router muss nun entscheiden, ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traf der Router bisher anhand einer Tabelle, der sogenannten Routing-Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei eine klassische Routingtabelle, wie sie der (klassische) Befehl <code>route -n</code> liefert:
+Das klassische Destination-based Routing arbeitet folgendermaßen: Ein Datenpaket erreicht den Router/die Firewall und durchläuft erstmal die PREROUTING-Kette (in Netfilter heißen sie ''chain''s) des Firewallsystems (vergleiche: [http://www.imagestream.com/~josh/PacketFlow-new.png PacketFlow-new.png ]). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PREROUTING-Kette steht die Routing-Entscheidung an, d.h. der Router muss nun entscheiden, ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traf der Router bisher anhand einer Tabelle, der sogenannten Routing-Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei eine klassische Routingtabelle, wie sie der (klassische) Befehl <code>route -n</code> liefert:
    Ziel            Router          Genmask         Flags Metric Ref    Use Iface

← Nächstältere Version		Version vom 10. Juni 2007, 16:18 Uhr
Zeile 1:		Zeile 1:
−	~~{{Wettbewerb}}~~
−
	Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten also keine Fremdwörter für den Leser sein.		Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten also keine Fremdwörter für den Leser sein.

@@ Zeile 1: / Zeile 1: @@
 {{Wettbewerb}}
-Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.
+Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten also keine Fremdwörter für den Leser sein.
 == Was ist Policy Based Routing? ==
 Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
-zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.
+zu treffen. Dies unterscheidet sich stark von den bisher eingesetzten Routingmöglichkeiten, bei welchen ein Router nur an Hand des Zieles, eines Datenpaketes entscheidet, an welchen Next Hop das Paket weitergereicht wird.
-Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.
+Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtigt und dann entscheidet was der Next Hop für das Paket sein soll.
 Für Weiteres siehe Quelle [1].
@@ Zeile 16: / Zeile 16: @@
 ==== Ereichen des gleichen Ziels über zwei Verbindungen ====
-In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.
+In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welches zuverlässig, aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.
 Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.
@@ Zeile 23: / Zeile 23: @@
 Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.
-Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.
+Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden, ob dieses mit Vorgang behandelt wird oder nicht.
-Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.
+Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden, ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.
 ==== Sonstiges ====
@@ Zeile 43: / Zeile 43: @@
 Wie muss man sich das Policy Based Routing technisch vorstellen?
-Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.
+Vorweg eine kurze Anmerkung. Ich verwende nachfolgend sowohl die Begriffe Router und Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist dies für das Policy Based Routing vorerst nicht von Interesse.
-Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:
+Das klassische Destination-Based Routing arbeitet folgendermaßen: Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden, ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traf der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei eine klassische Routingtabelle:
    Ziel            Router          Genmask         Flags Metric Ref    Use Iface
@@ Zeile 54: / Zeile 54: @@
-Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.
+Das Policy Based Routing erweitert dieses Konzept nun folgendermaßen: Statt einer Routingtabelle gibt es gleich Mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann, was der Next Hop für ein bestimmtes Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen, in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.
 Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.
@@ Zeile 78: / Zeile 78: @@
 (Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)
-Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.
+Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen, wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutrifft, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zum nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.
-Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte  ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.
+Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "nummerischen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte  ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.
@@ Zeile 145: / Zeile 145: @@
-Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Folgendermaßen fügt man eine Route einer Tabelle zu.
+Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts, wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Folgendermaßen fügt man eine Route einer Tabelle zu:
    ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0
@@ Zeile 156: / Zeile 156: @@
     a.b.c.d via 192.168.1.1 dev ra0
-Übrigens sollte man sich beim Anlegen einer Router vertippt haben sollen kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:
+Übrigens sollte man sich beim Anlegen einer Route vertippt haben sollen, kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:
    ip route del a.b.c.d table 2 via 192.168.1.1 dev ra0
@@ Zeile 171: / Zeile 171: @@
 Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:
-Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Balast darstellt.
+Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man, dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Balast darstellt.
 Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0 (tun0 ist das VPN Interface).
@@ Zeile 203: / Zeile 203: @@
 Die zweite Zeile fügt der Tabelle 3 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d. an 10.0.0.10 über das Interface tun0 geschickt werden.
-Das war es war erreicht werden soll. Dank iptables und ip werden Pakete mit dem gleichen Ziel, aber unterschiedlichen Protokollen auch unterschiedlich geroutet. SMTP wird über die sichere VPN Verbindung geschickt, HTTPS über das normale Internet. Das alles ohne das die Clients im Netzwerk davon etwas mitbekommen.
+Das war es was erreicht werden soll. Dank iptables und ip werden Pakete mit dem gleichen Ziel, aber unterschiedlichen Protokollen auch unterschiedlich geroutet. SMTP wird über die sichere VPN Verbindung geschickt, HTTPS über das normale Internet. Das alles ohne das die Clients im Netzwerk davon etwas mitbekommen.
 == Abschlussbemerkung ==

@@ Zeile 217: / Zeile 217: @@
 # [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]
+----
 [[Netzwerk|zurück zum Netzwerk]][[Category:Netzwerkgrundlagen]]

← Nächstältere Version	Version vom 10. Juni 2007, 20:18 Uhr
(kein Unterschied)

← Nächstältere Version		Version vom 22. Mai 2007, 05:57 Uhr
Zeile 216:		Zeile 216:
	# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]		# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
	# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]		# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]
		+
		+
		+
		+	[[Netzwerk\|zurück zum Netzwerk]][[Category:Netzwerkgrundlagen]]

@@ Zeile 87: / Zeile 87: @@
 Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.
-==== Wie man Regeln anlegt ====
+==== Wie man Regeln und Routen anlegt ====
 Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:
@@ Zeile 167: / Zeile 167: @@
-==== Beispielhafte Konfiguration 1 - Unterschiedliches Routing für verschiedene Dienste ====
+==== Beispielhafte Konfiguration - Unterschiedliches Routing für verschiedene Dienste ====
 Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:
-Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Overhead darstellt.
+Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Balast darstellt.
-Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0.
+Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0 (tun0 ist das VPN Interface).
 Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

← Nächstältere Version		Version vom 20. Mai 2007, 17:29 Uhr
Zeile 1:		Zeile 1:
	{{Wettbewerb}}		{{Wettbewerb}}
−
−	~~{{UnderConstruction}}~~

	Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.		Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.