A dial-in server with a dynamic point-to-point link gives your site all the advantages of point-to-point communications. Chapter 7, Understanding PPP, introduces this configuration type. It consists of remote hosts communicating with at least one dial-in server that dynamically allocates point-to-point links on an as-needed basis. The sample configuration shown in Figure 11-1 is used throughout this section.
Each remote host communicates with the dial-in server using a standard point-to-point link. However, unlike the multipoint dial-in server in Figure 9-1, dial-in server mojave connects to a calling host over a dynamic point-to-point link. The server allocates an available link whenever a remote host attempts to establish a connection.
The idea behind a dynamic link is that the server provides the client with an IP address each time a connection is established. When the connection is established, the server allocates an available IP interface to the client. The remote IP address of the interface then becomes the client's IP address for the duration of the connection. When the connection is terminated, the IP interface is returned to the pool of available interfaces, ready to be used for another connection.
You use the same generic procedures for configuring dynamic links as you do for the remote host-to-multipoint dial-in server link, as described in "Overview of the Configuration Process". However, the dynamic point-to-point link has its own set of issues and requires slightly different modifications to the files involved in configuration.
You must add host information to the /etc/inet/hosts file for each machine that use the dynamically allocated PPP link. The IP addresses for the PPP endpoints should follow these conventions:
For the dial-in server, you must use the IP address of the server's primary network interface (for example le0 or smc0) as the address of the dynamic link.
For a dynamic link, you don't need to assign an IP address to each remote host (as you would for a static link), but you do need to assign a remote IP address to each point-to-point IP interface on the server. The number of IP interfaces you can use is equal to the number of modems your server is connected to. For example, if you have three modems, you need three point-to-point IP interfaces and three IP addresses
You must include a dummy IP address for the ifconfig command to work properly on the client. This address acts as a placeholder for the local IP address assigned to the client IP interface when PPP is started.
There are no restrictions on the remote IP addresses that can be assigned to the IP interfaces, but, for clarity, it is probably best to include only IP addresses belonging to the same subnet.
You must update the hosts database on all machines involved in the dynamic-link configuration.
When configuring the hosts databases on the remote machines, do the following:
Add to the /etc/inet/hosts file the IP address and host name of the primary network interface for each dial-in server on the other end of the link.
For example, in Figure 11-1, the /etc/inet/hosts file for nomada, nomadb, and nomadc should each include the IP address of the primary network interface of the dial-in server mojave.
Add the dummy IP address.
This IP address is used only when PPP is started.
The /etc/inet/hosts file on nomadc might look like:
# Internet host table # 127.0.0.1 localhost loghost 192.41.40.55 mojave 1.2.3.4 dummy |
Add to the /etc/inet/hosts file the IP addresses of all machines on the dial-in server`s physical network that the remote host can remotely log in to.
Update the databases on any name server on the physical network with the host names and IP addresses of the remote hosts.
You do not have to add any PPP-specific address to the hosts database for the dial-in server. The dynamically allocated link must use the server's primary network interface. Therefore, when configuring the hosts database for the dial-in server, do the following:
Add entries to the server's /etc/inet/hosts files for each remote host served.
Add to the /etc/inet/hosts files of every machine on the physical network entries for any remote hosts they are permitted to communicate with.
The next steps in the configuration process involve editing the /etc/passwd file and the /etc/shadow file. Edit these files for the dynamic-link configurations just as you would for the remote host-to-multipoint dial-in server configuration. Refer to "Modifying the /etc/passwd File" for information regarding the /etc/passwd and /etc/shadow files.
The asppp.cf configuration file for a dynamic-link configuration must contain information about remote hosts and the interfaces to use for the PPP link. After the dial-in server boots, its link manager uses this information to establish communications whenever the server is called by a remote endpoint.
The asppp.cf configuration file for a remote host is the same as the one described in "Parts of Basic Configuration File", except for the addition of the parameter negotiate_address:
ifconfig ipdptp0 plumb dummy mojave up path interface ipdptp0 peer_system_name mojave-ppp connectivity_timeout 300 negotiate_address on |
The negotiate_address parameter indicates whether or not local IP address assignment is obtained through negotiation and assigned dynamically. If set to on, the IP address supplied by the server is used as the client's local address for the duration of the connection.
When the dial-in server receives an incoming packet, the link manager reads the path sections of its configuration file to identify the remote endpoint and determine the interface to use. The configuration file shown in Example 11-1 does not contain an interface keyword. Instead, the link manager uses interface information established in the defaults section.
The asppp.cf configuration file for a dial-in server with dynamically allocated links might resemble Example 11-1:
ifconfig ipdptp0 plumb mojave clienta down ifconfig ipdptp1 plumb mojave clientb down ifconfig ipdptp2 plumb mojave clientc down # This means grab whatever interface is available (not in use) defaults interface ipdptp* # Each path specifies a machine that might dial up / log # in to this server path peer_system_name tamerlane # nomada uses the login name # tamerlane path peer_system_name lawrence # nomadb uses the name lawrence # for login path peer_system_name nomadc |
The ifconfig section for a dial-in server with a dynamically allocated link has the syntax:
ifconfig ipdptpn plumb server-name client-address down
Example 11-1 contains three ifconfig lines, each initializing a point-to-point interface.
ifconfig ipdptp0 plumb mojave clienta down ifconfig ipdptp1 plumb mojave clientb down ifconfig ipdptp2 plumb mojave clientc down |
When you configure a dynamically allocated link, you might want to include a defaults section in the asppp.cf file. This section sets the defaults for the value replacing keyword, wherever keyword subsequently appears in the asppp.cf file. The syntax for the defaults section is:
default keyword |
Example 11-1 uses the keyword interface to define the interface as ipdptp*, indicating a dynamic link. The asterisk wildcard tells the link manager to use any available ipdptp interface defined in the ifconfig section. Thus the link manager on server mojave uses either ipdptp0, ipdptp1, or ipdptp2--whichever is the first interface configured "down" that it finds.
The configuration file for the server with dynamic links must contain path sections for every remote host permitted to establish connections with the server. The path section has the following syntax: .
path peer_system_name endpoint-username |
No interface keyword has been defined in the path section because this value is defined in the defaults section.The peer_system_name keyword has the same meaning here as it does in the configuration file for the multipoint server. See "path Section for Multipoint Dial-in Server" for more information.
You can supply other keywords in the asppp.cf file to define how endpoint machines should communicate, including the use of security keywords as explained in "Configuration Keywords".