Differences between version 4 and predecessor to the previous major change of SourceBasedRouting.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Monday, December 12, 2005 6:35:01 pm | by TimCareySmith | Revert |
| Older page: | version 3 | Last edited on Wednesday, October 27, 2004 5:10:51 pm | by PerryLorier | Revert |
@@ -3,30 +3,34 @@
On standard Internet systems, when you receive a packet and decide where to route it to, that decision is made only based on the ''destination'' of the packet.
For example:
+<verbatim>
crb@firewall:~$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
203.167.218.65 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 203.167.218.65 0.0.0.0 UG 0 0 0 ppp0
+</verbatim>
In this, a simple routing table for a firewall, all traffic for 192.168.0.0/24 is routed out eth1; traffic for 10.7.0.0/24 is routed out eth0; and everything else is routed out ppp0 to the Internet.
However, let's deal with the situation where we have two interfaces ppp0 and ppp1 (a dual-homed situation, with two internet providers.) We will call the IP address on ppp0 $P0 and on ppp1, $P1.
You end up with a routing table that looks like this:
+<verbatim>
crb@firewall:~$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
219.88.160.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1
203.167.218.65 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 203.167.218.65 0.0.0.0 UG 0 0 0 ppp0
+</verbatim>
If you get traffic for your machine come into ppp1 from $OUTSIDE, the machine will receive the packets, generate a reply, and the system will now have a packet from $P1, destined to $OUTSIDE. Because the system __only looks at destination IP addresses__, the packet will get routed out the default gateway, ppp0. Even if you disable ReversePathFiltering to allow this kind of traffic on all your interfaces, chances are high your ISP will be using it. (For example, TelstraClear does not allow any traffic on it's network that originates from another network's IP.)
So, this is where __source based routing__ comes in. We need to take any traffic that originates from $P1 (replies to traffic that came __in__ ppp1), and route it back out through ppp1.
@@ -34,30 +38,95 @@
To do this we need to have the __iproute2__ package, which provides the command /sbin/ip; giving you much finer grained control over routing. If you don't have the /sbin/ip command, install an iproute package (debian: apt-get install iproute). The command ''route'' cannot handle multiple routing tables.
You also need to have a couple of kernel options enabled: they are CONFIG_IP_ADVANCED_ROUTER (Networking/IP: Advanced Router) and CONFIG_IP_MULTIPLE_TABLES (Networking/IP: policy routing).
-Then, what you do is you create another routing table by editing /etc/iproute2/rt_tables; in my example I wish to create routes for a jetstream connection, so I have called the table 'jetstream' [
1]
by adding the line
+Then, what you do is you create another routing table by editing /etc/iproute2/rt_tables; in my example I wish to create routes for a jetstream connection, so I have called the table 'jetstream' <footnote
1>
by adding the line
+<verbatim>
100 jetstream
+</verbatim>
Now, you can create a __rule__ that dictates what routing __table__ to look at.
+<verbatim>
ip rule add __from $P1__ table jetstream
+</verbatim>
Look at the rules with ''ip rule list'' to get an idea of what happens when a packet is to be routed. The important bit is the from $P1. If you forget it, depending at the priority of your table, you could send all traffic to that table by default. Now, when routing, a packet that comes from the IP address $P1 will be passed to the routing table 'jetstream' instead of the main routing table.
Populate this table with a new default route, and simple routes for the rest of your local interfaces:
+<verbatim>
ip route add 10.7.0.0/24 dev eth0 table jetstream
ip route add 192.168.1.0/24 dev eth1 table jetstream
ip route add 127.0.0.0/8 dev lo table jetstream
ip route add default via 219.88.160.1 table jetstream
+</verbatim>
And you're done. In my case, I'm doing this on a ppp interface, so I only need the routes to exist when the interface is up; I've therefore added scripts for this to /etc/ppp/ip-up.d/ (ip-down.d contains ip rule del; I leave the table there - it's no harm if it's not called, but you could remove it with ip route del).
Thanks to PerryLorier for explaining this all to me, and to the [Linux Advanced Routing and Traffic Control HOWTO|http://lartc.org] for filling in the detail; specifically [Routing for multiple uplinks/providers|http://lartc.org/howto/lartc.rpdb.multiple-links.html].
----
-[1] It's added at priority
100 so that you can add other tables either side of it later if you want.
+!!! Dual-Homed Setup using a single interface
+
+In the situation where you want to have a network where you have multiple routes out to the
[Internet], but want to be able to determine the path of traffic not at the edge, but at the local box.
+
+To do this, assign the local box two IP addresses in the local subnet.
+<verbatim>
+ whisky:~# ip addr add 192.168.
1.105/24 brd 192.168.1.255 dev eth0
+ whisky:~# ip -4 addr list dev eth0
+ 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
+ inet 192.168.1.104/24 brd 192.168.1.255 scope global eth0
+ inet 192.168.1.105/24 brd 192.168.1.255 scope global secondary eth0
+</verbatim>
+
+Now add a rule in the [RPDB
];
+<verbatim>
+ whisky:~# ip rule add prio 200 from 192.168.1.105 lookup ORCON
+ whisky:~# ip rule
+ : from all lookup local
+ 200: from 192.168.1.105 lookup ORCON --- Footnote 2
+ 32766: from all lookup main
+ 32767: from all lookup default
+</verbatim>
+
+Now all packets with a source IP address of 192.168.1.105 will use the ORCON routing table and other packets will use the 'main' routing table.
+
+<verbatim>
+ whisky:~# ip ro list table main
+ 192.168.1./24 dev eth0 proto kernel scope link src 192.168.1.104
+ default via 192.168.1.254 dev eth0
+ whisky:~# ip ro list table ORCON
+ 192.168.1./24 dev eth0 scope link src 192.168.1.105
+ default via 192.168.1.253 dev eth0 src 192.168.1.105
+</verbatim>
+
+Now, if you have a program which does not allow you to set a bind IP address which it will use for connections, you can use the iptables mangle table to MARK the packets you wish to route differently.
+
+I will be doing this for a specific uid, so that all locally-generated traffic owned by the uid:1004 will be routed out through 192.168.1.253.
+
+Firstly, create a rule in the OUTPUT chain of the mangle table:
+<verbatim>
+ whisky:~# iptables -A OUTPUT -o eth0 -m owner --uid-owner 1004 -j MARK --set-mark 0x1
+</verbatim>
+
+Secondly, create a rule in the RPDB specifying that packets MARKed 0x1 should use the ORCON routing table.
+<verbatim>
+ whisky:~# ip rule add prio 199 fwmark 0x1 lookup ORCON
+</verbatim>
+
+You can use any iptables match (within reason) to modify the routing table which will be used.
+Anything which will not match every single packet in a connection will not work and will break the end-to-end nature of TCP.
+
+----
+
+1 -
It's added at entry
100 so that you can add other tables either side of it later if you want.
+This isn't a priority. The only value which affects packets which match multiple rules is the prio, as in:
+<verbatim>
+ ip rule add prio __300__ from $IP lookup $TABLE
+</verbatim>
+
+2 - I have added a line in /etc/iproute2/rt_tables containing '100 ORCON'
CategoryNetworking
