%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                        Nota Legal                             %
%                                                               %
%  Este documento  copyright (C) Olaf Kirch, okir@monad.swb.de  %
%                                                               %
% Para conocer las condiciones de copia, lea el fichero COPYING %
%                                                               %
% El autor no es responsable de cualquier da~no, directo o      %
% indirecto, resultante del uso de la informacion proporcionada %
% en este documento.                                            %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Cuando vaya a ver este documento en con vi en una pantalla de %
% 80 columnas haga antes un ':se nonumber'.                     %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
% Traduccion realizada por:                                     %
%   Eduardo Hernandez, eduher@arrakis.es                        %
%                                                               %
% Revisado en Mayo-1997 por:                                    %
%   Juan Jose Amor, jjamor@ls.fi.upm.es                         %
%                                                               %
% Revisado en 2-Marzo-1999 por:                                 %
%   Juan Jose Amor <jjamor@ls.fi.upm.es>                        %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%           C O M I E N Z O   D E   C A P I T U L O             %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{El Protocolo Punto\_a\_Punto (PPP)}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{ppp}

\section{Desenredando las Pes}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Internet!conexi\'on a}
\index{tel\'efono, env\'{\i}o de datos a trav\'es de}
\index{IP!l\'{\i}nea de serie}
\index{IP!llamadas}
\index{Protocolo Punto-a-Punto}
\index{enlace punto-a-punto}
\index{configuraci\'on!PPP|(}
\index{PPP|(}

Al igual que el SLIP, el PPP es un protocolo utilizado para enviar
datagramas a trav\'es de una conexi\'on serie, pero mejora algunas de
las carencias del anterior. El PPP permite a las partes comunicantes
negociar al principio de la conexi\'on opciones como las direcciones IP
y el tama\~no m\'aximo de los datagramas, y proporciona mecanismos de
autentificaci\'on de los clientes. Para cada una de estas
capacidades, el PPP tiene un protocolo concreto. A continuaci\'on,
describiremos brevemente estos bloques b\'asicos que constituyen el
PPP. Esta descripci\'on est\'a muy lejos de ser completa; si quiere saber
m\'as sobre el PPP, lea sus especificaciones en el RFC~1548, as\'{\i} como en
la docena de RFCs que le acompa\~nan.\footnote{
  Los RFCs m\'as relevantes est\'an listados en la Bibliograf\'{\i}a al final
  de este libro.
}


\index{HDLC}
En la parte m\'as baja del PPP est\'a el protocolo de
\emph{Control de Conexi\'on de Datos de Alto-Nivel}, abreviadamente
HDLC\footnote{N. del T.: Del inglés High-Level Data Link Control}
\footnote{
  En realidad, el HDLC es un protocolo mucho m\'as general publicado
  por la Organizaci\'on Internacional de Est\'andares (ISO).
}, que define los l\'{\i}mites de las tramas PPP individuales, y proporciona
un control de errores de 16~bit. Al contrario de lo que ocurr\'{\i}a
  con SLIP, una trama PPP es capaz de llevar
paquetes de otros protocolos distintos al IP, como el IPX de Novell o el
Appletalk. El PPP consigue esto a\~nadiendo a la trama b\'asica HDLC un
campo de control que identifica el tipo de paquete contenido en la
misma.


\index{LCP|see {Protocolo LCP de Control de Enlance (PPP)}}
\index{Protocolo LCP de Control de Enlace (PPP)}
% \index{l\'{\i}nea serie!cortocircuitada}
% \index{l\'{\i}nea serie cortocircuitada}
El LCP, Protocolo de Control de Enlace\footnote{N. del T.: Del inglés
Link Control Protocol}, es utilizado en la parte m\'as
alta del HDLC para negociar las opciones concernientes a la conexi\'on
de datos, tales como la Unidad M\'axima de Recepci\'on (MRU) que establece
el tama\~no m\'aximo del datagrama que cada extremo de comunicaci\'on
acepta recibir.

% El LCP es tambi\'en el responsable de vigilar la calidad de la conexi\'on
% y de la detecci\'on de l\'{\i}neas cortocircuitadas.\footnote{
%   Una l\'{\i}nea de serie est\'a cortocircuitada cuando recibes de vuelta
%   todo lo que la env\'{\i}as.
% }


% El LQR ser\'a descrito m\'as adelante, si es posible.


\index{autorizaciones!con PPP}
\index{PAP|see {Protocolo PAP de Autentificaci\'on por Contrase\~na}}
\index{Protocolo PAP de Autentificaci\'on por Contrase\~na}
\index{CHAP|see {Protocolo CHAP de Autentificaci\'on por Reto}}
\index{Protocolo CHAP de Autentificaci\'on por Reto}
Un paso importante en la configuraci\'on del enlace PPP corresponde a la
autentificaci\'on de los clientes. Aunque no es obligatorio, es casi un
deber para las l\'{\i}neas telef\'onicas. Normalmente el servidor pide al
cliente que se identifique probando que se sabe alguna clave secreta.
Si el llamante se equivoca, la conexi\'on se termina. Con el PPP,
las autorizaciones se producen en los dos sentidos; es decir, el
que llama tambi\'en puede pedir al servidor que se autentifique. Estos
procedimientos de autentificaci\'on son totalmente independientes entre
s\'{\i}. Hay dos protocolos distintos, seg\'un el tipo de autentificaci\'on, los
cuales discutiremos m\'as adelante. Se llaman el Protocolo de
Autentificaci\'on por Contrase\~na, o PAP, y el Protocolo de Autentificaci\'on
por Reto, o CHAP\footnote{N. del T.: Del inglés Challenge Handshake
Authentication Protocol}.


\index{Protocolos NCP de Control de Red}
\index{NCP|see {Protocolos NCP de Control de Red}}
\index{IP!Protocolo NCP de Control de Red (PPP)}
\index{IP!Protocolo de Control}
\index{IPCP|see {IP, Protocolo de Control}}
Cada protocolo de red que es encaminado a trav\'es de la conexi\'on de datos,
como el IP, el Appletalk, etc; es configurado din\'amicamente usando
el correspondiente Protocolo de Control de Red (NCP). Por ejemplo, para
enviar datagramas IP a trav\'es del enlace, los dos nodos tienen que
negociar en primer lugar qu\'e direcciones~IP van a utilizar. El protocolo
de control utilizado para esto es el IPCP\footnote{N. del T.: Del inglés
IP Control Protocol}, el Protocolo de Control del IP.


\index{compresi\'on de cabeceras Van Jacobson}
\index{compresi\'on de paquetes TCP/IP}
\index{PPP!compresi\'on}
\index{CSLIP}
Aparte de enviar datagramas~IP est\'andar a trav\'es del enlace, el PPP
tambi\'en permite la compresi\'on Van~Jacobson de las cabeceras en los
datagramas~IP. Es una t\'ecnica para meter las cabeceras de los paquetes
TCP en un espacio de tan solo tres bytes. Tambi\'en se utiliza en
el CSLIP, y es conocida coloquialmente como {\it compresi\'on de cabeceras~VJ}.
La utilizaci\'on de la compresi\'on puede negociarse
tambi\'en al comienzo de la conexi\'on gracias al IPCP.


%%%
% Otros m\'etodos para mejorar el rendimiento: compresi\'on de
% protocolos y control de direcciones.


\section{PPP en \linux}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{driver!PPP}
\index{PPP!driver}
\index{PPP!daemon}
\index{pppd@\prog{pppd}}

En el \linux, la funcionalidad del PPP est\'a dividida en dos partes, un
controlador de HDLC de bajo nivel situado en el kernel, y el demonio
\prog{pppd} del espacio del usuario que controla los diferentes
protocolos de control. La versi\'on actual del PPP para \linux{} es la
\file{linux-ppp-1.0.0}, y contiene el m\'odulo PPP para el kernel,
el \prog{pppd}, y un programa llamado \prog{chat} utilizado para
llamar al sistema remoto.


El controlador del PPP para el kernel fue escrito por Michael Callahan.
El \prog{pppd} fue escrito a partir de una implementaci\'on gratuita del PPP
para m\'aquinas Sun y 386BSD que a su vez fue escrita por Drew Perkins y otros
programadores, y mantenida por Paul Mackerras. Fue transportada a
\linux{} por Al Longyear.\footnote{
  Los dos autores han dicho que van a estar muy ocupados por bastante
  tiempo. As\'{\i} que si tiene alguna pregunta sobre el PPP en general,
  mejor pregunte a la gente en el canal de la lista de correo de los
  ``\linux{} activists'' en la RED.
} El \prog{chat} fue escrito por Karl Fox.\footnote{
  \email{karl@morningstar.com}.
}


\index{tty!disciplina de las l\'{\i}neas}
\index{disciplina de las l\'{\i}neas}
Al igual que el SLIP, el PPP est\'a implementado a trav\'es de una disciplina
especial para la utilizaci\'on de las l\'{\i}neas. Para utilizar una l\'{\i}nea de
serie como enlace PPP, en primer lugar tendr\'a que establecer la conexi\'on
con su m\'odem, como es usual; y posteriormente pasar la l\'{\i}nea al modo PPP.
En este modo, todos los datos que nos llegan son pasados al controlador
del PPP, que comprueba la validez de las tramas que llegan (cada trama
HDLC trae un c\'odigo de control de errores de 16~bit), las descompone y las
despacha. Actualmente, es capaz de controlar datagramas~IP, utilizando
opcionalmente la compresi\'on de cabeceras Van~Jacobson. Tan pronto como
\linux{} acepte IPX, el controlador PPP ser\'a ampliado para poder controlar
tambi\'en los paquetes IPX.


El controlador del kernel es ayudado por el  \prog{pppd}, el demonio del
PPP, que realiza toda la fase de inicializaci\'on y autentificaci\'on necesaria
antes de que el verdadero tr\'afico de red pueda ser enviado a trav\'es del
enlace. El comportamiento del \prog{pppd} puede ser ajustado utilizando
varias opciones. Como el PPP es bastante complejo, es imposible explicar
todas ellas en un s\'olo cap\'{\i}tulo. Por eso, este libro no puede cubrir todos
los aspectos del \prog{pppd}, sino solamente darle una introducci\'on. Para
m\'as informaci\'on, lea las p\'aginas de manual y los ficheros \file{README} de
la distribuci\'on con las fuentes del \prog{pppd}, que deber\'{\i}an ayudarle
a comprender la mayor parte de las cuestiones que este cap\'{\i}tulo no
trata. Si su problema persiste incluso despu\'es de leer toda la
documentaci\'on, deber\'{\i}a pasarse por el grupo de noticias
\ngrp{comp.protocols.ppp} para solicitar ayuda, que es el lugar donde
encontrar\'a a la mayor parte de la gente envuelta en el desarrollo del
\prog{pppd}.



\section{Conexiones con \prog{pppd}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Internet!conectando a}
\index{pppd@\prog{pppd}|(}

Cuando quiere conectarse a Internet a trav\'es de un enlace PPP, tiene
que configurar las capacidades b\'asicas de red como el dispositivo de
loopback y el sistema de resoluci\'on de direcciones. Las dos han sido explicadas
en los cap\'{\i}tulos previos. Hay algunas cosas que es necesario decir
sobre la utilizaci\'on del DNS en un enlace serie; por favor, lea
el cap\'{\i}tulo del SLIP para m\'as informaci\'on.


Como ejemplo introductorio de c\'omo establecer una conexi\'on PPP con
el \prog{pppd}, suponga que est\'a de nuevo en \host{vlager}. Ya ha
llamado al servidor PPP, \host{c3po}, y entrado en la cuenta del
usuario \user{ppp}. \host{c3po} ya ha lanzado su controlador PPP. Despu\'es
de salir del programa de comunicaciones que utiliz\'o para llamar, se ejecuta
el siguiente comando:


\begin{tscreen}
\begin{verbatim}
# pppd /dev/cua3 38400 crtscts defaultroute
\end{verbatim}
\end{tscreen}


\index{control de flujo, hardware}
\index{hardware!control de flujo}
\index{RTS/CTS!control de flujo}

Esto cambiar\'a a la l\'{\i}nea de serie \file{cua3} al modo PPP y establecer\'a
un enlace~IP con \host{c3po}. La velocidad de transferencia utilizada en
el puerto de serie ser\'a de 38400bps. La opci\'on \keyword{crtscts} activa
el control de flujo por hardware en el puerto, que es una obligaci\'on para
velocidades superiores a los 9600~bps.


Lo primero que hace el \prog{pppd} tras ejecutarse es negociar varias
caracter\'{\i}sticas para el enlace con el extremo remoto utilizando el LCP.
Normalmente, el conjunto de opciones que intenta negociar el \prog{pppd}
funcionar\'a, as\'{\i} que no nos meteremos m\'as con este asunto. Volveremos a
tratar el LCP con m\'as detalle en alguna secci\'on posterior.


Hasta ahora, tambi\'en hemos asumido que \host{c3po} no necesita ninguna
autentificaci\'on de nosotros, as\'{\i} que la fase configuraci\'on habr\'a sido
completada con \'exito.


\index{PPP!y direcciones IP}
\index{IP!direcci\'on!negociaci\'on con PPP}
\index{direcci\'on!negociaci\'on con PPP}
El \prog{pppd} negociar\'a entonces los par\'ametros IP con su compa\~nero
usando IPCP, el protocolo de control IP. Al no especificar direcci\'on
IP alguna, el \prog{pppd} intentar\'a usar la direcci\'on que se obtiene
al resolver el nombre del ordenador local. Decididas las direcciones,
cada \prog{pppd} se lo comunicar\'a al otro extremo.


Normalmente no habr\'a ning\'un problema con esta configuraci\'on por defecto.
Incluso si su m\'aquina est\'a en una Ethernet, puede utilizar la misma
direcci\'on~IP tanto para la Ethernet como para el interface PPP.
No obstante, el \prog{pppd} le permite utilizar direcciones diferentes,
o incluso pedir a su compa\~nero que utilice alguna direcci\'on espec\'{\i}fica.
Estas opciones ser\'an discutidas m\'as adelante.


\index{interface!PPP}
\index{configurando el!PPP}
\index{PPP!encaminamiento por defecto}
\index{encaminamiento, por defecto}
Tras pasar por la fase de configuraci\'on IPCP, el \prog{pppd}
configurar\'a la red de su ordenador para utilizar el enlace PPP. En
primer lugar, configurar\'a el interface de red PPP como un enlace
punto-a-punto, utilizando el \file{ppp0} para el primer enlace PPP que
est\'e activo, \prog{ppp1} para  el segundo, y as\'{\i}
sucesivamente. A continuaci\'on preparar\'a una entrada de la tabla de
encaminamiento que apunte al ordenador del otro extremo del
enlace. En el ejemplo anterior, el \prog{pppd} har\'a que el encaminamiento de
red por defecto apunte a \host{c3po}, debido a que lo especificamos
con la opci\'on \keyword{defaultroute}.\footnote{
  El encaminamiento por defecto es instalado s\'olamente si no hay
  ninguno establecido de antes.
} Esto provoca que todos los datagramas dirigidos a ordenadores que
no est\'en en su red sean enviados a \host{c3po}. Hay un variado n\'umero
de formas de encaminamiento que acepta el \prog{pppd}, y las
cubriremos en mayor detalle m\'as adelante.


\section{Los Ficheros de Opciones}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{ppp.ppprc}{Utilizaci\'on de los Ficheros de Opciones}
\index{PPP!ficheros de opciones}

Antes de que el \prog{pppd} procese los argumentos de su l\'{\i}nea de
comandos, 
echa un vistazo a varios ficheros para establecer sus opciones por defecto.
Estos ficheros pueden contener cualquier argumento de l\'{\i}nea de comando
v\'alido, distribuido a trav\'es de un cierto n\'umero de l\'{\i}neas.
Los comentarios se escriben tras el s\'{\i}mbolo de almohadillado
({\tt\#}).


El primer fichero de opciones es el \file{/etc/ppp/options}, que es
le\'{\i}do cada vez que el \prog{pppd} arranca. El utilizarlo para establecer
algunas opciones globales por defecto es una buena idea, pues le
permite evitar que sus usuarios hagan ciertas cosas que podr\'{\i}an
comprometer la seguridad del sistema. Por ejemplo, para hacer que el PPP
necesite alg\'un tipo de autentificaci\'on del otro sistema, a\~nadir\'{\i}a la
opci\'on \option{auth} a este fichero. Esta opci\'on no puede ser evitada
por el usuario, de forma que se hace totalmente imposible el establecer
una conexi\'on PPP con cualquier sistema que no est\'e en nuestras bases de
datos para la autentificaci\'on.


\index{ppprc@\file{.ppprc}}
El otro fichero de opciones, que es le\'{\i}do despu\'es del
\file{/etc/ppp/options}, es el \file{.ppprc} situado en el directorio
\emph{home} del usuario. Permite que cada usuario especifique su propio conjunto
de opciones por defecto.


Un fichero \file{/etc/ppp/options} de ejemplo puede parecerse a \'este:


\begin{tscreen}
\begin{verbatim}
# Opciones globales para el pppd de vlager.vbrew.com
auth                 # obligar a autentificacion
usehostname          # usar el nombre del ordenador local para el CHAP
lock                 # usar el bloqueo de dispositivo tipo UUCP
domain vbrew.com     # nombre de nuestro dominio
\end{verbatim}
\end{tscreen}


\index{ficheros de bloqueo!y PPP}
\index{PPP!ficheros de bloqueo}
Las dos primeras opciones se utilizan para la autentificaci\'on y ser\'an
explicadas a continuaci\'on. La expresi\'on \option{lock} hace que el
\prog{pppd} utilice el m\'etodo de bloqueo de dispositivos de UUCP. De
esta manera,
cada proceso que accede a un dispositivo serie, por ejemplo el
\file{/dev/cua3}, crea un fichero de bloqueo llamado \file{LCK..cua3}
en el directorio de spool del UUCP para se\~nalizar que ese dispositivo
est\'a siendo usado. Esto es necesario para evitar que otros programas, como
pueden ser el \prog{minicom} o el \prog{uucico}, abran el dispositivo de
serie mientras \'este es usado por el PPP.



La raz\'on de poner \'estas opciones en el fichero de configuraci\'on global
es que \'estas no pueden ser pasadas por alto, de forma que proporcionan un
razonable nivel de seguridad. Pero tenga en cuenta que, a pesar de todo,
algunas opciones podr\'an ser pasadas por alto m\'as tarde; un ejemplo de
esto es la cadena \keyword{connect}.



\section{Realizaci\'on de la Llamada con \prog{chat}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{estableciendo la conexi\'on}
\index{chat!PPP}
\index{PPP!script del chat|(}

Uno de los problemas que puede haberle dado el ejemplo anterior es que
ten\'{\i}a que establecer la conexi\'on manualmente antes de poder ejecutar el
\prog{pppd}. Al contrario que el \prog{dip}, el \prog{pppd} no tiene su
propio lenguaje de {\it scripts} para llamar al sistema remoto y entrar en \'el,
sino que conf\'{\i}a en otro programa externo para que haga esto. El comando que
tiene que ser ejecutado puede d\'arsele al \prog{pppd} con la opci\'on
\keyword{connect} en la l\'{\i}nea de comando. El \prog{pppd} redirigir\'a la
entrada y salida est\'andar de comandos a la l\'{\i}nea de serie. Un programa
\'util para esto es el \prog{expect}, escrito por Don Libes. Tiene un
lenguaje muy potente basado en el Tcl, y fue dise\~nado exactamente para
este tipo de aplicaci\'on.


\index{chat@\prog{chat}|(}
\index{script del chat}
El paquete \prog{pppd} incluye un programa similar llamado \prog{chat}
que le permite especificar un script del estilo de los de UUCP. B\'asicamente,
un script del chat consiste en una secuencia alterna de cadenas que
esperamos recibir del sistema remoto y las respuestas que hemos de
enviar. Las llamaremos respectivamente, cadenas esperadas y cadenas enviadas.
Este es un extracto de un t\'{\i}pico script del chat:


\begin{tscreen}
\begin{verbatim}
ogin: b1ff ssword: s3kr3t
\end{verbatim}
\end{tscreen}


Esto le indica al \prog{chat} que espere a que el sistema remoto le env\'{\i}e
el mensaje de petici\'on de usuario y entonces le devuelve el nombre del usuario
\user{b1ff}. S\'olo esperamos por \term{ogin:} para que no importe si el
mensaje de {\it login} empiece por {\bf l} may\'uscula o min\'uscula, o si llega con
basura. La siguiente cadena es una cadena esperada que hace que el
\prog{chat} espere al mensaje de petici\'on de contrase\~na y la env\'{\i}e
nuestra contrase\~na como respuesta.


Esto es b\'asicamente lo que tienen los scripts del chat. Un script
completo para llamar a un servidor PPP deber\'{\i}a, adem\'as, incluir los comandos
apropiados para el m\'odem. Suponga que su m\'odem entiende los comandos
Hayes, y que el n\'umero de tel\'efono del servidor es el 318714. En ese caso,
la l\'{\i}nea completa del \prog{chat} para que pudi\'esemos establecer una
conexi\'on con \host{c3po} ser\'{\i}a


\begin{tscreen}
\begin{verbatim}
$ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN
\end{verbatim}
\end{tscreen}


Por definici\'on, la primera cadena que damos al chat tiene que ser una
cadena esperada, pero como el m\'odem no dir\'a nada hasta que hablemos
con \'el, hacemos que el \prog{chat} la ignore especificando una cadena
vac\'{\i}a. Continuamos enviando \term{ATZ}, el comando de inicializai\'on
para los modems compatibles Hayes, y esperamos a que nos responda con
\term{OK}. La siguiente cadena env\'{\i}a al \prog{chat} el comando de
marcado junto con el n\'umero de tel\'efono, y espera a que aparezca el
mensaje \term{CONNECT} como respuesta. Esto est\'a seguido de otra
cadena vac\'{\i}a otra vez, porque ahora no queremos enviar nada, sino
esperar a que aparezca el mensaje de petici\'on de login. El resto del
script del chat funciona exactamente como antes.


La opci\'on \option{-v} hace que el \prog{chat} capture todas las
actividades hacia la facilidad \keyword{local2} del demonio
\prog{syslog}.\footnote{
  Si edita el \file{syslog.conf} para redirigir estos mensajes a
  un fichero, aseg\'urese de que \'este fichero no pueda ser le\'{\i}do por
  cualquiera, pues el \prog{chat} tambi\'en captura todo el script de
  entrada por defecto~-- incluyendo las contrase\~nas.
}


\index{seguridad!PPP}
El escribir el script de chat directamente en la l\'{\i}nea de comando implica
un cierto riesgo, pues los usuarios pueden ver la l\'{\i}nea de comando de
un proceso con el comando \prog{ps}. Puede evitar esto colocando el script
del chat en un fichero, por ejemplo llamado \file{dial-c3po}. Entonces,
podr\'a hacer al \prog{chat} leer el script del fichero en vez de la l\'{\i}nea
de comando utilizando la opci\'on \option{-f}, seguida por el nombre del
fichero. Por lo tanto la invocaci\'on completa al \prog{pppd} tendr\'a
ahora un aspecto como \'este:


\begin{tscreen}
\begin{verbatim}
# pppd connect "chat -f dial-c3po" /dev/cua3 38400 -detach \
	crtscts modem defaultroute
\end{verbatim}
\end{tscreen}


Adem\'as de la opci\'on \keyword{connect} que se refiere al script de llamada,
hemos a\~nadido dos opciones m\'as a la l\'{\i}nea de comando: \keyword{-detach},
que le indica al \prog{pppd} que no se separe de la consola ni se vuelva
proceso de segundo plano. La palabra \keyword{modem} activa algunas acciones
espec\'{\i}ficas para m\'odem sobre el dispositivo de serie, como colgar la
l\'{\i}nea antes y despu\'es de la llamada. Si no utiliza esta opci\'on, el
\prog{pppd} no se preocupar\'a de la l\'{\i}nea DCD del puerto, y por lo tanto no
podr\'a detectar si el extremo remoto cuelga de forma imprevista.



Los ejemplos anteriores eran bastante simples; el \prog{chat} permite
el uso de scripts mucho m\'as complejos. Una caracter\'{\i}stica muy \'util
es la capacidad de especificar cadenas frente a las cuales parar el
chat con un error. Unas cadenas t\'{\i}picas para parar pueden ser
mensajes como 
\term{BUSY} o \term{NO CARRIER}, que son los que su m\'odem produce cuando
el n\'umero al que llama comunica o no descuelga. Para hacer que el 
\prog{chat} las reconozca inmediatamente en vez de esperar, puede
introducirlas al principio del script utilizando la opci\'on \option{ABORT}:


\begin{tscreen}
\begin{verbatim}
$ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...
\end{verbatim}
\end{tscreen}


De una forma parecida, puede variar el valor del tiempo de espera para
algunas partes de los scripts de chat insertando opciones
\option{TIMEOUT}. Para m\'as detalles, vea la p\'agina de manual del
\file{chat(8)}.


Algunas veces, tambi\'en querr\'a disponer de alg\'un tipo de ejecuci\'on
condicional de algunas partes del script de chat. Por ejemplo,
cuando reciba el mensaje de petici\'on de login desde el extremo remoto,
puede que quiera enviar un BREAK, o un retorno de carro. Puede conseguir
esto a\~nadiendo un sub-script a la parte esperada del script. Consiste en
en una secuencia de de cadenas de env\'{\i}o y esperadas, de la misma forma que
el script en su totalidad, pero separadas por guiones. El sub-script es
ejecutado desde el momento en que la cadena esperada a la que est\'an
ligados no es recibida a tiempo. Para este ejemplo, modificar\'{\i}amos el
script del chat de la siguiente manera:


\begin{tscreen}
\begin{verbatim}
ogin:-BREAK-ogin: ppp ssword: GaGariN
\end{verbatim}
\end{tscreen}


Ahora, cuando el \prog{chat} no recibe el mensaje de login del sistema
remoto, se ejecuta el sub-script enviando un BREAK y esperando de nuevo
por el mensaje de login. Si ahora ya aparece, el script contin\'ua como
usualmente y si no, termina con un error.

\index{PPP!script del chat|)}
\index{chat@\prog{chat}|)}


\section{Depuraci\'on de la Configuraci\'on PPP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{PPP!informaci\'on de depuraci\'on}
\index{depuraci\'on!configuraci\'on PPP}
\index{syslog@\prog{syslog}}
\index{comprobaci\'on!PPP}

Por defecto, el \prog{pppd} registrar\'a todos los avisos y mensajes de
error gracias a las facilidades \keyword{daemon} del \prog{syslog}. Tiene
que a\~nadir una entrada al \file{syslog.conf} que redirija esto a un
fichero, o incluso a la consola, pues de otra forma el \prog{syslog}
simplemente desechar\'a estos mensajes. La siguiente entrada env\'{\i}a todos
los mensajes a \file{/var/log/ppp-log}:


\begin{tscreen}
\begin{verbatim}
daemon.*                /var/log/ppp-log
\end{verbatim}
\end{tscreen}


Si la configuraci\'on de su PPP no funciona, echar un vistazo a este
fichero le deber\'{\i}a dar una primera pista de qu\'e es lo que va mal.
Si esto no le ayuda, tambi\'en puede activar la salida extra de
depuraci\'on utilizando la opci\'on \option{debug}. Esto hace que el
\prog{pppd} registre los contenidos de todos los paquetes de control
enviados o recibidos a \prog{syslog}. Todos los mensajes ir\'an a
la facilidad \keyword{daemon}.


Finalmente, la opci\'on m\'as dr\'astica es el activar la depuraci\'on a
nivel de kernel llamando al \prog{pppd} con la opci\'on \keyword{kdebug}. 
Esto es seguido por un argumento num\'erico que es el O exclusivo
({\it xor}) de los
siguientes valores: 1 para mensajes de depuraci\'on generales, 2 para
imprimir los contenidos de todas las tramas HDLC que nos llegan, y 4
para hacer al controlador imprimir todas las tramas HDLC salientes. Para
capturar los mensajes de depuraci\'on a nivel de kernel, tiene que, o
bien ejecutar un demonio \prog{syslogd} que lea el fichero
\file{/proc/kmsg}, o si no el demonio \prog{klogd}. Cualquiera de los
dos dirige la depuraci\'on del kernel a la facilidad \prog{kernel} del
\keyword{syslogd}.



\section{Opciones de Configuraci\'on IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{IP!Protocolo de Control}

El IPCP se utiliza para negociar un par de par\'ametros IP a la hora
de configurar la conexi\'on. Normalmente, cada extremo de
comunicaci\'on puede enviar
un Paquete de Petici\'on de Configuraci\'on IPCP, indicando qu\'e valores
quiere cambiar de los que vienen por defecto, y a qu\'e valor. Tras la
recepci\'on, el extremo remoto inspecciona cada opci\'on sucesivamente,
y, o responde que la acepta, o la rechaza.


El \prog{pppd} le da gran control sobre qu\'e opciones intentar\'a
negociar el IPCP. Puede ajustar esto a trav\'es de varias opciones
en la l\'{\i}nea de comandos de las que hablamos a continuaci\'on.


\subsection{Elecci\'on de las Direcciones IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{PPP!direcciones IP|(}
\index{IP!direcci\'on!negociaci\'on en PPP}
\index{direcci\'on!negociaci\'on con PPP}

En el ejemplo anterior, hac\'{\i}amos que el \prog{pppd} llamase a
\host{c3po} y estableciera una conexi\'on IP. No nos preocup\'abamos de
elegir una direcci\'on~IP particular en ninguno de los extremos de la
conexi\'on. En vez de ello, tom\'abamos la direcci\'on de \host{vlager} como
la direcci\'on~IP local, y dej\'abamos a \host{c3po} darse su propia
direcci\'on. Algunas veces, sin embargo, es \'util el tener control sobre
la direcci\'on utilizada por alguno de los extremos de la conexi\'on. El
\prog{pppd} soporta diferentes posibilidades sobre este aspecto.


Para pedir direcciones particulares, normalmente d\'e al \prog{pppd} la
siguiente opci\'on:


\begin{tscreen}
\var{dir\_local}:\var{dir\_remota}
\end{tscreen}


\noindent
donde \var{dir\_local} y \var{dir\_remota} pueden ser especificadas
en notaci\'on de cu\'adruplas num\'ericas o como nombres de ordenador.
\footnote{
   El utilizar nombres de ordenador en esta opci\'on tiene algunas   
   consecuencias a la hora de la autentificaci\'on utilizando CHAP.
   Puede echar un vistazo a la secci\'on sobre CHAP m\'as adelante.
} Esto hace al \prog{pppd} intentar usar la primera direcci\'on como su
propia direcci\'on~IP, y la segunda como la de su compa\~nero. Si el
compa\~nero rechaza alguna de ellas durante la negociaci\'on IPCP, no se
establecer\'a ninguna conexi\'on~IP.\footnote{
   Puede permitir al otro PPP sobreescribir sus ideas de direcciones IP
   dando al \prog{pppd} las opciones \option{ipcp-accept-local} e
   \option{ipcp-accept-remote}. Eche un vistazo a la p\'agina del manual
   para m\'as detalles.
}


Si s\'olo quiere establecer la direcci\'on local, y aceptar cualquier
direcci\'on que utilice el compa\~nero, simplemente deseche la parte de
la \var{dir\_remota}. Por ejemplo, para hacer a \host{vlager} usar
la direcci\'on~IP \host{130.83.4.27} en vez de la suya propia, le
escribir\'{\i}a \option{130.83.4.27:} en la l\'{\i}nea de comando. De forma
similar, para establecer la direcci\'on remota \'unicamente, dejar\'{\i}a
el campo de la \var{dir\_local}\/ en blanco. Por defecto, el \prog{pppd}
utilizar\'a entonces la direcci\'on asociada al nombre de su ordenador.


\index{PPP!asignaci\'on din\'amica de direcciones}
Algunos servidores PPP que sirven a muchos clientes asignan direcciones
din\'amicamente: las direcciones son asignadas a los sistemas s\'olo cuando
llaman, y son reclamadas de nuevo una vez que se desconecta. Cuando
llame a uno de \'estos servidores, debe asegurarse de que el
\prog{pppd} no solicita una direcci\'on~IP particular, sino que acepta
la direcci\'on que el servidor le pide que utilice. Esto quiere decir que
no tiene que poner el argumento \var{dir\_local}. Adem\'as, tendr\'a que
utilizar la opci\'on \option{noipdefault}, que hace que el \prog{pppd}
espere a que el compa\~nero le proporcione la direcci\'on IP en vez de
utilizar la direcci\'on IP del ordenador local.


% Bajo ciertas circunstancias, puede ser deseable el desactivar la
% negociaci\'on de direcci\'on IP conjuntamente, y simplemente confiar
% en la direcci\'on especificada en la l\'{\i}nea de comando. Esto se
% puede conseguir dando al \prog{pppd} la opci\'on \option{-ip}.

\index{PPP!direcciones IP|)}

\subsection{Encaminamiento a trav\'es de una Conexi\'on PPP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{encaminamiento!a trav\'es de PPP}
\index{PPP!encaminamiento|(}

Tras configurar el interface de red, el \prog{pppd} preparar\'a un encaminamiento
que s\'olamente le sirve para comunicarse con el otro extremo. Si el ordenador
remoto est\'a en una red de \'area local, seguramente usted desear\'a conectar
tambi\'en con los ordenadores que est\'an ``detr\'as'' de \'el; para eso, se
ha de configurar un encaminamiento de red adecuado.


Ya hemos visto antes que se puede pedir al \prog{pppd} que configure el
encaminamiento por defecto utilizando la opci\'on \option{defaultroute}. Esta opci\'on
es muy \'util si el servidor PPP al que llama va a actuar como su pasarela
a Internet.


\index{ARP!proxy}
\index{proxy ARP}
\index{PPP!proxy ARP}
El caso contrario, cuando su sistema act\'ua como un gateway para un
s\'olo ordenador, es tambi\'en relativamente f\'acil de llevar a cabo. Por
ejemplo, imagine a alg\'un empleado de la Cervecera Virtual cuyo ordenador
de casa se llama \host{loner}. Cuando est\'e conectando a \host{vlager}
a trav\'es de PPP, \'el utiliza una direcci\'on de la subred de la Cervecera.
Podremos dar al \prog{pppd} del ordenador \host{vlager} la opci\'on
\option{proxyarp}, que instalar\'a una entrada proxy-ARP para el
ordenador \host{loner}. Esto har\'a que \host{loner} sea autom\'aticamente
accesible desde todos los ordenadores de la Cervecera y la Vinatera.


\index{Red de Area Local!conecando}
\index{conectando Redes de Area Local}
De cualquier manera, las cosas no son siempre tan f\'aciles como esto, por
ejemplo cuando intentamos unir dos redes de \'area local. Esto requiere
normalmente el a\~nadir una ruta de red espec\'{\i}fica, porque estas redes
tendr\'an ya sus propios encaminamientos por defecto. Por otra parte, el tener a
los dos extremos de comunicaci\'on utilizando la conexi\'on PPP como
encaminamiento por defecto
generar\'{\i}a un ciclo sin fin, donde los paquetes con destinos desconocidos
rebotar\'{\i}an entre los dos ordenadores hasta que su tiempo de vida
({\it TTL}) expirase.


Pongamos un ejemplo: suponga que la Cervecera Virtual abre una sucursal en
alguna otra ciudad. La sucursal utiliza su propia red Ethernet
utilizando el n\'umero de red IP \host{191.72.3.0}, que es la subred~3 de
la red de clase B de la Cervecera. Quieren conectarse a la red Ethernet
principal de la Cervecera a trav\'es de PPP para actualizar las bases de
datos de clientes, etc. De nuevo, \host{vlager} actuar\'a como pasarela;
la otra m\'aquina se llama \host{sub-etha} y tiene una direcci\'on IP de
\host{191.72.3.1.}.


Cuando \host{sub-etha} conecta a \host{vlager}, har\'a que el punto de
encaminamiento por defecto sea \host{vlager}, como es habitual. En \host{vlager},
de todas formas, tendremos que instalar un encaminamiento de red para la subred~3
que vaya a trav\'es de \host{sub-etha}. Para esto, utilizamos una
caracter\'{\i}stica del \prog{pppd} de la que no hemos hablado hasta ahora~--
el comando \prog{ip-up}.  Es un script de shell situado en \file{/etc/ppp}
que se ejecuta despu\'es de que el interface PPP ha sido configurado. Cuando
est\'a presente, se le llama con los siguientes par\'ametros:


\begin{tscreen}
 ip-up \var{interface} \var{dispositivo} \var{velocidad} \var{dir\_local}
		\var{dir\_remota}
\end{tscreen}


\noindent
donde \var{interface}\/ se refiere al interface de red usado, \var{dispositivo} es
la ruta al dispositivo serie utilizado, (\file{/dev/tty} si se utiliza
la salida y entrada est\'andar), y \var{velocidad} es la velocidad del
dispositivo. \var{dir\_local} y \var{dir\_remota} nos dan las
direcciones~IP usadas en dos extremos de la conexi\'on en notaci\'on de
cuarteto num\'erico. En nuestro caso, el script \prog{ip-up} puede
contener el siguiente fragmento de c\'odigo:


\begin{tscreen}
\begin{verbatim}
#!/bin/sh
case $5 in
191.72.3.1)            # este es sub-etha
	route add -net 191.72.3.0 gw 191.72.3.1;;
...
esac
exit 0
\end{verbatim}
\end{tscreen}


De una forma an\'aloga, \prog{/etc/ppp/ip-down} se utiliza para deshacer
todas las acciones de \prog{ip-up} despu\'es de que la conexi\'on PPP ha sido
cortada.


\index{encaminamiento!din\'amico}
\index{gated@\prog{gated}}
A pesar de todo, la tabla de encaminamiento a\'un no est\'a completa. Hemos
configurado las entradas de la tabla de encaminamiento para las dos ordenadores
con PPP, pero hasta ahora, todos los dem\'as ordenadores de las dos redes
no saben nada sobre la conexi\'on PPP. Esto no es un gran problema
si todos los ordenadores de la sucursal tienen su encaminamiento por defecto
encaminado a \host{sub-etha}, y todos los ordenadores de la Cervecera
encaminan hacia \host{vlager} por defecto. Si \'este no fuera el caso, su
\'unica posibilidad normalmente ser\'a usar un demonio de
encaminamiento como el
\prog{gated}. Tras crear el encaminamiento de la red en \host{vlager},
el demonio
de encaminamiento pasar\'a el nuevo encaminamiento a todos los ordenadores de las redes
dependientes de \'esta.




\index{PPP!encaminamiento|)}


\section{Opciones de Control de Enlace}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Protocolo LCP de Control de Enlace (PPP)|(}

Anteriormente, ya hemos tratado sobre el LCP, el protocolo de control
de enlace (Link Control Protocol), que se utiliza para negociar las
caracter\'{\i}sticas de la conexi\'on y comprobarla.


Las dos opciones m\'as importantes que pueden ser negociadas por el LCP
son la unidad m\'axima de recepci\'on (MRU) y el mapa de caracteres de
control as\'{\i}ncronos. Tambi\'en hay varias opciones de configuraci\'on LCP
m\'as, pero son demasiado espec\'{\i}ficas como para comentarlas aqu\'{\i}. Eche
un vistazo a la RFC~1548 para ver una descripci\'on de \'estas.


\index{l\'{\i}nea de serie!protegiendo caracteres}
\index{PPP!rehuyendo caracteres de control}
\index{PPP!mapa as\'{\i}ncrono}
El mapa de caracteres de control as\'{\i}ncronos, tambi\'en conocido como
el mapa as\'{\i}ncrono, es usado en enlaces as\'{\i}ncronos, como las l\'{\i}neas
telef\'onicas, para identificar los caracteres de control que deben de ser
reemplazados por una secuencia espec\'{\i}fica de dos
caracteres\footnote{N. del T.: Estos caracteres se conocen como {\it
rehuidos}}.
Por ejemplo, puede que quiera evitar los caracteres XON y XOFF
utilizados con el control de flujo hardware activado, pues alg\'un
m\'odem mal configurado puede 
parar hasta que reciba un XOFF. Otro candidato puede ser \term{Ctrl-]}
(el car\'acter de escape del \prog{telnet}). El PPP le permite rehuir de
cualquiera de los caracteres con c\'odigos ASCII comprendidos entre 0 y 31
especific\'andolos en el mapa as\'{\i}ncrono.


El mapa as\'{\i}ncrono ({\it async map}) es un mapa de bits de 32~bits de ancho, y
cuyo bit menos significativo corresponde al car\'acter ASCII NUL, y cuyo
bit m\'as significativo corresponde al ASCII 31. Si un bit se pone a 1,
indica que el caracter correspondiente debe de ser rehuido antes de
ser enviado a trav\'es de la conexi\'on. Inicialmente, el mapa as\'{\i}ncrono
se establece como \keyword{0xffffffff}, lo que significa que todos los
caracteres de control ser\'an rehuidos.


Para decir al otro ordenador que no tiene que rehuir de todos los
caracteres de control sino s\'olo de algunos, puede establecer un nuevo
mapa as\'{\i}ncrono al \prog{pppd} utilizando la opci\'on \option{asyncmap}.
Por ejemplo, si s\'olo \verb|^S| y \verb|^Q| (los c\'odigos ASCII 17 y 19,
normalmente utilizados para XON y XOFF) deben de ser rehuidos, utilice la
siguiente opci\'on:


\begin{tscreen}
asyncmap 0x000A0000
\end{tscreen}


\index{MRU|see {PPP, Unidad M\'axima de Recepci\'on}}
\index{PPP!Unidad M\'axima de Recepci\'on}
\index{Unidad M\'axima de Recepci\'on (PPP)}
\index{Unidad M\'axima de Transferencia}
La unidad m\'axima de recepci\'on, o MRU, se\~naliza al otro extremo el tama\~no
m\'aximo de las tramas HDLC que queremos recibir. Aunque \'esto puede que
le recuerde al valor de la MTU (unidad m\'axima de transferencia), tienen
poco en com\'un. El MTU es un par\'ametro del dispositivo de red del kernel,
y describe el tama\~no m\'aximo de la trama que el interface es capaz de
soportar. El MRU es m\'as bien un consejo al ordenador remoto para que no
genere ninguna trama m\'as grande que la MRU; no obstante, el interface ha
de ser capaz de recibir tramas de hasta 1500~bytes.


\index{PPP!comprimiendo datos}
Por lo tanto, elegir un MRU no es tanto una cuesti\'on de qu\'e es capaz de
transmitir la conexi\'on, sino de c\'omo conseguir el mejor rendimiento. Si
va a usar la conexi\'on para aplicaciones interactivas, el poner en el
MRU valores tan bajos como 296 es una buena idea, de forma que un paquete
ocasional mayor (digamos, de una sesi\'on de FTP) no haga a su cursor
``saltar''. Para decir al \prog{pppd} que pida un MRU de 296, pondr\'{\i}a la
opci\'on \option{mru 296}. Las MRUs peque\~nas, de todas maneras, s\'olo tienen
sentido si no tiene la compresi\'on de cabecera VJ desactivada (est\'a
activada por defecto).


El \prog{pppd} tambi\'en entiende un par de opciones LCP que configuran
el comportamiento general del proceso de negociaci\'on, como es el
m\'aximo n\'umero de peticiones de configuraci\'on que pueden ser
intercambiadas antes de que se corte la conexi\'on. A menos que sepa
exactamente lo que est\'a haciendo, deber\'a dejar este valor fijo.


Finalmente, hay dos opciones que se aplican a los mensajes de eco del
LCP. El PPP define dos mensajes, ``Petici\'on de Eco'' y ``Respuesta de Eco''.
El \prog{pppd} usa esta caracter\'{\i}stica para comprobar si la conexi\'on
est\'a a\'un operativa. Puede habilitar esto utilizando la opci\'on
\option{lcp-echo-interval} junto con el tiempo en segundos. Si no se
reciben tramas del ordenador remoto en este intervalo, el \prog{pppd}
genera una Petici\'on de Eco, y espera a que el compa\~nero devuelva una
Respuesta de Eco. Si el compa\~nero no produce una respuesta, la conexi\'on
es cortada despu\'es de que se hayan enviado un cierto n\'umero de peticiones.
Este n\'umero puede ser establecido utilizando la opci\'on
\option{lcp-echo-failure}. Por defecto, esta caracter\'{\i}stica
tambi\'en est\'a desactivada.

\index{Protocolo LCP de Control de Enlace (PPP)|)}

\section{Consideraciones Generales sobre Seguridad}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{acceso!PPP}
\index{pppd@\prog{pppd}}
\index{PPP!seguridad}
\index{seguridad!PPP|(}

Un demonio de PPP mal configurado puede ser un peligroso agujero en
la seguridad. Es equivalente a dejar a cualquiera enganchar su
m\'aquina a su red Ethernet (y eso es muy malo). En esta secci\'on,
discutiremos algunas medidas que deber\'{\i}an hacer su configuraci\'on del PPP
segura.


Uno de los problemas del \prog{pppd} es que el configurar el dispositivo
de red y la tabla de encaminamiento requiere los privilegios de \user{root}.
Normalmente resolver\'a esto ejecut\'andolo como {\it setuid} de
\user{root}. A pesar de 
ello, el \prog{pppd} permite a los usuarios establecer varias opciones
de relevancia para la seguridad. Para protegerse contra cualquier ataque
que pueda lanzar alg\'un usuario manipulando estas opciones, se sugiere
que establezca un par de valores por defecto en el fichero global
\file{/etc/ppp/options}, tal como los mostrados en el fichero de ejemplo en
la secci\'on ``\ref{ppp.ppprc}''. Algunos de ellos, como los de las opciones
de autentificaci\'on, no pueden ser despu\'es modificados por el usuario,
as\'{\i} que proporcionan una razonable protecci\'on contra las manipulaciones.


Por supuesto, tambi\'en tiene que protegerse de los sistemas con los que
habla con PPP. Para evitar que otros ordenadores puedan hacerse pasar
por quien no son, debe utilizar siempre alg\'un tipo de autentificaci\'on
con el otro extremo de la comunicaci\'on. Adem\'as, no deber\'{\i}a
permitir a ordenadores desconocidos 
usar cualquier direcci\'on IP que elijan, sino restringirlas a unas pocas.
La siguiente secci\'on tratat\'a sobre estos asuntos.



\section{Autentificaci\'on con PPP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{PPP!autentificaci\'on|(}

\subsection{CHAP frente a PAP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{autorizaciones!con PPP|(}
\index{Protocolo CHAP de Autentificaci\'on por Reto}
\index{Protocolo PAP de Autentificaci\'on por Contrase\~na}
\index{PPP!usando PAP}
\index{PPP!usando CHAP}

Con el PPP, cada sistema puede obligar al otro ordenador a identificarse
usando uno de los dos protocolos de autentificaci\'on disponibles. Estos
son el Protocolo de Autentificación por Contraseña (PAP), y el Protocolo de Autentificación por Reto (CHAP). Cuando se establece una conexi\'on,
cada extremo puede pedir al otro que se autentifique,
independientemente de que sea el llamante o el llamado. M\'as adelante,
utilizar\'e relajadamente `cliente' y `servidor' cuando quiera distinguir
entre el sistema autentificado y el autentificador. Un demonio PPP puede
pedir a la otra m\'aquina autentificaci\'on enviando otra petici\'on m\'as de
configuraci\'on de LCP indicando el protocolo de autentificaci\'on
deseado.


El PAP trabaja b\'asicamente de la misma forma que el procedimiento normal
de {\it login}. El cliente se autentifica a s\'{\i} mismo enviando un nombre de
usuario y una contrase\~na (opcionalmente encriptada) al servidor, la cual
es comparada por el servidor con su base de datos de claves. Esta
t\'ecnica es vulnerable a los intrusos que pueden intentar obtener la
contrase\~na escuchando en una l\'{\i}nea de serie y a otros que hagan
sucesivos intentos de ataque por el m\'etodo de prueba y error.


El CHAP no tiene estos defectos. Con el CHAP, el autentificador (i.e.
el servidor) env\'{\i}a una cadena de ``{\it reto}'' generada aleatoriamente
al cliente, junto a su nombre de ordenador. El cliente utiliza el
nombre del ordenador para buscar la clave apropiada, la combina con
el reto, y encripta la cadena utilizando una funci\'on de codificaci\'on
de un solo sentido. El resultado es devuelto al servidor junto con
el nombre del ordenador cliente. El servidor realiza ahora la misma
computaci\'on, y advierte al cliente si llega al mismo resultado.


Otra caracter\'{\i}stica del CHAP es que no solicita autentificaci\'on al
cliente solamente al comienzo de la sesi\'on, sino que env\'{\i}a retos
a intervalos regulares para asegurarse de que el cliente no ha sido
reemplazado por un intruso, por ejemplo cambiando la l\'{\i}nea telef\'onica.


El \prog{pppd} mantiene las claves secretas para el CHAP y el PAP
en dos ficheros separados, llamados \file{/etc/ppp/chap-secrets} y
\file{pap-secrets} respectivamente. Si introduce un ordenador remoto
en alguno de los dos ficheros, tiene un buen control de cual de los
protocolos CHAP o PAP se utilizar\'a para autentificarnos con \'el
y viceversa.


Por defecto, el \prog{pppd} no pide autentificaci\'on al ordenador
remoto, pero aceptar\'a el autentificarse a s\'{\i} mismo cuando se lo pida
el ordenador remoto. Como el CHAP es mucho m\'as fuerte que el PAP, el
\prog{pppd} intenta usar el anterior siempre que es posible. Si el
otro ordenador no lo acepta, o el \prog{pppd} no encuentra una clave
CHAP para el sistema remoto es su fichero \file{chap-secrets},
cambia al PAP. Si tampoco tiene clave PAP para su compa\~nero,
renunciar\'a a autentificarse. Como consecuencia de esto, se cerrar\'a
la conexi\'on.


Este comportamiento puede ser modificado de varias formas. Por
ejemplo, cuando se a\~nade la palabra \option{auth}, el \prog{pppd}
solicitar\'a al otro ordenador que se autentifique. El \prog{pppd}
aceptar\'a el uso del CHAP o el PAP para ello, siempre y cuando tenga
una clave para su compa\~nero en su base de datos CHAP o PAP
respectivamente. Hay otras opciones para activar o no un
determinado protocolo de autentificaci\'on, pero no las describir\'e
aqu\'{\i}. Puede leer la p\'agina de manual del \file{pppd(8)} para m\'as
detalles.


Si todos los sistemas con los que conversa en PPP est\'an de acuerdo en
autentificarse con usted, deber\'{\i}a poner la opci\'on  \option{auth} en el
fichero global \file{/etc/ppp/options} y definir contrase\~nas para cada
sistema en el fichero \file{chap-secrets}. Si un sistema no acepta el
CHAP, a\~nada una entrada para \'el al fichero \file{pap-secrets}. De
esta forma, puede asegurarse de que ning\'un sistema sin autentificar
se conecta a su ordenador.


Las dos secciones siguientes hablan sobre los dos ficheros de claves del
PPP,  \file{pap-secrets} y \file{chap-secrets}. Est\'an situados en
\file{/etc/ppp} y contienen tripletas de clientes, servidores y
contrase\~nas, seguidas opcionalmente por una lista de direcciones IP.
La interpretaci\'on de los campos de servidor y cliente es distinta en
el CHAP y el PAP, y tambi\'en depende de si nos autentificamos nosotros con
el otro ordenador, o si solicitamos al servidor que se autentifique con
nosotros.



\subsection{El fichero de claves CHAP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{El Protocolo CHAP de Autentificaci\'on por Reto|(}
\index{PPP!usando CHAP|(}

Cuando tiene que autentificarse con alg\'un servidor utilizando el CHAP,
el \prog{pppd} busca en el fichero \file{chap-secrets} una entrada cuyo
campo de cliente sea igual al nombre del ordenador local, y cuyo campo
de servidor sea igual al nombre del ordenador remoto enviado en el reto
del CHAP. Cuando solicita a la otra m\'aquina que se autentifique, los roles
son simplemente al rev\'es: el \prog{pppd} entonces buscar\'a una entrada
que tenga el campo de cliente igual al nombre del ordenador remoto
(enviado en la respuesta del CHAP del cliente), y el campo de
servidor igual al nombre del ordenador local.


El siguiente es un fichero de ejemplo del \file{chap-secrets}
para \host{vlager}:\footnote{
  Las comillas no son parte de la contrase\~na, simplemente sirven para
  proteger el espacio en blanco del interior de la contrase\~na.
}


\begin{tscreen}
\begin{verbatim}
# claves CHAP para vlager.vbrew.com
#
# cliente         servidor          clave                 direccion
#----------------------------------------------------------------------
vlager.vbrew.com  c3po.lucas.com    "Use The Source Luke" vlager.vbrew.com
c3po.lucas.com    vlager.vbrew.com  "riverrun, pasteve"   c3po.lucas.com
*                 vlager.vbrew.com  "VeryStupidPassword"  pub.vbrew.com
\end{verbatim}
\end{tscreen}


Cuando se intenta establecer una conexi\'on PPP con \host{c3po},
\host{c3po} pide a \host{vlager} que se autentifique usando el
CHAP mediante el env\'{\i}o de un reto del CHAP. El \prog{pppd} entonces
examina \file{chap-secrets} buscando una entrada cuyo campo de
cliente sea igual a \host{vlager.vbrew.com} y el campo de servidor
sea \host{c3po.lucas.com},\footnote{
  Este nombre de ordenador se toma del reto del CHAP.
} y encuentra la primera l\'{\i}nea mostrada anteriormente. Entonces produce
la respuesta del CHAP a partir de la cadena del reto y la clave
(\term{Use The Source Luke}), y la env\'{\i}a de vuelta a \host{c3po}.


Al mismo tiempo, el \prog{pppd} produce un reto del CHAP para \host{c3po},
conteniendo una \'unica cadena de reto y su nombre de ordenador completo
\host{vlager.vbrew.com}. \host{c3po} construye una respuesta del CHAP de
la manera que acabamos de decir, y se la devuelve a \host{vlager}. El
\prog{pppd} extrae ahora el nombre del cliente (\host{c3po.vbrew.com})
de la respuesta, y busca en el fichero \file{chap-secrets} una l\'{\i}nea
que tenga \host{c3po} como cliente y \host{vlager} como servidor. La
segunda l\'{\i}nea se corresponde con esto, as\'{\i} que el \prog{pppd} combina el
reto del CHAP y la clave \term{riverrun, pasteve}, las encripta, y
compara el resultado con la respuesta del CHAP de \host{c3po}.


\index{direcci\'on!negociaci\'on con PPP}
\index{IP!direcci\'on!negociaci\'on en PPP}
\index{acceso!restringiendo}
El cuarto campo opcional lista las direcciones IP que son aceptables
por los clientes nombrados en el primer campo. Las direcciones pueden
ser dadas en notaci\'on de cuarteto num\'erico o como nombres de ordenador
que son resueltos posteriormente. Por ejemplo, si \host{c3po} solicita
usar una direcci\'on IP que no est\'a en esta lista durante la negociaci\'on 
IPCP, la petici\'on ser\'a rechazada, y IPCP se desconectar\'a. En el fichero
de ejemplo anterior, \host{c3po} est\'a limitado a poder usar s\'olo su
propia direcci\'on. Si el campo de direcci\'on est\'a vac\'{\i}o, se permitir\'a
cualquier direcci\'on; un valor de ``\keyword{-}'' evita el uso de una
cierta direcci\'on IP con un cliente.


La tercera l\'{\i}nea del fichero \file{chap-secrets} de prueba, permite a
cualquier ordenador establecer un enlace PPP con \host{vlager}, pues
si aparece la expresi\'on ``\keyword{*}'' en los campos de cliente o servidor,
ser\'a v\'alido cualquier nombre. El \'unico requisito es que sepa la
clave, y utiliza la direcci\'on de \host{pub.vbrew.com}. Pueden aparecer
perfectamente entradas con comodines en los nombres en cualquier lugar
del fichero de claves, pues el \prog{pppd} siempre utilizar\'a la entrada
m\'as espec\'{\i}fica que pueda ser aplicada a un par cliente/servidor.


% las claves deber\'{\i}an tener una longitud de 16 caracteres


Hay algunas cosas que decir sobre la manera en que el \prog{pppd} encuentra
los nombres de ordenadores que busca en el fichero de claves. Como se
explic\'o anteriormente, el nombre del ordenador remoto es siempre
proporcionado por el otro ordenador en el paquete de reto o respuesta del CHAP.
El nombre del ordenador local ser\'a obtenido por defecto llamando a la
funci\'on \func{gethostname(2)}. Si ha configurado el nombre del sistema
como el nombre del ordenador sin calificar, entonces tendr\'a que
dar al \prog{pppd} el nombre del dominio a a\~nadir usando la opci\'on
\option{domain}:


\begin{tscreen}
\#{} pppd \ldots domain vbrew.com
\end{tscreen}


Esto a\~nadir\'a el nombre del dominio de la Cervecera a \host{vlager} para
todas las actividades relacionadas con la autentificaci\'on. Otras
opciones que modifican la idea que tiene el \prog{pppd} del nombre del
ordenador local son \option{usehostname} y \option{name}. Cuando da
la direcci\'on IP local en la l\'{\i}nea de comando usando
``\var{local}\option{:}\var{remoto}'', y \var{local} es un nombre en vez
de un cuarteto num\'erico, el \prog{pppd} utilizar\'a \'este como el nombre
local. Para m\'as detalles, lea la p\'agina del manual del \file{pppd(8)}.


\index{PPP!usando CHAP|)}
\index{Protocolo CHAP de Autentificaci\'on por Reto|)}

\subsection{El Fichero de Claves PAP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{PPP!usando PAP|(}

El fichero de claves PAP es muy similar al utilizado por el  CHAP. Los
dos primeros campos siempre contienen un nombre de usuario y
un nombre de servidor; el tercero alberga la clave PAP. Cuando el
sistema remoto env\'{\i}a una petici\'on de autentificaci\'on, el \prog{pppd}
usa la entrada en la que el campo de servidor es igual al nombre del
ordenador local, y el campo de usuario igual al nombre de usuario
enviado en la petici\'on. Cuando se autentifica a s\'{\i} mismo al
otro ordenador, el \prog{pppd} toma la clave a enviar de la l\'{\i}nea
con el nombre de
usuario igual al nombre del usuario local, y con el campo de servidor
igual al nombre del ordenador remoto.


Un fichero de claves PAP sencillo puede parecerse a \'este:

\begin{tscreen}
\begin{verbatim}
# /etc/ppp/pap-secrets
#
# usuario       servidor        clave           direccion
vlager-pap      c3po            cresspahl       vlager.vbrew.com
c3po            vlager          DonaldGNUth     c3po.lucas.com
\end{verbatim}
\end{tscreen}


La primera l\'{\i}nea se usa para autentificarnos a nosotros mismos cuando
hablemos con \host{c3po}. La segunda l\'{\i}nea describe c\'omo un usuario
llamado \host{c3po} tiene que autentificarse con nosotros.


El nombre \host{vlager-pap} de la primera columna es el nombre de usuario
que nosotros mandamos a \host{c3po}. Por defecto, el \prog{pppd} tomar\'a
el nombre del ordenador local como el nombre de usuario, pero tambi\'en
se puede especificar un nombre diferente dando la opci\'on \option{user},
seguida por el nombre deseado.


Para escoger una de las entradas del fichero \file{pap-secrets} para la
autentificaci\'on con el compa\~nero, el \prog{pppd} tiene que saber el
nombre del ordenador remoto. Como no tiene manera de averiguarlo, tiene
que especificarlo en la l\'{\i}nea de comando usando la palabra
\option{remotename}, seguida por el nombre del ordenador remoto. Por
ejemplo, para usar la entrada comentada anteriormente para la
autentificaci\'on con \host{c3po}, tenemos que a\~nadir la siguiente opci\'on
a la l\'{\i}nea de comando del \prog{pppd}:


\begin{tscreen}
\begin{verbatim}
 # pppd ... remotename c3po user vlager-pap
\end{verbatim}
\end{tscreen}


En el cuarto campo (y todos los siguientes), puede especificar qu\'e
direcciones IP est\'an permitidas para ese ordenador particular, de la
misma forma que en el fichero de claves del CHAP. El otro ordenador
s\'olo podr\'a pedir direcciones de esa lista. En el fichero de ejemplo,
obligamos a \host{c3po} a usar su direcci\'on IP aut\'entica.


Dese cuenta de que el PAP es un m\'etodo de autentificaci\'on bastante
d\'ebil, y se recomienda utilizar el CHAP siempre que sea posible. Por
eso, no explicaremos el PAP en gran profundidad aqu\'{\i}; si est\'a
interesado en utilizar el PAP, encontrar\'a algunas caracter\'{\i}sticas
m\'as de \'este comentadas en la p\'agina del manual del \file{pppd(8)}.

\index{PPP!usando PAP|)}

\index{autorizaciones!con PPP|)}
\index{PPP!autentificaci\'on|)}
\index{seguridad!PPP|)}


\section{Configuraci\'on de un Servidor PPP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{PPP!servidor}

Hacer funcionar el \prog{pppd} como servidor es s\'olo cuesti\'on de a\~nadir las
opciones adecuadas en la l\'{\i}nea de comando. Idealmente, crear\'{\i}a una cuenta
especial, digamos \user{ppp}, y le adjudicar\'{\i}a un script o programa como
shell de entrada que llame al \prog{pppd} con estas opciones. Por ejemplo,
podr\'{\i}a a\~nadir la siguiente l\'{\i}nea a \file{/etc/passwd}:


\begin{tscreen}
\begin{verbatim}
ppp:*:500:200:Cuenta PPP Publica:/tmp:/etc/ppp/ppplogin
\end{verbatim}
\end{tscreen}


Por supuesto, puede usar uids y gids diferentes a los mostrados
arriba. Tambi\'en tendr\'a que establecer la contrase\~na para la
cuenta de arriba usando el comando \prog{passwd}.


El script \prog{ppplogin} tendr\'a entonces este aspecto:


\begin{tscreen}
\begin{verbatim}
#!/bin/sh
# ppplogin - script para lanzar el pppd al entrar
mesg n
stty -echo
exec pppd -detach silent modem crtscts
\end{verbatim}
\end{tscreen}


El comando \prog{mesg} deshabilita la opci\'on de que otros usuarios puedan
escribir a la terminal ({\it tty}) usada utilizando, por ejemplo, el comando \prog{write}.
El comando \prog{stty} desactiva el eco de caracteres. Esto es necesario,
pues de otra forma todo lo que el otro ordenador env\'{\i}e le ser\'a devuelto a
modo de eco. La opci\'on del \prog{pppd} m\'as importante de las
incluidas en el script
es \option{-detach}, porque evita que el \prog{pppd} se separe de la terminal
controlada. Si no especific\'asemos esta opci\'on, se ir\'{\i}a a segundo plano,
haciendo que el script del shell terminase. Esto provocar\'{\i}a que la
l\'{\i}nea serie colgase y se perdiera la conexi\'on. La opci\'on
\prog{silent} hace que el \prog{pppd} espere hasta recibir un paquete del
sistema llamante antes de comenzar a enviar. Esto evita la aparici\'on de
{\it timeouts} al transmitir cuando el sistema que nos llama es lento en lanzar
su cliente PPP. La opci\'on \option{modem} hace al \prog{pppd} vigilar la l\'{\i}nea DTR
para ver si el otro sistema ha colgado, y \option{crtscts}
activa el control de flujo por hardware.


Adem\'as de estas opciones, se puede forzar alguna clase de
autentificaci\'on, por ejemplo especificando \option{auth} en la l\'{\i}nea de
comando del \prog{pppd}, o en el fichero de opciones globales. La p\'agina
del manual tambi\'en habla sobre opciones m\'as espec\'{\i}ficas para activar o
desactivar los protocolos de autentificaci\'on individuales.


\index{pppd@\prog{pppd}|)}

\index{PPP|)}
\index{configurando!PPP|)}
