674-676.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 95 行
HTML
95 行
<HTML>
<HEAD>
<TITLE>Linux Unleashed, Third Edition:SLIP and PPP</TITLE>
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!--ISBN=0672313723//-->
<!--TITLE=Linux Unleashed, Third Edition//-->
<!--AUTHOR=Tim Parker//-->
<!--PUBLISHER=Macmillan Computer Publishing//-->
<!--IMPRINT=Sams//-->
<!--CHAPTER=38//-->
<!--PAGES=674-676//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="672-674.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="676-680.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P>The <TT>pppd</TT> daemon begins setting up the connection parameters with the remote by exchanging IP addresses, then sets communications values. After that is done, <TT>pppd</TT> sets the network layer to use the PPP link by setting the interface to <TT>/dev/ppp0</TT> (if it’s the first PPP link active on the machine). Finally, <TT>pppd</TT> establishes a kernel routing table entry to point to the machine on the other end of the PPP link.</P>
<H4 ALIGN="LEFT"><A NAME="Heading10"></A><FONT COLOR="#000077">Checking Problems</FONT></H4>
<P>The <TT>pppd</TT> daemon echoes all warnings and error messages to the syslog facility. If you use the <TT>-v</TT> option with the chat script, <TT>chat</TT>’s messages are also sent to syslog. If you have trouble with your PPP connections, you can check the syslog for details and try to isolate the problem. A word of warning about the <TT>-v</TT> option: Everything gets echoed to the logs, including usernames and passwords. This is an option you should avoid using unless necessary for debugging purposes.</P>
<P>Unless there is an entry in the <TT>/etc/syslog.conf</TT> file that redirects incoming error and warning messages to another file, the messages are discarded by syslog. To save the messages from <TT>pppd</TT> and <TT>chat</TT>, add this line to the <TT>/etc/syslog.conf</TT> file:</P>
<!-- CODE SNIP //-->
<PRE>
daemon.* /tmp/ppp-log
</PRE>
<!-- END CODE SNIP //-->
<P>This entry tells syslog to save any incoming messages from a daemon to the <TT>/tmp/ppp-log</TT> file. You can use any filename you want instead of <TT>/tmp/ppp-log.</TT> Many Linux versions of the <TT>syslog.conf</TT> file insist on tabs to separate the columns instead of spaces. After your script is working, remember to remove this line or the log file will grow quite large!</P>
<H4 ALIGN="LEFT"><A NAME="Heading11"></A><FONT COLOR="#000077">PPP Authentication</FONT></H4>
<P>PPP is a wonderful protocol for modem-based communications, but it has one major problem: It has security holes large enough to drive a bus through. If even slightly incorrectly configured, anyone can use the PPP line to get into your machine or use the PPP line to get out to other systems. To help prevent this, <I>authentication</I> is often used. Authentication essentially makes sure that each end of the connection is who they say they are and is allowed to use the link.</P>
<P>There are two authentication schemes used by PPP: the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). PAP is much like a login procedure. When one machine sends the login name and password to the other, the receiving machine verifies the information with a database on its end. While simple, PAP has a major flaw: Anyone can tap into the line and monitor the passwords being sent.</P>
<P>CHAP solves this problem, and hence, is the most favored form of authentication for PPP links. CHAP enables one machine to send a random string to the other, along with its hostname. The other end uses the hostname to look up the proper reply, combine it with the first string, encrypt it, then resend it to the first machine along with its hostname. The first machine performs the same sort of manipulation on the random string it first sent, and if the two replies match, the authentication is complete. And because CHAP doesn’t authenticate only at start time but at random intervals throughout the connection, it is even more powerful.</P>
<P>When two machines connect, they don’t use authentication unless explicitly instructed to do so. (See the <TT>auth</TT> entry in the <TT>/etc/ppp/options</TT> file discussed earlier.) When authentication is active, one end tries to use CHAP first; then, if that fails because the other end doesn’t support CHAP, it will use PAP. If neither authentication scheme is supported by the other end, the connection is terminated. If you are going to use authentication for all your PPP connections, put the <TT>auth</TT> entry in the <TT>/etc/ppp/options</TT> file. If your connections don’t all support authentication, then those connections will fail if <TT>auth</TT> is specified.</P>
<P>The information needed for both CHAP and PAP are kept in two files called <TT>/etc/ppp/chap-secrets</TT> and <TT>/etc/ppp/pap-secrets,</TT> respectively. When authentication is active, one end checks the other for these files, trying CHAP first. If you are going to use authentication for all your connections (which is a very good idea), you can build up the <TT>chap-secrets</TT> and <TT>pap-secrets</TT> files. If you configure both <TT>chap-secrets</TT> and <TT>pap-secrets</TT> and specify the <TT>auth</TT> option in <TT>/etc/ppp/options</TT>, no unauthenticated host can connect to your machine.</P>
<P>The <TT>/etc/ppp/chap-secrets</TT> file consists of four columns for the client name, the server name, the secret password string, and an optional list of IP addresses. The behavior of the system is different depending on whether the local machine is being challenged to authenticate itself or is issuing a challenge to the remote. When the local machine has to authenticate itself, <TT>pppd</TT> examines the <TT>/etc/ppp/chap-secrets</TT> file for an entry in the client field that matches the local hostname and the server field equal to the remote hostname, then uses the string to build the authentication message. Such an entry in the <TT>/etc/ppp/chap-secrets</TT> file looks like this:</P>
<!-- CODE SNIP //-->
<PRE>
# client server string addresses
merlin.tpci.com big_guy.big_net.com “I hate DOS”
</PRE>
<!-- END CODE SNIP //-->
<P>This entry uses the string <TT>I hate DOS</TT> to build an authentication message back to <TT>big_guy.big_net.com</TT>. The quotations are necessary to surround the string in the file. (We’ll look at the addresses column in a moment.) If you are setting up your system to connect to three different PPP remotes, you will want an entry for each server, so your file may look like this:</P>
<!-- CODE SNIP //-->
<PRE>
# client server string addresses
merlin.tpci.com big_guy.big_net.com “I hate DOS”
merlin.tpci.com chatton.cats.com “Meow, Meow, Meow”
merlin.tpci.com roy.sailing.ca “Hoist the spinnaker”
</PRE>
<!-- END CODE SNIP //-->
<P>When your machine is sending the challenge, the process is reversed. The <TT>pppd</TT> daemon looks for the remote hostname in the client field, the local hostname in the server field, and uses the string to compare the encryption results with the string sent back by the remote. Entries in the <TT>/etc/ppp/chap-secrets</TT> file for this purpose look like this:</P>
<!-- CODE SNIP //-->
<PRE>
# client server string addresses
big_guy.big_net.com merlin.tpci.com “Size isn’t everything”
</PRE>
<!-- END CODE SNIP //-->
<P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="672-674.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="676-680.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?