Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

6.5. IP Configuration Options

IPCP is used to negotiate a number of
IP parameters at link configuration time. Usually, each peer sends an
IPCP configuration request packet, indicating which values it wants
to change from the defaults and the new value. Upon receipt, the
remote end inspects each option in turn and either acknowledges or
rejects it.

pppd gives you a lot of control over which
IPCP options it will try to negotiate. You can tune it through
various command-line options that we will discuss in this section.

6.5.1. Choosing IP Addresses

All IP
interfaces require that IP addresses be assigned to them; a PPP
device always has an IP address. The PPP suite of protocols provides
a mechanism that allows the automatic assignment of IP addresses to
PPP interfaces. It is possible for the PPP program at one end of a
point-to-point link to assign an IP address for the remote end to
use, or each may use its own.

Some PPP servers that handle a lot of
client sites assign addresses dynamically; addresses are assigned to
systems only when calling in and are reclaimed after they have logged
off again. This allows the number of IP addresses required to be
limited to the number of dial-up lines. While limitation is
convenient for managers of the PPP dial-up server, it is often less
convenient for users who are dialing in. We discussed the way that
hostnames are mapped to IP addresses by use of a database in Chapter 5. In order for people to connect to your
host, they must know your IP address or the hostname associated with
it. If you are a user of a PPP service that assigns you an IP address
dynamically, this knowledge is difficult without providing some means
of allowing the DNS database to be updated after you are assigned an
IP address. Such systems do exist, but we won't
cover them in detail here; instead, we will look at the preferable
approach, which involves you being able to use the same IP address
each time you establish a network connection.[4]

[4] More
information on two dynamic host assignment mechanisms can be found at
http://www.dynip.com/.

In the previous example, we had pppd dial up c3po and establish an IP link. No provisions
were taken to choose a particular IP address on either end of the
link. Instead, we let pppd take its default action. It attempts to
resolve the local hostname, vlager
in our example, to an IP address, which it uses for the local end,
while letting the remote machine, c3po, provide its own. PPP supports several
alternatives to this arrangement.

To ask for particular addresses, you generally provide pppd with the
following option:

local_addr:remote_addr

local_addr
and
remote_addr may be specified either in
dotted quad notation or as hostnames.[5] This
option makes pppd attempt to use the first address supplied as its
own IP address, and the second as the peer's. If the
peer rejects either of the addresses during IPCP negotiation, no IP
link will be established.[6]

[5] Using hostnames
in this option has consequences for CHAP authentication. Please refer
to the section "The CHAP Secrets
File" later in this chapter.

[6] The
ipcp-accept-local and
ipcp-accept-remote options instruct your
pppd to accept the local and remote IP addresses
being offered by the remote PPP, even if you've
supplied some in your configuration. If these options are not
configured, your pppd will reject any attempt to
negotiate the IP addresses used.

If
you are dialing in to a server and expect it to assign you an IP
address, you should ensure that pppd does not attempt to negotiate
one for itself. To do this, use the noipdefault
option and leave the local_addr blank. The
noipdefault option will stop pppd from trying to
use the IP address associated with the hostname as the local address.

If you
want to set only the local address but accept any address the peer
uses, simply leave out the remote_addr
part. To make vlager use the IP
address 130.83.4.27 instead of its
own, give it 130.83.4.27: on the
command line. Similarly, to set the remote address only, leave the
local_addr field blank. By default, pppd
will then use the address associated with your hostname.

6.5.2. Routing Through a PPP Link

After setting up the network interface,
pppd will usually set up a host route to its peer only. If the remote
host is on a LAN, you certainly want to be able to connect to hosts
"behind" your peer as well; in that
case, a network route must be set up.

We have already seen that pppd can be
asked to set the default route using the
defaultroute option. This option is very useful if
the PPP server you dialed up acts as your Internet gateway.

The
reverse case, in which your system acts as a gateway for a single
host, is also relatively easy to accomplish. For example, take some
employee at the Virtual Brewery whose home machine is called
oneshot. Let's also
assume that we've configured vlager as a dial-in PPP server. If
we've configured vlager to dynamically assign an IP address
that belongs to the Brewery's subnet, we can use the
proxyarp option with pppd, which will install a
proxy ARP entry for oneshot. This
automatically makes oneshot
accessible from all hosts at the brewery and the winery.

However, things aren't always that simple. Linking
two local area networks usually requires adding a specific network
route because these networks may have their own default routes.
Besides, having both peers use the PPP link as the default route
would generate a loop, through which packets to unknown destinations
would ping-pong between the peers until their time to live expired.

Suppose the Virtual Brewery opens a branch in another city. The
subsidiary runs an Ethernet of its own using the IP network number
172.16.3.0, which is subnet 3 of the
brewery's class B network. The subsidiary wants to
connect to the brewery's network via PPP to update
customer databases. Again, vlager
acts as the gateway for the brewery network and will support the PPP
link; its peer at the new branch is called vbourbon and has an IP address of 172.16.3.1.

When vbourbon connects to vlager, it makes the default route point to
vlager as usual. On vlager, however, we will have only the
point-to-point route to vbourbon and
will have to specially configure a network route for subnet 3 that
uses vbourbon as its gateway. We
could do this manually using the route command
by hand after the PPP link is established, but this is not a very
practical solution. Fortunately, we can configure the route
automatically by using a feature of pppd that we
haven't discussed yetthe
ip-up command. This command is a shell script or
program located in /etc/ppp that is executed by
pppd after the PPP interface has been configured. When present, it is
invoked with the following parameters:

ip-up iface device speed local_addr remote_addr

Table 6-1 summarizes the meaning of each of the
arguments (in the first column, we show the number used by the shell
script to refer to each argument).

In our case, the ip-up script may contain
the following code fragment:[7]

[7] If we wanted to have
routes for other sites created when they dial in,
we'd add appropriate case statements to cover those
where the ... appears in the example.

#!/bin/sh
case $5 in
172.16.3.1)            # this is vbourbon
route add -net 172.16.3.0 gw 172.16.3.1;;
...
esac
exit 0

Similarly,
/etc/ppp/ip-down can be used to undo any actions
of ip-up after the PPP link has been taken down again. So in our
/etc/ppp/ip-down script we would have a route
command that removed the route we created in the
/etc/ppp/ip-up script.

However, the routing scheme is not yet complete. We have set up
routing table entries on both PPP hosts, but so far none of the hosts
on either network knows anything about the PPP link. This is not a
big problem if all hosts at the subsidiary have their default route
pointing at vbourbon and all brewery
hosts route to vlager by
default.