Home > Articles > Operating Systems, Server

  • Print
  • + Share This
This chapter is from the book

6.2 Cesium's Environment

Let's get back to our Ethernet/token ring gateways and take a look at what we need to build to get our workstations talking to the rest of the network. The basic topology is depicted in Figure 6.1. So at first glance it seems all we need to do is assign addresses to our token ring cards, pick a private subnet for our Ethernet segments, and configure IP forwarding. But recall that the token ring network was built for individual clients, and we're not going to be able to get traffic from the token ring side forwarded via cesium. In fact, because the token ring segments are set up for DHCP, we cannot even get a fixed IP address for cesium! So any traJc exiting the Ethernet segments will have to be marked with the IP address of tr0 so that the reply will find its way back. In other words, we're masquerading again.

Figure 6.1Figure 6.1 Cesium/Xenom Network Topology

To complicate matters, the RFC 1918 address space has been assigned for use to other systems within the corporation and is routable across the WAN (don't laugh—this is a true story). So we shouldn't pick this address space for our private segments because we can't be sure that we won't need to route to 192.168.0.0/16 some day to access resources on the network. Now what? Well, in a way, I cheated. I took a handful of class C subnets from Internet valid address space and used them. This was safe for the following reasons: access to the real outside, the Internet, was via proxies, so the workstations would not need to access that address space in any context other than the local usage; the workstation IPs would be masqueraded by the token ring gateways, so there wasn't any danger of their freaking out any internal (but external to us) routers or traJc monitors; and finally, I happened to know that the Internet valid IPs were sitting behind a firewall on the other side of the planet (which is largely irrelevant). Anyway, that's where the address space comes from, although I'll be using RFC 1918 address space for all the example addresses in this chapter.

Now, what if a workstation on Ethernet segmentA would like to connect to a workstation on Ethernet segmentB? Can't we just add a route to cesium that forwards all packets for segmentB to xenon? As tempting as this is, the answer is no. Cesium and xenon are separated

by a router (and therefore aren't on the same subnet), and you cannot specify a route that uses a gateway remote to the segment you're on. Think about it for a moment, and you'll realize that there aren't enough address fields in a normal IP packet to do this. Well, strictly speaking, the prior statement is not true. This is possible with source routing, a feature of IP that allows the sender to specify the network path to take to the destination. Source routing, though, is Evil because it can be used in all kinds of spoofing attacks and therefore is typically disabled. We're certainly not going to count on its being available to us for passing traJc between cesium and xenon. By the way, don't confuse source routing with source-based routing. The latter refers to the practice of taking the source address into consideration before forwarding a packet and can be used to provide diNerentiated levels of service to clients based on the IP address of the sender.

Hint: Disabling Source Routing on Linux

If youÕd like to make sure that your Linux router will not be party to an attack that utilizes source routing, make sure that the feature is disabled (it is by default) by checking the value of:

/proc/sys/net/ipv4/conf/interface/accept_source_route

where interface represents the network interface which should not accept source routes.Bet ter yet, use the interface all to disable this feature for all interfaces on the system. As with other files in /proc, 0 means off/disabled, and 1 means on/enabled.

I hope you'll discover that the primary reason to have Linux in your network is for its flexibility, not its low cost. The cost is just icing on the cake. Good technicians demand good tools, which is how I explain the growth and long-standing popularity of the GNU toolset. Integral to flexibility are choices, and Linux often oNers you choices about how to complete a task so that you can select what suits you best. In that vein we head into the next section, which introduces us to the iproute2 toolset.

  • + Share This
  • 🔖 Save To Your Account