mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-12-30 23:48:09 +01:00
1130b656e5
This will make a number of things easier in the future, as well as (finally!) avoiding the Id-smashing problem which has plagued developers for so long. Boy, I'm glad we're not using sup anymore. This update would have been insane otherwise.
280 lines
12 KiB
Plaintext
280 lines
12 KiB
Plaintext
<!-- $FreeBSD$ -->
|
|
<!-- The FreeBSD Documentation Project -->
|
|
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
|
|
|
<sect><heading>Gateways and routes<label id="routing"></heading>
|
|
|
|
<p><em>Contributed by &a.gryphon;.<newline>6 October 1995.</em>
|
|
|
|
For one machine to be able to find another, there must be a
|
|
mechanism in place to describe how to get from one to the
|
|
other. This is called Routing. A ``route'' is a defined
|
|
pair of addresses: a <bf>destination</bf> and a
|
|
<bf>gateway</bf>. The pair indicates that if you are
|
|
trying to get to this <em>destination</em>, send along
|
|
through this <em>gateway</em>. There are three types of
|
|
destinations: individual hosts, subnets, and ``default''. The
|
|
``default route'' is used if none of the other routes
|
|
apply. We will talk a little bit more about default routes
|
|
later on. There are also three types of gateways:
|
|
individual hosts, interfaces (also called ``links''), and
|
|
ethernet hardware addresses.
|
|
|
|
<sect1><heading>An example</heading>
|
|
|
|
<p>To illustrate different aspects of routing, we will use
|
|
the following example which is the output of the command
|
|
<tt>netstat -r</tt>:
|
|
|
|
<tscreen><verb>
|
|
Destination Gateway Flags Refs Use Netif Expire
|
|
|
|
default outside-gw UGSc 37 418 ppp0
|
|
localhost localhost UH 0 181 lo0
|
|
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
|
|
10.20.30.255 link#1 UHLW 1 2421
|
|
foobar.com link#1 UC 0 0
|
|
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
|
|
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
|
|
host2.foobar.com link#1 UC 0 0
|
|
224 link#1 UC 0 0
|
|
</verb></tscreen>
|
|
|
|
The first two lines specify the default route (which we
|
|
will cover in the next section) and the <tt>localhost</tt> route.
|
|
|
|
The interface (<tt>Netif</tt> column) that it specifies to use
|
|
for <tt>localhost</tt> is <tt>lo0</tt>, also known as the
|
|
loopback device. This says to keep all traffic for this
|
|
destination internal, rather than sending it out over the
|
|
LAN, since it will only end up back where it started
|
|
anyway.
|
|
|
|
The next thing that stands out are the
|
|
``<tt>0:e0:...</tt>'' addresses. These are ethernet
|
|
hardware addresses. FreeBSD will automatically identify any
|
|
hosts (<tt>test0</tt> in the example) on the local ethernet and
|
|
add a route for that host, directly to it over the ethernet
|
|
interface, <tt>ed0</tt>. There is also a timeout
|
|
(<tt>Expire</tt> column) associated with this type of route,
|
|
which is used if we fail to hear from the host in a
|
|
specific amount of time. In this case the route will be
|
|
automatically deleted. These hosts are identified using a
|
|
mechanism known as RIP (Routing Information Protocol),
|
|
which figures out routes to local hosts based upon a
|
|
shortest path determination.
|
|
|
|
FreeBSD will also add subnet routes for the local subnet
|
|
(<tt>10.20.30.255</tt> is the broadcast address for the subnet
|
|
<tt>10.20.30</tt>, and <tt>foobar.com</tt> is the domain name
|
|
associated with that subnet). The designation <tt>link#1</tt>
|
|
refers to the first ethernet card in the machine. You will
|
|
notice no additional interface is specified for those.
|
|
|
|
Both of these groups (local network hosts and local
|
|
subnets) have their routes automatically configured by a
|
|
daemon called <tt>routed</tt>. If this is not run, then only
|
|
routes which are statically defined (ie. entered
|
|
explicitly) will exist.
|
|
|
|
The <tt>host1</tt> line refers to our host, which it knows by
|
|
ethernet address. Since we are the sending host, FreeBSD
|
|
knows to use the loopback interface (<tt>lo0</tt>) rather than
|
|
sending it out over the ethernet interface.
|
|
|
|
The two <tt>host2</tt> lines are an example of what happens
|
|
when we use an ifconfig alias (see the section of ethernet
|
|
for reasons why we would do this). The <tt>=></tt>
|
|
symbol after the <tt>lo0</tt> interface says that not only are
|
|
we using the loopback (since this is address also refers to
|
|
the local host), but specifically it is an alias. Such
|
|
routes only show up on the host that supports the alias;
|
|
all other hosts on the local network will simply have a
|
|
<tt>link#1</tt> line for such.
|
|
|
|
The final line (destination subnet <tt>224</tt>) deals with
|
|
MultiCasting, which will be covered in a another section.
|
|
|
|
The other column that we should talk about are the
|
|
<tt>Flags</tt>. Each route has different attributes that are
|
|
described in the column. Below is a short table of some of
|
|
these flags and their meanings:
|
|
|
|
<descrip>
|
|
|
|
<tag/U/ <bf/Up:/ The route is active.
|
|
|
|
<tag/H/ <bf/Host:/ The route destination is a single host.
|
|
|
|
<tag/G/ <bf/Gateway:/ Send anything for this destination
|
|
on to this remote system, which will figure out from
|
|
there where to send it.
|
|
|
|
<tag/S/ <bf/Static:/ This route was configured manually,
|
|
not automatically generated by the system.
|
|
|
|
<tag/C/ <bf/Clone:/ Generates a new route based upon this
|
|
route for machines we connect to. This type of route is
|
|
normally used for local networks.
|
|
|
|
<tag/W/ <bf/WasCloned/ Indicated a route that was
|
|
auto-configured based upon a local area network (Clone)
|
|
route.
|
|
|
|
<tag/L/ <bf/Link:/ Route involves references to ethernet
|
|
hardware.
|
|
|
|
</descrip>
|
|
|
|
|
|
<sect1><heading>Default routes</heading>
|
|
|
|
<p>When the local system needs to make a connection to
|
|
remote host, it checks the routing table to determine if
|
|
a known path exists. If the remote host falls into a
|
|
subnet that we know how to reach (Cloned routes), then
|
|
the system checks to see if it can connect along that
|
|
interface.
|
|
|
|
If all known paths fail, the system has one last option:
|
|
the <bf>default</bf> route. This route is a special type
|
|
of gateway route (usually the only one present in the
|
|
system), and is always marked with a ``<tt>c</tt>'' in
|
|
the flags field. For hosts on a local area network, this
|
|
gateway is set to whatever machine has a direct
|
|
connection to the outside world (whether via PPP link, or
|
|
your hardware device attached to a dedicated data line).
|
|
|
|
If you are configuring the default route for a machine
|
|
which itself is functioning as the gateway to the outside
|
|
world, then the default route will be the gateway machine
|
|
at your Internet Service Provider's (ISP) site.
|
|
|
|
Let us look at an example of default routes. This is a
|
|
common configuration:
|
|
<tscreen><verb>
|
|
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
|
|
</verb></tscreen>
|
|
|
|
The hosts <tt>Local1</tt> and <tt>Local2</tt> are at your
|
|
site, with the formed being your PPP connection to your
|
|
ISP's Terminal Server. Your ISP has a local network at
|
|
their site, which has, among other things, the server
|
|
where you connect and a hardware device (T1-GW) attached
|
|
to the ISP's Internet feed.
|
|
|
|
The default routes for each of your machines will be:
|
|
|
|
<tscreen><verb>
|
|
host default gateway interface
|
|
---- --------------- ---------
|
|
Local2 Local1 ethernet
|
|
Local1 T1-GW PPP
|
|
</verb></tscreen>
|
|
|
|
A common question is ``Why (or how) would we set the
|
|
T1-GW to be the default gateway for Local1, rather than
|
|
the ISP server it is connected to?''.
|
|
|
|
Remember, since the PPP interface is using an address on
|
|
the ISP's local network for your side of the connection,
|
|
routes for any other machines on the ISP's local network
|
|
will be automatically generated. Hence, you will already
|
|
know how to reach the T1-GW machine, so there is no need
|
|
for the intermediate step of sending traffic to the ISP
|
|
server.
|
|
|
|
As a final note, it is common to use the address ``<tt>...1</tt>''
|
|
as the gateway address for your local network. So (using
|
|
the same example), if your local class-C address space
|
|
was <tt>10.20.30</tt> and your ISP was using <tt>10.9.9</tt> then the
|
|
default routes would be:
|
|
|
|
<tscreen><verb>
|
|
Local2 (10.20.30.2) --> Local1 (10.20.30.1)
|
|
Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Dual homed hosts</heading>
|
|
|
|
<p>There is one other type of configuration that we should
|
|
cover, and that is a host that sits on two different
|
|
networks. Technically, any machine functioning as a
|
|
gateway (in the example above, using a PPP connection)
|
|
counts as a dual-homed host. But the term is really only
|
|
used to refer to a machine that sits on two local-area
|
|
networks.
|
|
|
|
In one case, the machine as two ethernet cards, each
|
|
having an address on the separate subnets. Alternately,
|
|
the machine may only have one ethernet card, and be using
|
|
ifconfig aliasing. The former is used if two physically
|
|
separate ethernet networks are in use, the latter if
|
|
there is one physical network segment, but two logically
|
|
separate subnets.
|
|
|
|
Either way, routing tables are set up so that each subnet
|
|
knows that this machine is the defined gateway (inbound
|
|
route) to the other subnet. This configuration, with the
|
|
machine acting as a Bridge between the two subnets, is
|
|
often used when we need to implement packet filtering or
|
|
firewall security in either or both directions.
|
|
|
|
<sect1><heading>Routing propagation</heading>
|
|
|
|
<p>We have already talked about how we define our routes to
|
|
the outside world, but not about how the outside world
|
|
finds us.
|
|
|
|
We already know that routing tables can be set up so that
|
|
all traffic for a particular address space (in our
|
|
examples, a class-C subnet) can be sent to a particular
|
|
host on that network, which will forward the packets
|
|
inbound.
|
|
|
|
When you get an address space assigned to your site, your
|
|
service provider will set up their routing tables so that
|
|
all traffic for your subnet will be sent down your PPP
|
|
link to your site. But how do sites across the country
|
|
know to send to your ISP?
|
|
|
|
There is a system (much like the distributed DNS
|
|
information) that keeps track of all assigned
|
|
address-spaces, and defines their point of connection to
|
|
the Internet Backbone. The ``Backbone'' are the main
|
|
trunk lines that carry Internet traffic across the
|
|
country, and around the world. Each backbone machine has
|
|
a copy of a master set of tables, which direct traffic
|
|
for a particular network to a specific backbone carrier,
|
|
and from there down the chain of service providers until
|
|
it reaches your network.
|
|
|
|
It is the task of your service provider to advertise to
|
|
the backbone sites that they are the point of connection
|
|
(and thus the path inward) for your site. This is known
|
|
as route propagation.
|
|
|
|
<!--
|
|
<sect1><heading>Multicast Routing</heading>
|
|
-->
|
|
|
|
<sect1><heading>Troubleshooting</heading>
|
|
|
|
<p>Sometimes, there is a problem with routing propagation,
|
|
and some sites are unable to connect to you. Perhaps the
|
|
most useful command for trying to figure out where a
|
|
routing is breaking down is the <tt>traceroute(8)</tt>
|
|
command. It is equally useful if you cannot seem to make
|
|
a connection to a remote machine (ie. <tt>ping(8)</tt>
|
|
fails).
|
|
|
|
The <tt>traceroute(8)</tt> command is run with the name
|
|
of the remote host you are trying to connect to. It will
|
|
show the gateway hosts along the path of the attempt,
|
|
eventually either reaching the target host, or
|
|
terminating because of a lack of connection.
|
|
|
|
For more information, see the manual page for
|
|
<tt>traceroute(8)</tt>.
|
|
|