Information to Be Gathered for the Leased-Line Link
Before you configure the peer at your end of a leased line, you might need to gather the items or information that is listed in the next table.
Table 30-4 Planning for a Leased-Line Link
Information | Action |
|---|---|
Device name of the interface | Refer to the Interface card documentation. |
Configuration instructions for the synchronous interface card | Refer to the Interface card documentation. You need this information to configure the HSI/S interface. You might not need to configure other types of interface cards. |
(Optional) IP address of the remote peer | Refer to the service provider documentation or contact the system administrator of the remote peer. This information is needed only if the IP address is not negotiated between the two peers. |
(Optional) Name of the remote peer | Refer to the service provider documentation or contact the system administrator of the remote peer. |
(Optional) Speed of the link | Refer to the service provider documentation or contact the system administrator of the remote peer. |
(Optional) Compression that is used by the remote peer | Refer to the service provider documentation or contact the system administrator of the remote peer. |
Example--Configuration for a Leased-Line Link
The tasks in Chapter 32, Setting Up a Leased-Line PPP Link (Tasks) show how to implement the goal of a medium-sized organization called LocalCorp to provide Internet access for its employees. Currently, the employees' computers are connected on a private corporate intranet.
LocalCorp requires speedy transactions and access to the many resources on the Internet. The organization signs a contract with Far ISP, a service provider, that allows LocalCorp to set up its own leased line to Far ISP. Then, LocalCorp leases a T1 line from Phone East, a telephone company. Phone East puts in the leased line between LocalCorp and Far ISP and provides to Local Corp a CSU/DSU that is already configured.
The tasks set up a leased-line link with the following characteristics:
LocalCorp has set up a system as a gateway router, which forwards packets over the leased line to hosts on the Internet.
Far ISP also has set up a peer as a router to which leased lines from customers are attached.
Figure 30-2 Sample Leased-Line Configuration
In the figure, the machine that is set up for PPP at LocalCorp is a router with a connection to the corporate intranet through its hme0 interface. The second connection is through the machine's HSI/S interface (hih1) to the CSU/DSU digital unit. The CSU/DSU then connects to the installed leased line. The link between LocalCorp and Far ISP is initiated after the administrator at LocalCorp configures the HSI/S interface and PPP files, and then types the /etc/init.d/pppd start command.
Where to Get More Information About Leased Lines
Task | For Information |
|---|---|
Set up a client on a leased line | |
Get an overview of leased lines |
Planning for Authentication on a Link
This section contains planning information for providing authentication on the PPP link. Chapter 33, Setting Up PPP Authentication (Tasks) contains tasks for implementing PPP authentication at your site.
PPP offers two types of authentication, PAP, which is described in detail in "Password Authentication Protocol (PAP)" and CHAP, which is described in "Challenge-Handshake Authentication Protocol (CHAP)".
Before you set up authentication on a link, you must choose which authentication protocol best suits your site's security policy. Then you set up the secrets file and PPP configuration files for the dial-in machines, or callers' dial-out machines, or both types of machines. For information on choosing the appropriate authentication protocol for your site, see "Why Use PPP Authentication?".
This section includes the following information:
Planning information for both PAP and CHAP authentication
Explanations of the sample authentication scenarios that are shown in Figure 30-3 and Figure 30-4
Before You Set Up PPP Authentication
Setting up authentication at your site should be an integral part of your overall PPP strategy. Before implementing authentication, you should assemble the hardware, configure the software, and test the link to see if it works.
Table 30-5 Prerequisites Before Configuring Authentication
Information | For Instructions |
|---|---|
Tasks for configuring a dial-up link | |
Tasks for testing the link | |
Security requirements for your site | Your corporate security policy. If you do not have a policy, setting up PPP authentication gives you an opportunity to create a security policy. |
Suggestions about whether to use PAP or CHAP at your site | "Why Use PPP Authentication?". For more detailed information about these protocols, refer to "Authenticating Callers on a Link". |
Example--PPP Authentication Configurations
This section contains the sample authentication scenarios to be used in the procedures in Chapter 33, Setting Up PPP Authentication (Tasks).
Example--Configuration Using PAP Authentication
The tasks in "Configuring PAP Authentication" show how to set up PAP authentication over the PPP link. The procedures use as an example a PAP scenario that was created for the fictitious "Big Company" that was introduced in "Example-- Configuration for Dial-up PPP".
Big Company wants to enable its users to work from home. The system administrators want a secure solution for the serial lines to the dial-in server. UNIX-style login that uses the NIS password databases has served BigCompany's network well in the past. The system administrators want a UNIX-like authentication scheme for calls that come in to the network over the PPP link. So they implement the following scenario that uses PAP authentication.
Figure 30-3 Example--PAP Authentication Scenario (Working From Home)
The system administrators create a dedicated dial-in DMZ that is separated from the rest of the corporate network by a router. The term DMZ comes from the military term demilitarized zone. The DMZ is an isolated network that is set up for security purposes. The DMZ typically contains resources that a company offers to the public, such as web servers, anonymous FTP servers, databases, and modem servers. Network designers often place the DMZ between a firewall and a company's Internet connection.
The only occupants of the DMZ that is pictured in Figure 30-3 are the dial-in server myserver and the router. The dial-in server requires callers to provide PAP credentials (including user names and passwords) when setting up the link. Furthermore, the dial-in server uses the login option of PAP. Therefore, the callers' PAP user names and passwords must correspond exactly to their UNIX user names and passwords that already are in the dial-in server's password database.
After the PPP link is established, the caller's packets are forwarded to the router. The router forwards the transmission to its destination on the corporate network or Internet.
Example--Configuration Using CHAP Authentication
The tasks in "Configuring CHAP Authentication" show how to set up CHAP authentication. The procedures use as an example a CHAP scenario to be created for the fictitious LocalCorp that was introduced in "Example--Configuration for a Leased-Line Link".
LocalCorp provides connectivity to the Internet over a leased line to an ISP. Because it generates heavy network traffic, the Technical Support department within LocalCorp requires its own, isolated private network. The department's field technicians travel extensively and need to access the Technical Support network from remote locations for problem-solving information. To protect sensitive information that is stored on the private network's database, remote callers must be authenticated before they are granted permission to log in.
Therefore, the system administrators implement the following CHAP authentication scenario for a dial-up PPP configuration.
Figure 30-4 Example--CHAP Authentication Scenario (Calling a Private Network)
The only link from the Technical Support department network to the outside world is the serial line to the dial-in server's end of the PPP link. The system administrators configure the laptop computer of each field service representative for PPP with CHAP security, including a CHAP secret. The chap-secrets database on the dial-in server contains the CHAP credentials for all machines that are allowed to call in to the Technical Support network.
Where to Get More Information About Authentication
Task | For Instructions |
|---|---|
Set up PAP authentication | |
Set up CHAP authentication | |
Learn details about PPP authentication | "Authenticating Callers on a Link" and the pppd(1M) man page |
Planning for DSL Support Over a PPPoE Tunnel
Some DSL providers require you to set up PPPoE tunneling for your site in order to run PPP over the providers' DSL lines and high-speed digital networks. For an overview of PPPoE, see "Support for DSL Users Through PPPoE".
A PPPoE tunnel involves three participants: a consumer, a telephone company, and an ISP. As system administrator, you either configure PPPoE for consumers--PPPoE clients at your company or consumers in their homes--or on a server at an ISP.
This section contains planning information for running PPPoE on both clients and access servers. The following topics are covered:
Planning information for the PPPoE host and access server
Explanation of the PPPoE scenario that is introduced in "Example--Configuration for a PPPoE Tunnel"
Before You Set Up a PPPoE Tunnel
Your preconfiguration activities depend on whether you configure the client side or server side of the tunnel. In either instance, you or your organization must contract with a telephone company. The telephone company provides the DSL lines for clients, and some form of bridging and possibly an ATM pipe for access servers. In most contracts, the telephone company assembles its equipment at your site.
Before Configuring a PPPoE Client
PPPoE client implementations usually consist of the following equipment:
Personal computer or other system used by an individual
DSL modem, which is usually installed by the telephone company or Internet access provider
(Optional) A hub, if more than one client is involved, as is true for corporate DSL consumers
(Optional) A splitter, usually installed by the provider
Many different DSL configurations are possible, which depends on the user or corporation's needs and the services that are offered by the provider.
Table 30-6 Planning for PPPoE Clients
Information | Action |
|---|---|
If setting up a home PPPoE client for an individual or yourself, get any setup information that is outside the scope of PPPoE. | Ask the telephone company or ISP if it requires any setup procedures. |
If setting up PPPoE clients at a corporate site, get the names of users to get PPPoE clients. If you configure remote PPPoE clients, it might be your responsibility to give users information for getting DSL equipment into their homes. | Ask management at your company for a list of authorized users. |
Find out what interfaces are available on the PPPoE client. | Run the ifconfig -a command on each machine for interface names. |
(Optional) Get the password for the PPPoE client. | Ask users for passwords that they prefer or assign them. Note that this password is used for link authentication, not for UNIX login. |