Linux Advanced Routing Tutorial
Solving the DMZ Challenge
What we need now is to set up a special routing table for all DMZ traffic and create a rule that will plug it in to the routing decision process.
The first step is to create and populate the new table and name it "dmz". We can choose any non-reserved table ID and add one line into the rt_table file to map the ID to our desired name:
[router] ~ # echo "121 dmz" >> /etc/iproute2/rt_tables [router] ~ # ip route show table dmz [router] ~ #
The dmz table is empty for now. Let's populate it. Apparently, we need just the default route—everything should be sent to ISP1's gateway:
[router] ~ # ip route add default via 203.0.113.37 ↪dev vlan-shdsl table dmz [router] ~ # ip route show table dmz default via 203.0.113.37 dev vlan-shdsl
All we need to do now is activate the table by adding a lookup rule to the routing decision process. The lookup rules can be based on many different parameters—the source and/or destination address or address range, the incoming interface, the TOS (Type Of Service) or an arbitrary "fwmark" value that is used in conjunction with iptables rules. For our purpose, the source IP and incoming network interface are the "selectors" that we need:
[router] ~ # ip rule add pri 1000 from 203.0.113.208/28 ↪iif vlan-dmz lookup dmz [router] ~ # ip rule show 0: from all lookup local 1000: from 203.0.113.208/28 iif vlan-dmz lookup dmz 32766: from all lookup main 32767: from all lookup default
All the packets coming from interface vlan-dmz with source address 203.0.113.208/28 will consult the dmz table. And the dmz table says to send them all to the SHDSL link by default. Let's see if it works:
[dmz-box] ~ # traceroute 22.214.171.124 traceroute to 126.96.36.199 (188.8.131.52), 30 hops max, 60 byte packets 1 gw-dmz.e-it.co.nz (203.0.113.209) ↪0.200 ms 0.124 ms 0.110 ms 2 rt-shdsl.isp1 (203.0.113.37) 2.676 ms 2.599 ms 2.632 ms 3 rt3.isp1 (121.98.ab.cd) 2.715 ms 2.680 ms 2.591 ms [... some more hops ...] 10 216.239.xx.yy (216.239.xx.yy) ↪172.955 ms 172.398 ms 172.339 ms 11 * * * 12 google-public-dns-b.google.com (184.108.40.206) ↪171.703 ms 171.621 ms 170.554 ms
That looks good. The international traffic from the box in DMZ goes over the SHDSL link, while at the same time, we can re-check that from the workstation in the internal LAN, it still goes over ADSL:
[workstation] ~ # traceroute 220.127.116.11 traceroute to 18.104.22.168 (22.214.171.124), 30 hops max, ↪40 byte packets using UDP 1 gw-vlan-office.e-it.co.nz (192.168.130.1) ↪0.170 ms 0.128 ms 0.125 ms 2 gw-vlan-adsl.e-it.co.nz (192.168.128.254) ↪0.861 ms 0.846 ms 0.825 ms 3 core-adsl.isp2 (218.101.x.y) 22.718 ms 22.109 ms 21.931 ms 4 core-xyz.isp2 (203.98.x.y) 20.417 ms 20.222 ms 19.769 ms [... some more hops ...] 13 64.233.x.y (64.233.x.y) 198.456 ms 197.824 ms 197.189 ms 14 * * * 15 google-public-dns-b.google.com (126.96.36.199) ↪194.318 ms 194.153 ms 194.159 ms
Magic, isn't it! It all looks good, and we're done, right? Well, not quite.
More Work for DMZ Routing
What happens when pinging the DMZ box from my workstation? First, the ping packet goes from 192.168.130.100 to the router. The router consults the "main" routing table, sees that the destination 203.0.113.222 is on a directly connected vlan-dmz and sends the ping request there. The DMZ box replies with a packet from 203.0.113.222 to 192.168.130.100—that's my workstation on vlan-office—and sends it to the router. The router sees that it arrived from the DMZ address range and consults the "dmz" table! The only record in there is the default route, so it takes it and dispatches the packet with destination IP 192.168.130.100 to the ISP where it eventually gets discarded. Oops!
Figure 4. Broken Traffic between DMZ and the Office
There are a number of solutions. Either we can copy all the non-BGP routes from the "main" table to the "dmz" table—that's indeed possible but not very elegant. A better option is to add a new routing entry to the "dmz" table that, when matched, will make the kernel move on to the next rule on the list:
[router] ~ # ip rule show 0: from all lookup local 1000: from 203.0.113.208/28 iif vlan-dmz lookup dmz 32766: from all lookup main 32767: from all lookup default [router] ~ # ip route add throw 192.168.128.0/20 table dmz [router] ~ # ip route show table dmz throw 192.168.128.0/20 default via 203.0.113.37 dev vlan-shdsl
What happens now with the ping reply packet is this: the kernel sees a matching rule 1000 and looks up the "dmz" table. There it finds that the best matching route for a destination of 192.168.130.100 is "throw". That tells it to choose the next available rule—in our case, "32766: from all lookup main" and looks up the "main" table. Here it finds a path to the 192.168.130.0/24 subnet and sends the ping reply to vlan-office. Problem fixed.
Another way, equally as good if not even better, is to go straight to the "main" table for all packets that arrive from the DMZ and are destined for our company's internal address range. Let's add a rule for it:
[router] ~ # ip rule add pri 999 from 203.0.113.208/28 ↪iif vlan-dmz to 192.168.128.0/20 table main [router] ~ # ip rule show 0: from all lookup local 999: from 203.0.113.208/28 to 192.168.128.0/20 ↪iif vlan-dmz lookup main 1000: from 203.0.113.208/28 iif vlan-dmz lookup dmz 32766: from all lookup main 32767: from all lookup default
With this rule in place, the router will see that the ping reply packet matches the rule "from 203.0.113.208/28 to 192.168.128.0/20" and will look up the "main" table instead of the "dmz" table right away. Personally, I like this solution the most as it explicitly says "lookup main" instead of a more vague "go to the next rule", whatever it may be, that the former solution does.
Figure 5. DMZ traffic works as expected.
Making the Changes Permanent
Many of the changes we have done so far are only in the router's memory and will disappear after a reboot. Let's make them permanent. Our core router is CentOS 6.2, and the following steps should work on any recent Red Hat Enterprise Linux or Fedora-based system.
A permanent name already has been given to the "dmz" table:
[router] ~ # cat /etc/iproute2/rt_tables # reserved values 255 local 254 main 253 default 0 unspec # local 121 dmz
To add the new ip rules, edit the file /etc/sysconfig/network-scripts/rule-<interface>. As soon as the given interface is configured, the rules will be loaded. The logical place is to load our rules once the DMZ interface vlan-dmz is configured:
[router] ~ # cat /etc/sysconfig/network-scripts/rule-vlan-dmz # ip rule add ... pri 999 from 203.0.113.208/28 to 192.168.128.0/20 ↪iif vlan-dmz lookup main pri 1000 from 203.0.113.208/28 iif vlan-dmz lookup dmz
Finally, populate the "dmz" table on reboot. This is done in the route-<interface> file in the same directory:
[router] ~ # cat /etc/sysconfig/network-scripts/route-vlan-dmz # ip route add ... default via 203.0.113.37 dev vlan-shdsl table dmz # throw 192.168.128.0/20 table dmz ## unless the rule 999 is in place
That's it. The routing now works as designed and survives a reboot.
The topics I explained in this article—multiple routing tables, rules for selecting them and a hint of BGP—should give you enough knowledge to build moderately complex Linux-based routers. In this trade, you will come across a lot more concepts—from OSPF through firewalls and NATs to VPNs and high-availability networks. None of these topics are within the scope of this article; however, in the end, the core thing that makes all this networking fun possible is routing. If you learn the few simple concepts of how IP routing works, you will know half of what networking is all about. Happy experimenting!
Michal Ludvig works for Enterprise IT Ltd in New Zealand as a senior Linux engineer. He's got root access to some of the largest New Zealand corporations, but since he tends to forget his passwords, he is, in general, pretty harmless.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide