Local Service Segregation
Local Service Segregation
An address defines a set of services. This simple statement provides a powerful tool that can define how any system on a network is viewed . In the one extreme a system may be invisible because it provides no services. In the other it may be seen to contain the network.
Consider a system with perhaps just one or two services. If you assign multiple addresses to this system, in what way are the services defined to the system? This raises the question of how the actual implementations of both services and addresses are performed by a Policy Routing structure.
Within Policy Routing, an address does not define any particular physical device. While traditional practice is to always assign an address to a device, there is no requirement. What happens if an address is defined not to a particular hardware interface but to a virtual interface defined only in software? More precisely, what should happen?
With these questions scrolling through your mind you decide to set up a little testing environment and see what happens when these and other questions are implemented. Your setup consists of a machine you call net1, which connects to Network A. A full Policy Routing “compliant system you call router1 is connected between this network and another network, Network B. host1 and host2 reside on Network B. You have an independent machine running Ethereal or any other packet capture utility you are familiar with that is connected to both networks so that you can see the details of the packets themselves . This setup is illustrated in Figure 6.1.
Figure 6.1. Policy Routing testing network.
This is the testing environment you will use throughout this chapter as you explore advanced Policy Routing topics. The setup is quite flexible and can be added to easily.
Example 6.1 ”The Art of Ping
To start your testing you set up the testing environment with the following addressing:
net1 192.168.1.1/24 router1 192.168.1.254/24 10.1.1.1/24 host1 10.1.1.2/24 host2 10.1.1.3/24
This setup defines Network A as 192.168.1.0/24 and Network B as 10.1.1.0/24. The two host machines have their default routes pointing at router1. The net1 machine only has a network route for 10.1.1.0/24 pointing at router1. And router1 has no default route set.
Under this setup, you can ping from net1 to all three devices, router1, host1, and host2. On the packet capture you can see that the arps are correctly answered on both sides of router1. This is traditional standard networking.
Now you want to see what happens if you start adding addresses to router1. First you try adding addresses to the physical interfaces on router1. You add 172.16.1.254/16 to the Network B interface of router1. Then you try pinging this interface from host1 and verify that is does respond. So router1 is routing between the two addresses on the single interface.
Now you decide to use a virtual interface on router1 to perform the same test. Looking through the list of available interfaces you decide to try the dummy interface set. On the system is a dummy0 interface, which looks like the following:
[root@router1 /root]# ip link ls dev dummy0 5: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff Now you delete the 172.16.1.254/24 address from the Network B interface and add it to the dummy interface. Then you set the dummy interface active. Now your dummy0 interface looks as follows :
[root@router1 /root]# ip addr ls dev dummy0 5: dummy0: <BROADCAST,NOARP,UP> mtu 1500 qdisc noqueue link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet 172.16.1.254/24 scope global dummy0 inet6 fe80::200:ff:fe00:0/10 scope link Finally you try pinging this address from host1. The ping output looks exactly like the output from when you had assigned the address to the physical device interface. Now you see that the address is truly independent of the physical devices.
Curious, you look at the routing table on router1 to see if there is anything different about this setup:
[root@router1 /root]# ip route 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 172.16.1.0/24 dev dummy0 proto kernel scope link src 172.16.1.254 10.1.1.0/24 dev eth1 proto kernel scope link src 10.1.1.254 Everything looks perfectly normal. Just for grins you try pinging 172.16.1.254 from the net1 machine. And you get the connect: Network is unreachable message response from net1. Of course, net1 only has a route to the 10.1.1.0/24 network via router1 and has no route to the 172.16.1.0/24 network, thus the ping packets never go anywhere .
Example 6.2 ”Loopback Dummy
You think some more about how router1 can respond to the ping for 172.16.1.254 when the interface that contains the address is internal to the system itself. Indeed, you wonder how router1 responds to any type of ping. This leads to considering again how the Routing Policy Database (RPDB) works in this situation.
Considering how the system is responding you determine that since the address belongs to the system, then the system responds due to ownership. This is true for any address owned by the system. The response follows the output procedures as specified through the RPDB. To consider the simple one-packet ping from host1 to router1 for the 172.16.1.254 address, you have the following simplified steps:
-
host1 checks its routing table and determines that it has no specific route to 172.16.1.254. Thus, it should send the packet to the default gateway, router1.
-
router1 receives the packet and determines that it owns the 172.16.1.254 address and so it should respond.
-
router1 consults its RPDB to determine the method of response. Since in this case there is a route with a provided source address it uses the src address to respond. Additionally, there is no defined route response so router1 responds using the local table route to host1.
-
host1 receives the response coded with the 172.16.1.254 source address.
Now statement 3 is deliberate in scope. The tangled logic is best illustrated by going through the following example. You really need to pay careful attention to the details to understand how the responses are generated.
First, you delete all addresses from dummy0 on router1 using the flush command, ip addr flush dev dummy0 . Then you add back in the address to dev dummy0 using the host mask to prevent auto-route creation, ip addr add 172.16.1.254/32 dev dummy0 . You then test this setup by pinging the address from host1 and note that you get a response.
Now you look at the routing table on router1. The route to 172.16.1.254 is coded only in the local table. This is as it should be because the local table contains all broadcast and interface routes. You note that this is the only location for this route.
You create a table called table2, which refers to routing table 2, by adding a line to /etc/iproute2/rt_tables . Then you add a default route through net1 to table2, which specifies using the src of 172.16.1.254, ip route add default via 192.168.1.1 src 172.16.1.254 table table2 .
So far you are not using this table, so a ping from host1 will still get a response. To use the table you create a rule. This rule is different and explained in just a bit:
ip rule add from 172.16.1.254 dev lo table 2 prio 2000 To ensure that this rule is used by the system immediately, you issue the route cache flush, ip route flush cache .
Fire up the Ethereal capture on Network A and ping from host1 to 172.16.1.254. The capture looks like the following:
172.16.1.254 -> host2 ICMP Echo (ping) reply 172.16.1.254 -> host2 ICMP Echo (ping) reply 172.16.1.254 -> host2 ICMP Echo (ping) reply 172.16.1.254 -> host2 ICMP Echo (ping) reply
Note that you are listening on Network A, not on Network B where the ping originated from. The response packet was exactly as you suspected but sent to a different network. This is why the format of the rule statement is very important.
You dissect the rule statement by considering the actions in order. First, the rule is added with a from clause that specifies the address you added to dev dummy0 , 172.16.1.254. This rule will look at all packets with source address 172.16.1.254. There is an additional qualifier, dev lo , that states that the interface through which the packet is originated must be lo , the loopback interface. But the interface to which the packet was supposedly destined and replied from is dummy0 . This is the strange part.
You wonder if maybe this is due to dev dummy0 being somehow different from the physical interfaces. So you try the same sequence only this time you add the address to dev eth1 , which is the Network B interface. All the rest of the commands are the same. And now when you ping, you get the same result.
What you see is that an address exists only to define a service ”just as required by the tenets of Policy Routing. Yes, it seems weird to consider that an address assigned to a physical interface can be routed back through a different interface, but the really weird part is even thinking that the address is "assigned" to the interface.
At first glance this may seem to be a convoluted and theoretical example, but think back to "loopy" routing and consider the following setup.
Example 6.3 ”Reality Is Loopy
You have a Policy Routing firewall system, router1, similar to Example 5.6, "Troubleshooting Unbalanced Multiple Loop Routes," from Chapter 5, "Simple Network Examples." This system has three different interfaces defined on the system, as illustrated in Figure 6.2. The first interface, eth0 , is connected to Network A, a legal IP network (real Internet routable addressing), provided through a 256K Frame connection. The second interface, eth1 , is connected to Network B, which has a connection to the Internet through a full T1 frame. The third interface, sat0 is connected to a high downlink speed satellite connection, which has a 64Kbps uplink and a 3Mbps downlink. The addressing is similar to the following (substituting private addresses):
Figure 6.2. Reality is loopy.
eth0 192.168.1.254/24 gateway from Inet = 192.168.1.253/24 eth1 172.16.1.1/30 gateway to Inet = 172.16.1.2/30 sat0 10.1.1.1/30 gateway from/to Inet = 10.1.1.2/30
What you have is all of your Internet accessible devices on network 192.168.1.0/24. The default route for those devices is the router1 eth0 interface, 192.168.1.254. The uplink to the Internet for these devices is 172.16.1.2. This is so far just a simple example of asymmetrical routing.
The router1 is also running named for DNS. This is a service being provided by router1 on all of its interfaces. Recalling how the outputs are seen from Example 6.2, you would think that there is only one way that the DNS server could be located. But you want DNS queries coming in the link from ISP #1, who provides the 256K link to go back out the 256K link with the address of eth0 . Also, you want the DNS queries coming in from the link to ISP #2, the T1 provider, to return out that link with the address from eth1 . Finally, you want DNS queries from the satellite link to go out the link to ISP #2 but using the sat0 address as source. Using the constructs from Example 6.2, this is easy.
You create a setup to handle these requirements. First you define three routing tables in /etc/iproute2/rt_tables . These are DMZ, Inet, and Sat. In each of these tables you place the following routes:
ip route add default via 192.168.1.253 table DMZ src 192.168.1.254 ip route add default via 172.16.1.2 table Inet src 172.16.1.1 ip route add default via 172.16.1.2 table Sat src 10.1.1.1
Now you define the rules to interact with these route tables. Note that in this case you only need deal with the source address because the incoming packet would already have been routed to the system.
ip rule add from 192.168.1.254 dev lo table DMZ prio 15000 ip rule add from 172.16.1.1 dev lo table Inet prio 15100 ip rule add from 10.1.1.1 dev lo table Sat prio 15200
Now you have your loopy routing and you get to DNS too.
All of these setups rely on the provision of addresses as independent from any physical definition. The address merely defines the location of a service.
| Top |
