Thursday, March 5, 2015

Advanced Routing with RedHat 6

Have you ever run into this situation?  You have a RHEL server with two network connections (virtual or physical), one for primary traffic and one for management.  On two different VLANs with two different gateways.  You are also load balancing this host with an F5 or A10 device.  You NEED your primary traffic segregated and routed through a certain gateway.  You also NEED your management traffic segregated and routed through a different gateway.  Primary traffic will use Source Network Address Translation (SNAT) for logging and auditing at the load balancer.  The management network will use the default gateway for the VLAN it is on.  So, how do you do this at the server?

The solution is route and rule files in /etc/sysconfig/network-scripts.  Let's use eth0 and eth1 as our primary and management network interfaces respectively.

Create a routing file named route-eth0 in /etc/sysconfig/network-scripts/.  It  will consists of two lines.

10.10.17.0/24 dev eth0 table 200
default via 10.10.17.251 table 200

Let's break down the fields in each line.

10.10.17.0/24 dev eth0 table 200
VLAN/CIDR = 10.10.17.0/24   
device = dev
eth0 = as defined by OS/Vendor
table = for routing lookups
ID = unique table ID (arbitrary number, must be unique)   

default via 10.10.17.251 table 200
default gateway for this interface = default
via = through a specific router
Gateway IP = 10.10.17.251 (this is the default router for this VLAN - could be a firewall interface or load balancer.
table = for routing lookups
ID = unique table ID (arbitrary number, must be unique)

Create a rule file named rule-eth0 in /etc/sysconfig/network-scripts/

from 10.10.17.17/32 table 200
to 10.10.17.17 table 200

Let's break down the fields for the rule file next.

from 10.10.17.17/32 table 200
source = from network
IP/CIDR = IPADDR for eth0 10.10.17.17/32
table = for routing lookups
ID = unique table ID (arbitrary number, must be unique)

to 10.10.17.17 table 200
destination = to
IP = IPADDR for eth0 10.10.17.17
table = for routing lookups
ID = unique table ID (arbitrary number, must be unique)


The management device is on a different VLAN with a different default gateway.

route-eth1
10.10.0.0/24 dev eth1 table 203
default via 10.10.0.1 dev eth1 table 203

rule-eth1
from 10.10.0.3/32 table 203
to 10.10.0.3 table 203

Restart network services (during an approved maintenance window):

/sbin/service network restart

Verify with by looking at the routing table.

/sbin/route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0             10.10.0.1        0.0.0.0             UG    0          0        0    eth1

Notice the one and only gateway (UG) shown is actually for the management network.  The primary gateway isn't published with the route command. You'd have to know to look in /etc/sysconfig/network-scripts for specific routing files tied to eth0.

Discussion

All traffic destined for the primary interface will go through a specific router and will never mix with the management interface.  All management traffic goes through a different gateway and will also never mix with primary network traffic.  Traffic on both interfaces remain bi-directional through different gateways.  You might use the management network for system backups, logging or troubleshooting without any effect on primary traffic.

Security benefits

Segregation, one-way traffic configurations have often been a popular strategy to manage and shape traffic.  Especially when using such disparate networks with very different intentions.  This configuration works with iptables just as well.  Using a local firewall is still highly encouraged in addition to next generation firewalls.

Static Routes

What about using static routes?  Depending on your network this is an alternative to using specific route and rules files.  However, in this configuration adding ad GATEWAY or GATEWAYDEV to /etc/sysconfig/network of ifcfg-ethN files can cause loss of connectivity for the primary interface.  You don't want that.  That's why in this configuration we don't hard code or set GATEWAY information in global or interface files.  We utilize route-ethN files and let the kernel ensure traffic follows the rules you've created.


No comments:

Post a Comment