Routing fun?

Ben Scott dragonhawk at gmail.com
Fri Dec 28 12:03:31 EST 2012


On Fri, Dec 28, 2012 at 11:16 AM, Ken D'Ambrosio <ken at jots.org> wrote:
> I've got a device on
> my network that, for various reasons, I want to route only over an
> OpenVPN link.  All other devices go out normally.  Assuming my Linux box
> is doing the routing, and has the VPN link, how do I get it to do that
> for that one device's MAC/IP/whatever?

  One way to do this would be to have different routing tables on the
"special" device, and use a separate VPN gateway on your LAN.  This
would be the way it would have to be done before better ways came
along.  But there's a better way:

  Traditional IP routing looks only at the destination address.  You
need to use something Linux calls "routing policy".  It allows you to
create multiple routing tables, and then create rules which select a
routing table based on various other things, such as source address.

GENERAL ALGORITHM

Routing tables are chosen using rules
Rules have a preference number
Lower numbered rules are tried first
If a rule matches, the specified routing table is tried:
  If a matching entry in that routing table is found
    Done, route the packet with that entry
  If no route in a table matches, return to rules list and keep looking
  A routing table entry can explicitly say "no route", that counts
  A default route matches everything
    So a table with a default route will always route the packet
If no routing table has a matching route, there is no route to the destination
If no rules match, no tables get tried, so again no route to destination

CONFIGURATION EXAMPLE

  For illustration purposes, let us suppose:

* Your home network is 192.168.0.0/24
* Your Linux router is 192.168.10.1 on your home net
* The special node on your home net is 192.168.10.42
* Your internal VPN gateway (tun adapter) is 10.0.20.1
* Your upstream gateway (ISP router) is 203.0.113.1

  Add the following entries to your /etc/iproute2/rt_tables file:

	11	ISP
	12	VPN

  Arrange to have the following commands run at startup:

	ip rule add pref 100 from 0/0 table main
	ip rule add pref 200 from 192.168.10.42 table VPN
	ip rule add pref 210 from 0/0 table ISP

	ip route add default via 203.0.113.1 table ISP
	ip route add default via 10.0.20.1 table VPN

  Do *not* define a default gateway in the main table.  In particular,
do *not* use any distro-provided configuration automation which
associates your default gateway with a particular network interface.

  If your ISP gives you dynamic address via DHCP, you'll have to
script something to handle the changing gateway.  dhcpcd provides
hooks for this.

THEORY OF OPERATION FOR CONFIGURATION EXAMPLE

  Routes within routing tables are processed "best match wins", same
as ever, but rules to select the table to use are processed with lower
preference values first.

  The "main" table is the default (the "default" table is not the
default; this is confusing).  Once consequence of that is that when an
interface is brought up, the route to the directly-connected network
is placed into the "main" table automatically.  We want to preserve
that functionality.    So we don't put our default routes in the
"main" table.

  By default, there is a rule which puts the "main" table at
preference 32766.   That doesn't allow us any room to insert more
rules.  So we add a new rule to call the "main" table early, at
preference 100.  (Our other rules should cover all possible packets,
so the preference 32766 rule will never get used, but even if it did,
it would be harmless.)

  We create two special tables, one for the VPN as default gateway,
one for the ISP as default gateway.  We use a rule to match your
special node and select the "VPN" table for that.  Everything else
(0/0) uses the "ISP" table, which has a default route to the public
Internet.

  Any other routes should prolly go in the "main" table.

CONFIGURATION SOURCES

  Systems derived from Red Hat can use files in
/etc/sysconfig/network-scripts/ to define these.  Specifically,
rule-$IFACE and route-$IFACE files.

  I don't know what systems derived from Debian do for this, if anything.

-- Ben


More information about the gnhlug-discuss mailing list