Al igual que el SLIP, el PPP es un protocolo utilizado para enviar datagramas a través de una conexión serie, pero mejora algunas de las carencias del anterior. El PPP permite a las partes comunicantes negociar al principio de la conexión opciones como las direcciones IP y el tamaño máximo de los datagramas, y proporciona mecanismos de autentificación de los clientes. Para cada una de estas capacidades, el PPP tiene un protocolo concreto.

A continuación, describiremos brevemente estos bloques básicos que constituyen el PPP. Esta descripción esta muy lejos de ser completa; si quiere saber mas sobre el PPP, lea sus especificaciones en el RFC 1548, así como en la docena de RFCs que le acompañan.1

En la parte más baja del PPP esta el protocolo de Control de Conexión de Datos de Alto-Nivel, abreviadamente HDLC2 3, que define los limites de las tramas PPP individuales, y proporciona un control de errores de 16 bit. Al contrario de lo que ocurrí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ñadiendo a la trama básica HDLC un campo de control que identifica el tipo de paquete contenido en la misma.

El LCP, Protocolo de Control de Enlace4, es utilizado en la parte mas alta del HDLC para negociar las opciones concernientes a la conexión de datos, tales como la Unidad Máxima de Recepción (MRU) que establece el tamaño máximo del datagrama que cada extremo de comunicación acepta recibir.

_____________________________________________
1 Los RFCs mas relevantes están listados en la Bibliografía al final de este libro.
2 N. del T.: Del inglés High-Level Data Link Control
3 En realidad, el HDLC es un protocolo mucho mas general publicado por la Organización Internacional de Estándares (ISO).
4 N. del T.: Del inglés Link Control Protocol

Un paso importante en la configuración del enlace PPP corresponde a la autentificación de los clientes. Aunque no es obligatorio, es casi un deber para las líneas telefónicas.

Normalmente el servidor pide al cliente que se identifique probando que se sabe alguna clave secreta. Si el llamante se equivoca, la conexión se termina. Con el PPP, las autorizaciones se producen en los dos sentidos; es decir, el que llama también puede pedir al servidor que se autentifique. Estos procedimientos de autentificación son totalmente independientes entre si. Hay dos protocolos distintos, según el tipo de autentificación, los cuales discutiremos mas adelante. Se llaman el Protocolo de Autentificación por Contraseña, o PAP, y el Protocolo de Autentificación por Reto, o CHAP5.

Cada protocolo de red que es encaminado a través de la conexión de datos, como el IP, el Appletalk, etc; es configurado dinámicamente usando el correspondiente Protocolo de Control de Red (NCP). Por ejemplo, para enviar datagramas IP a través del enlace, los dos nodos tienen que negociar en primer lugar que direcciones IP van a utilizar. El protocolo de control utilizado para esto es el IPCP6, el Protocolo de Control del IP.

Aparte de enviar datagramas IP estándar a través del enlace, el PPP también permite la compresión Van Jacobson de las cabeceras en los datagramas IP. Es una técnica para meter las cabeceras de los paquetes TCP en un espacio de tan solo tres bytes. También se utiliza en el CSLIP, y es conocida coloquialmente como compresión de cabeceras VJ. La utilización de la compresión puede negociarse también al comienzo de la conexión gracias al IPCP.

En el Linux, la funcionalidad del PPP esta dividida en dos partes, un controlador de HDLC de bajo nivel situado en el kernel, y el demonio pppd del espacio del usuario que controla los diferentes protocolos de control. La versión actual del PPP para Linux es la linux-ppp-1.0.0, y contiene el modulo PPP para el kernel, el pppd, y un programa llamado chat utilizado para llamar al sistema remoto.

El controlador del PPP para el kernel fue escrito por Michael Callahan. El pppd fue escrito a partir de una implementación gratuita del PPP para máquinas 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.7 El chat fue escrito por Karl Fox.8

_____________________________________________
5 N. del T.: Del inglés Challenge Handshake Authentication Protocol
6 N. del T.: Del inglés IP Control Protocol
7 Los dos autores han dicho que van a estar muy ocupados por bastante tiempo. Así 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.
8 karl@morningstar.com.

Al igual que el SLIP, el PPP esta implementado a través de una disciplina especial para la utilización de las líneas. Para utilizar una línea de serie como enlace PPP, en primer lugar tendrá que establecer la conexión con su módem, como es usual; y posteriormente pasar la lí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ódigo de control de errores de 16 bit), las descompone y las despacha. Actualmente, es capaz de controlar datagramas IP, utilizando opcionalmente la compresión de cabeceras Van Jacobson. Tan pronto como Linux acepte IPX, el controlador PPP será ampliado para poder controlar también los paquetes IPX.

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

Cuando quiere conectarse a Internet a través de un enlace PPP, tiene que configurar las capacidades básicas de red como el dispositivo de loopback y el sistema de resolución de direcciones. Las dos han sido explicadas en los capítulos previos. Hay algunas cosas que es necesario decir sobre la utilización del DNS en un enlace serie; por favor, lea el capítulo del SLIP para mas información.

Como ejemplo introductorio de como establecer una conexión PPP con el pppd, suponga que esta de nuevo en vlager. Ya ha llamado al servidor PPP, c3po, y entrado en la cuenta del usuario ppp. c3po ya ha lanzado su controlador PPP. Después de salir del programa de comunicaciones que utilizo para llamar, se ejecuta el siguiente comando:

Esto cambiará a la línea de serie cua3 al modo PPP y establecerá un enlace IP con c3po. La velocidad de transferencia utilizada en el puerto de serie será de 38400bps. La opción crtscts activa el control de flujo por hardware en el puerto, que es una obligación para velocidades superiores a los 9600 bps.

Lo primero que hace el pppd tras ejecutarse es negociar varias características para el enlace con el extremo remoto utilizando el LCP. Normalmente, el conjunto de opciones que intenta negociar el pppd funcionará, así que no nos meteremos mas con este asunto. Volveremos a tratar el LCP con mas detalle en alguna sección posterior.

Hasta ahora, también hemos asumido que c3po no necesita ninguna autentificación de nosotros, así que la fase configuración habrá sido completada con éxito.

El pppd negociará entonces los parámetros IP con su compañero usando IPCP, el protocolo de control IP. Al no especificar dirección IP alguna, el pppd intentará usar la dirección que se obtiene al resolver el nombre del ordenador local. Decididas las direcciones, cada pppd se lo comunicará al otro extremo.

Normalmente no habrá ningún problema con esta configuración por defecto. Incluso si su máquina esta en una Ethernet, puede utilizar la misma dirección IP tanto para la Ethernet como para el interface PPP. No obstante, el pppd le permite utilizar direcciones diferentes, o incluso pedir a su compañero que utilice alguna dirección específica. Estas opciones serán discutidas mas adelante.

Tras pasar por la fase de configuración IPCP, el pppd configurará la red de su ordenador para utilizar el enlace PPP. En primer lugar, configurará el interface de red PPP como un enlace punto-a-punto, utilizando el ppp0 para el primer enlace PPP que este activo, ppp1 para el segundo, y así sucesivamente. A continuación preparará una entrada de la tabla de encaminamiento que apunte al ordenador del otro extremo del enlace. En el ejemplo anterior, el pppd hará que el encaminamiento de red por defecto apunte a c3po, debido a que lo especificamos con la opción defaultroute.9 Esto provoca que todos los datagramas dirigidos a ordenadores que no estén en su red sean enviados a c3po. Hay un variado número de formas de encaminamiento que acepta el pppd, y las cubriremos en mayor detalle mas adelante.

Antes de que el pppd procese los argumentos de su línea de comandos, echa un vistazo a varios ficheros para establecer sus opciones por defecto. Estos ficheros pueden contener cualquier argumento de línea de comando valido, distribuido a través de un cierto número de líneas. Los comentarios se escriben tras el símbolo de almohadillado (#).

El primer fichero de opciones es el /etc/ppp/options, que es leído cada vez que el 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ían comprometer la seguridad del sistema. Por ejemplo, para hacer que el PPP necesite algún tipo de autentificación del otro sistema, añadiría la opción auth a este fichero. Esta opción no puede ser evitada por el usuario, de forma que se hace totalmente imposible el establecer una conexión PPP con cualquier sistema que no este en nuestras bases de datos para la autentificación.

_____________________________________________
9 El encaminamiento por defecto es instalado solamente si no hay ninguno establecido de antes.

El otro fichero de opciones, que es leído después del /etc/ppp/options, es el .ppprc situado en el directorio home del usuario. Permite que cada usuario especifique su propio conjunto de opciones por defecto.

Un fichero /etc/ppp/options de ejemplo puede parecerse a éste:

# Opciones globales para el pppd de vlager.vbrew.com
auth # obligar a autentificación
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

Las dos primeras opciones se utilizan para la autentificación y serán explicadas a continuación. La expresión lock hace que el pppd utilice el método de bloqueo de dispositivos de UUCP. De esta manera, cada proceso que accede a un dispositivo serie, por ejemplo el /dev/cua3, crea un fichero de bloqueo llamado LCK..cua3 en el directorio de spool del UUCP para señalizar que ese dispositivo esta siendo usado. Esto es necesario para evitar que otros programas, como pueden ser el minicom o el uucico, abran el dispositivo de serie mientras éste es usado por el PPP.

La razón de poner estas opciones en el fichero de configuración global es que éstas 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án ser pasadas por alto mas tarde; un ejemplo de esto es la cadena connect.

Uno de los problemas que puede haberle dado el ejemplo anterior es que tenia que establecer la conexión manualmente antes de poder ejecutar el pppd. Al contrario que el dip, el pppd no tiene su propio lenguaje de scripts para llamar al sistema remoto y entrar en él, sino que confía en otro programa externo para que haga esto. El comando que tiene que ser ejecutado puede dársele al pppd con la opción connect en la línea de comando. El pppd redirigirá la entrada y salida estándar de comandos a la línea de serie. Un programa útil para esto es el expect, escrito por Don Libes. Tiene un lenguaje muy potente basado en el Tcl, y fue diseñado exactamente para este tipo de aplicación.

El paquete pppd incluye un programa similar llamado chat que le permite especificar un script del estilo de los de UUCP. Básicamente, 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ípico script del chat:

Esto le indica al chat que espere a que el sistema remoto le envíe el mensaje de petición de usuario y entonces le devuelve el nombre del usuario b1ff. Solo esperamos por ogin: para que no importe si el mensaje de login empiece por l mayúscula o minúscula, o si llega con basura. La siguiente cadena es una cadena esperada que hace que el chat espere al mensaje de petición de contraseña y la envíe nuestra contraseña como respuesta.

Esto es básicamente lo que tienen los scripts del chat. Un script completo para llamar a un servidor PPP debería, además, incluir los comandos apropiados para el módem. Suponga que su módem entiende los comandos Hayes, y que el número de teléfono del servidor es el 318714. En ese caso, la línea completa del chat para que pudiésemos establecer una conexión con c3po seria

Por definición, la primera cadena que damos al chat tiene que ser una cadena esperada, pero como el módem no dirá nada hasta que hablemos conel, hacemos que el chat la ignore especificando una cadena vacía. Continuamos enviando ATZ, el comando de inicialización para los módems compatibles Hayes, y esperamos a que nos responda con OK. La siguiente cadena envía al chat el comando de marcado junto con el número de teléfono, y espera a que aparezca el mensaje CONNECT como respuesta. Esto esta seguido de otra cadena vacía otra vez, porque ahora no queremos enviar nada, sino esperar a que aparezca el mensaje de petición de login. El resto del script del chat funciona exactamente como antes.

La opción -v hace que el chat capture todas las actividades hacia la facilidad local2 del demonio syslog.10

El escribir el script de chat directamente en la línea de comando implica un cierto riesgo, pues los usuarios pueden ver la línea de comando de un proceso con el comando ps. Puede evitar esto colocando el script del chat en un fichero, por ejemplo llamado dial-c3po. Entonces, podrá hacer al chat leer el script del fichero en vez de la línea de comando utilizando la opción -f, seguida por el nombre del fichero. Por lo tanto la invocación completa al pppd tendrá ahora un aspecto como éste:

_____________________________________________
10 Si edita el syslog.conf para redirigir estos mensajes a un fichero, asegúrese de que este fichero no pueda ser leído por cualquiera, pues el chat también captura todo el script de entrada por defecto - incluyendo las contraseñas.

Además de la opción connect que se refiere al script de llamada, hemos añadido dos opciones mas a la línea de comando: -detach, que le indica al pppd que no se separe de la consola ni se vuelva proceso de segundo plano. La palabra módem activa algunas acciones especificas para módem sobre el dispositivo de serie, como colgar la línea antes y después de la llamada. Si no utiliza esta opción, el pppd no se preocupara de la línea DCD del puerto, y por lo tanto no podrá detectar si el extremo remoto cuelga de forma imprevista.

Los ejemplos anteriores eran bastante simples; el chat permite el uso de scripts mucho mas complejos. Una característica muy útil es la capacidad de especificar cadenas frente a las cuales parar el chat con un error. Unas cadenas típicas para parar pueden ser mensajes como BUSY o NO CARRIER, que son los que su módem produce cuando el número al que llama comunica o no descuelga. Para hacer que el chat las reconozca inmediatamente en vez de esperar, puede introducirlas al principio del script utilizando la opción ABORT:

De una forma parecida, puede variar el valor del tiempo de espera para algunas partes de los scripts de chat insertando opciones TIMEOUT. Para mas detalles, vea la página de manual del chat(8).

Algunas veces, también querrá disponer de algún tipo de ejecución condicional de algunas partes del script de chat. Por ejemplo, cuando reciba el mensaje de petición de login desde el extremo remoto, puede que quiera enviar un BREAK, o un retorno de carro.

Puede conseguir esto añadiendo un sub-script a la parte esperada del script. Consiste en una secuencia de cadenas de enví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án ligados no es recibida a tiempo. Para este ejemplo, modificaríamos el script del chat de la siguiente manera:

Ahora, cuando el 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 continua como usualmente y si no, termina con un error.

Por defecto, el pppd registrará todos los avisos y mensajes de error gracias a las facilidades daemon del syslog. Tiene que añadir una entrada al syslog.conf que redirija esto a un fichero, o incluso a la consola, pues de otra forma el syslog simplemente desechara estos mensajes. La siguiente entrada envía todos los mensajes a /var/log/ppp-log:

Si la configuración de su PPP no funciona, echar un vistazo a este fichero le debería dar una primera pista de que es lo que va mal. Si esto no le ayuda, también puede activar la salida extra de depuración utilizando la opción debug. Esto hace que el pppd registre los contenidos de todos los paquetes de control enviados o recibidos a syslog. Todos los mensajes irán a la facilidad daemon.

Finalmente, la opción mas drástica es el activar la depuración a nivel de kernel llamando al pppd con la opción kdebug. Esto es seguido por un argumento numérico que es el O exclusivo (xor) de los siguientes valores: 1 para mensajes de depuración 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ón a nivel de kernel, tiene que, o bien ejecutar un demonio syslogd que lea el fichero /proc/kmsg, o si no el demonio klogd. Cualquiera de los dos dirige la depuración del kernel a la facilidad kernel del syslogd.

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

El pppd le da gran control sobre que opciones intentara negociar el IPCP. Puede ajustar esto a través de varias opciones en la línea de comandos de las que hablamos a continuación.

En el ejemplo anterior, hacíamos que el pppd llamase a c3po y estableciera una conexión IP. No nos preocupábamos de elegir una dirección IP particular en ninguno de los extremos de la conexión. En vez de ello, tomábamos la dirección de vlager como la dirección IP local, y dejábamos a c3po darse su propia dirección. Algunas veces, sin embargo, es útil el tener control sobre la dirección utilizada por alguno de los extremos de la conexión. El pppd soporta diferentes posibilidades sobre este aspecto.

Para pedir direcciones particulares, normalmente de al pppd la siguiente opción:

donde dir_local y dir_remota pueden ser especificadas en notación de cuádruplas numéricas o como nombres de ordenador. 11 Esto hace al pppd intentar usar la primera dirección como su propia dirección IP, y la segunda como la de su compañero. Si el compañero rechaza alguna de ellas durante la negociación IPCP, no se establecerá ninguna conexión IP.12

Si solo quiere establecer la dirección local, y aceptar cualquier dirección que utilice el compañero, simplemente deseche la parte de la dir_remota. Por ejemplo, para hacer a vlager usar la dirección IP 130.83.4.27 en vez de la suya propia, le escribiría 130.83.4.27: en la línea de comando. De forma similar, para establecer la dirección remota únicamente, dejaría el campo de la dir_local en blanco. Por defecto, el pppd utilizara entonces la dirección asociada al nombre de su ordenador.

Algunos servidores PPP que sirven a muchos clientes asignan direcciones dinámicamente: las direcciones son asignadas a los sistemas solo cuando llaman, y son reclamadas de nuevo una vez que se desconecta. Cuando llame a uno de éstos servidores, debe asegurarse de que el pppd no solicita una dirección IP particular, sino que acepta la dirección que el servidor le pide que utilice. Esto quiere decir que no tiene que poner el argumento dir_local.

Además, tendrá que utilizar la opción noipdefault, que hace que el pppd espere a que el compañero le proporcione la dirección IP en vez de utilizar la dirección IP del ordenador local.

Tras configurar el interface de red, el pppd preparará un encaminamiento que solamente le sirve para comunicarse con el otro extremo. Si el ordenador remoto esta en una red de área local, seguramente usted deseara conectar también con los ordenadores que están "detrás" de él; para eso, se ha de configurar un encaminamiento de red adecuado.

_____________________________________________
11 El utilizar nombres de ordenador en esta opción tiene algunas consecuencias a la hora de la autentificación utilizando CHAP. Puede echar un vistazo a la sección sobre CHAP más adelante.12 Puede permitir al otro PPP sobrescribir sus ideas de direcciones IP dando al pppd las opciones
ipcp-accept-local e ipcp-accept-remote. Eche un vistazo a la página del manual para más detalles.

Ya hemos visto antes que se puede pedir al pppd que configure el encaminamiento por defecto utilizando la opción defaultroute. Esta opción es muy útil si el servidor PPP al que llama va a actuar como su pasarela a Internet.

El caso contrario, cuando su sistema actúa como un gateway para un solo ordenador, es también relativamente fácil de llevar a cabo. Por ejemplo, imagine a algún empleado de la Cervecera Virtual cuyo ordenador de casa se llama loner. Cuando este conectando a vlager a través de PPP, él utiliza una dirección de la subred de la Cervecera. Podremos dar al pppd del ordenador vlager la opción proxyarp, que instalara una entrada proxy-ARP para el ordenador loner. Esto hará que loner sea automáticamente accesible desde todos los ordenadores de la Cervecera y la Vinatera.

De cualquier manera, las cosas no son siempre tan fáciles como esto, por ejemplo cuando intentamos unir dos redes de área local. Esto requiere normalmente el añadir una ruta de red especifica, porque estas redes tendrán ya sus propios encaminamientos por defecto. Por otra parte, el tener a los dos extremos de comunicación utilizando la conexión PPP como encaminamiento por defecto generaría un ciclo sin fin, donde los paquetes con destinos desconocidos rebotarían entre los dos ordenadores hasta que su tiempo de vida (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úmero de red IP 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és de PPP para actualizar las bases de datos de clientes, etc. De nuevo, vlager actuara como pasarela; la otra máquina se llama sub-etha y tiene una dirección IP de 191.72.3.1.

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

donde interface se refiere al interface de red usado, dispositivo es la ruta al dispositivo serie utilizado, (/dev/tty si se utiliza la salida y entrada estándar), y velocidad es la velocidad del dispositivo. dir_local y dir_remota nos dan las direcciones IP usadas en dos extremos de la conexión en notación de cuarteto numérico. En nuestro caso, el script ip-up puede contener el siguiente fragmento de código:

De una forma análoga, /etc/ppp/ip-down se utiliza para deshacer todas las acciones de ip-up después de que la conexión PPP ha sido cortada.

A pesar de todo, la tabla de encaminamiento aun no esta completa. Hemos configurado las entradas de la tabla de encaminamiento para las dos ordenadores con PPP, pero hasta ahora, todos los demás ordenadores de las dos redes no saben nada sobre la conexión PPP.

Esto no es un gran problema si todos los ordenadores de la sucursal tienen su encaminamiento por defecto encaminado a sub-etha, y todos los ordenadores de la Cervecera encaminan hacia vlager por defecto. Si éste no fuera el caso, su única posibilidad normalmente será usar un demonio de encaminamiento como el gated. Tras crear el encaminamiento de la red en vlager, el demonio de encaminamiento pasara el nuevo encaminamiento a todos los ordenadores de las redes dependientes de ésta.

Anteriormente, ya hemos tratado sobre el LCP, el protocolo de control de enlace (Link Control Protocol), que se utiliza para negociar las características de la conexión y comprobarla. 

Las dos opciones mas importantes que pueden ser negociadas por el LCP son la unidad máxima de recepción (MRU) y el mapa de caracteres de control asíncronos. También hay varias opciones de configuración LCP mas, pero son demasiado especificas como para comentarlas aquí. Eche un vistazo a la RFC 1548 para ver una descripción de éstas.

El mapa de caracteres de control asíncronos, también conocido como el mapa asíncrono, es usado en enlaces asíncronos, como las líneas telefónicas, para identificar los caracteres de control que deben de ser reemplazados por una secuencia especifica de dos caracteres13. Por ejemplo, puede que quiera evitar los caracteres XON y XOFF utilizados con el control de flujo hardware activado, pues algún módem mal configurado puede parar hasta que reciba un XOFF. Otro candidato puede ser Ctrl-] (el carácter de escape del telnet). El PPP le permite rehuir de cualquiera de los caracteres con códigos ASCII comprendidos entre 0 y 31 especificándolos en el mapa asíncrono.

_____________________________________________
13 N. del T.: Estos caracteres se conocen como rehuidos

El mapa asíncrono (async map) es un mapa de bits de 32 bits de ancho, y cuyo bit menos significativo corresponde al carácter ASCII NUL, y cuyo bit mas significativo corresponde al ASCII 31. Si un bit se pone a 1, indica que el carácter correspondiente debe de ser rehuido antes de ser enviado a través de la conexión. Inicialmente, el mapa asíncrono se establece como 0xffffffff, lo que significa que todos los caracteres de control serán rehuidos.

Para decir al otro ordenador que no tiene que rehuir de todos los caracteres de control sino solo de algunos, puede establecer un nuevo mapa asíncrono al pppd utilizando la opción asyncmap. Por ejemplo, si solo ^S y ^Q (los códigos ASCII 17 y 19, normalmente utilizados para XON y XOFF) deben de ser rehuidos, utilice la siguiente opción:

La unidad máxima de recepción, o MRU, señaliza al otro extremo el tamaño máximo de las tramas HDLC que queremos recibir. Aunque esto puede que le recuerde al valor de la MTU (unidad máxima de transferencia), tienen poco en común. El MTU es un parámetro del dispositivo de red del kernel, y describe el tamaño máximo de la trama que el interface es capaz de soportar. El MRU es mas bien un consejo al ordenador remoto para que no genere ninguna trama mas grande que la MRU; no obstante, el interface ha de ser capaz de recibir tramas de hasta 1500 bytes.

Por lo tanto, elegir un MRU no es tanto una cuestión de que es capaz de transmitir la conexión, sino de como conseguir el mejor rendimiento. Si va a usar la conexión 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ón de FTP) no haga a su cursor "saltar". Para decir al pppd que pida un MRU de 296, pondría la opción mru 296.

Las MRUs pequeñas, de todas maneras, solo tienen sentido si no tiene la compresión de cabecera VJ desactivada (esta activada por defecto).

El pppd también entiende un par de opciones LCP que configuran el comportamiento general del proceso de negociación, como es el máximo número de peticiones de configuración que pueden ser intercambiadas antes de que se corte la conexión. A menos que sepa exactamente lo que esta haciendo, deberá dejar este valor fijo.

Finalmente, hay dos opciones que se aplican a los mensajes de eco del LCP. El PPP define dos mensajes, "Petición de Eco" y "Respuesta de Eco". El pppd usa esta característica para comprobar si la conexión esta aun operativa. Puede habilitar esto utilizando la opción lcp-echo-interval junto con el tiempo en segundos. Si no se reciben tramas del ordenador remoto en este intervalo, el pppd genera una Petición de Eco, y espera a que el compañero devuelva una Respuesta de Eco. Si el compañero no produce una respuesta, la conexión es cortada después de que se hayan enviado un cierto número de peticiones. Este número puede ser establecido utilizando la opción lcp-echo-failure. Por defecto, esta característica también esta desactivada.

Un demonio de PPP mal configurado puede ser un peligroso agujero en la seguridad. Es equivalente a dejar a cualquiera enganchar su máquina a su red Ethernet (y eso es muy malo). En esta sección, discutiremos algunas medidas que deberían hacer su configuración del PPP segura.

Uno de los problemas del pppd es que el configurar el dispositivo de red y la tabla de encaminamiento requiere los privilegios de root. Normalmente resolverá esto ejecutándolo como setuid de root. A pesar de ello, el pppd permite a los usuarios establecer varias opciones de relevancia para la seguridad. Para protegerse contra cualquier ataque que pueda lanzar algún usuario manipulando estas opciones, se sugiere que establezca un par de valores por defecto en el fichero global /etc/ppp/options, tal como los mostrados en el fichero de ejemplo en la sección "Utilización de los Ficheros de Opciones". Algunos de ellos, como los de las opciones de autentificación, no pueden ser después modificados por el usuario, así que proporcionan una razonable protección contra las manipulaciones.

Por supuesto, también 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ún tipo de autentificación con el otro extremo de la comunicación. Además, no debería permitir a ordenadores desconocidos usar cualquier dirección IP que elijan, sino restringirlas a unas pocas. La siguiente sección tratará sobre estos asuntos.

Con el PPP, cada sistema puede obligar al otro ordenador a identificarse usando uno de los dos protocolos de autentificación 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ón, cada extremo puede pedir al otro que se autentifique, independientemente de que sea el llamante o el llamado. Mas adelante, utilizare relajadamente 'cliente' y 'servidor' cuando quiera distinguir entre el sistema autentificado y el autentificador. Un demonio PPP puede pedir a la otra máquina autentificación enviando otra petición mas de configuración de LCP indicando el protocolo de autentificación deseado.

El PAP trabaja básicamente de la misma forma que el procedimiento normal de login. El cliente se autentifica a si mismo enviando un nombre de usuario y una contraseña (opcionalmente encriptada) al servidor, la cual es comparada por el servidor con su base de datos de claves. Esta técnica es vulnerable a los intrusos que pueden intentar obtener la contraseña escuchando en una línea de serie y a otros que hagan sucesivos intentos de ataque por el método de prueba y error.

El CHAP no tiene estos defectos. Con el CHAP, el autentificador (i.e. el servidor) envía una cadena de "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ón de codificación de un solo sentido. El resultado es devuelto al servidor junto con el nombre del ordenador cliente. El servidor realiza ahora la misma computación, y advierte al cliente si llega al mismo resultado.

Otra característica del CHAP es que no solicita autentificación al cliente solamente al comienzo de la sesión, sino que envía retos a intervalos regulares para asegurarse de que el cliente no ha sido reemplazado por un intruso, por ejemplo cambiando la línea telefónica.

El pppd mantiene las claves secretas para el CHAP y el PAP en dos ficheros separados, llamados /etc/ppp/chap-secrets y 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 utilizara para autentificarnos conel y viceversa.

Por defecto, el pppd no pide autentificación al ordenador remoto, pero aceptara el autentificarse a si mismo cuando se lo pida el ordenador remoto. Como el CHAP es mucho mas fuerte que el PAP, el pppd intenta usar el anterior siempre que es posible. Si el otro ordenador no lo acepta, o el pppd no encuentra una clave CHAP para el sistema remoto es su fichero chap-secrets, cambia al PAP. Si tampoco tiene clave PAP para su compañero, renunciará a autentificarse. Como consecuencia de esto, se cerrará la conexión.

Este comportamiento puede ser modificado de varias formas. Por ejemplo, cuando se añade la palabra auth, el pppd solicitara al otro ordenador que se autentifique. El pppd aceptara el uso del CHAP o el PAP para ello, siempre y cuando tenga una clave para su compañero en su base de datos CHAP o PAP respectivamente. Hay otras opciones para activar o no un determinado protocolo de autentificación, pero no las describiré aquí. Puede leer la página de manual del pppd(8) para mas detalles.

Si todos los sistemas con los que conversa en PPP están de acuerdo en autentificarse con usted, debería poner la opción auth en el fichero global /etc/ppp/options y definir contraseñas para cada sistema en el fichero chap-secrets. Si un sistema no acepta el CHAP, añada una entrada para él al fichero pap-secrets. De esta forma, puede asegurarse de que ningún sistema sin autentificar se conecta a su ordenador.

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

Cuando tiene que autentificarse con algún servidor utilizando el CHAP, el pppd busca en el fichero 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áquina que se autentifique, los roles son simplemente al revés: el pppd entonces buscara 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 chap-secrets para vlager:14

Cuando se intenta establecer una conexión PPP con c3po, c3po pide a vlager que se autentifique usando el CHAP mediante el envío de un reto del CHAP. El pppd entonces examina chap-secrets buscando una entrada cuyo campo de cliente sea igual a vlager.vbrew.com y el campo de servidor sea c3po.lucas.com,15 y encuentra la primera línea mostrada anteriormente. Entonces produce la respuesta del CHAP a partir de la cadena del reto y la clave (Use The Source Luke), y la envía de vuelta a c3po.

Al mismo tiempo, el pppd produce un reto del CHAP para c3po, conteniendo una única cadena de reto y su nombre de ordenador completo vlager.vbrew.com. c3po construye una respuesta del CHAP de la manera que acabamos de decir, y se la devuelve a vlager.

El pppd extrae ahora el nombre del cliente (c3po.vbrew.com) de la respuesta, y busca en el fichero chap-secrets una línea que tenga c3po como cliente y vlager como servidor. La segunda línea se corresponde con esto, así que el pppd combina el reto del CHAP y la clave riverrun, pasteve, las encripta, y compara el resultado con la respuesta del CHAP de c3po.

_____________________________________________
14 Las comillas no son parte de la contraseña, simplemente sirven para proteger el espacio en blanco del interior de la contraseña.
15 Este nombre de ordenador se toma del reto del CHAP.

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ón de cuarteto numérico o como nombres de ordenador que son resueltos posteriormente. Por ejemplo, si c3po solicita usar una dirección IP que no esta en esta lista durante la negociación IPCP, la petición será rechazada, y IPCP se desconectara. En el fichero de ejemplo anterior, c3po esta limitado a poder usar solo su propia dirección. Si el campo de dirección está vacío, se permitirá cualquier dirección; un valor de "-" evita el uso de una cierta dirección IP con un cliente.

La tercera línea del fichero chap-secrets de prueba, permite a cualquier ordenador establecer un enlace PPP con vlager, pues si aparece la expresión "*" en los campos de cliente o servidor, será valido cualquier nombre. El único requisito es que sepa la clave, y utiliza la dirección de pub.vbrew.com. Pueden aparecer perfectamente entradas con comodines en los nombres en cualquier lugar del fichero de claves, pues el pppd siempre utilizará la entrada mas especifica que pueda ser aplicada a un par cliente/servidor.

Hay algunas cosas que decir sobre la manera en que el pppd encuentra los nombres de ordenadores que busca en el fichero de claves. Como se explicó 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á obtenido por defecto llamando a la función gethostname(2). Si ha configurado el nombre del sistema como el nombre del ordenador sin calificar, entonces tendrá que dar al pppd el nombre del dominio a añadir usando la opción domain:

Esto añadirá el nombre del dominio de la Cervecera a vlager para todas las actividades relacionadas con la autentificación. Otras opciones que modifican la idea que tiene el pppd del nombre del ordenador local son usehostname y name. Cuando da la dirección IP local en la línea de comando usando "local :remoto ", y local es un nombre en vez de un cuarteto numérico, el pppd utilizará éste como el nombre local. Para mas detalles, lea la página del manual del pppd(8).

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ía una petición de autentificación, el 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ón. Cuando se autentifica a si mismo al otro ordenador, el pppd toma la clave a enviar de la lí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 éste:

# /etc/ppp/pap-secrets
#
# usuario servidor clave dirección
vlager-pap c3po cresspahl vlager.vbrew.com
c3po vlager DonaldGNUth c3po.lucas.com

La primera línea se usa para autentificarnos a nosotros mismos cuando hablemos con c3po. La segunda línea describe como un usuario llamado c3po tiene que autentificarse con nosotros.

El nombre vlager-pap de la primera columna es el nombre de usuario que nosotros mandamos a c3po. Por defecto, el pppd tomara el nombre del ordenador local como el nombre de usuario, pero también se puede especificar un nombre diferente dando la opción user, seguida por el nombre deseado.

Para escoger una de las entradas del fichero pap-secrets para la autentificación con el compañero, el pppd tiene que saber el nombre del ordenador remoto. Como no tiene manera de averiguarlo, tiene que especificarlo en la línea de comando usando la palabra remotename, seguida por el nombre del ordenador remoto. Por ejemplo, para usar la entrada comentada anteriormente para la autentificación con c3po, tenemos que añadir la siguiente opción a la línea de comando del pppd:

En el cuarto campo (y todos los siguientes), puede especificar que direcciones IP están permitidas para ese ordenador particular, de la misma forma que en el fichero de claves del CHAP. El otro ordenador solo podrá pedir direcciones de esa lista. En el fichero de ejemplo, obligamos a c3po a usar su dirección IP autentica.

Dése cuenta de que el PAP es un método de autentificación bastante débil, y se recomienda utilizar el CHAP siempre que sea posible. Por eso, no explicaremos el PAP en gran profundidad aquí; si esta interesado en utilizar el PAP, encontrará algunas características mas de éste comentadas en la página del manual del pppd(8).

Hacer funcionar el pppd como servidor es solo cuestión de añadir las opciones adecuadas en la línea de comando. Idealmente, crearía una cuenta especial, digamos ppp, y le adjudicaría un script o programa como shell de entrada que llame al pppd con estas opciones. Por ejemplo, podría añadir la siguiente línea a /etc/passwd:

Por supuesto, puede usar uids y gids diferentes a los mostrados arriba. También tendrá que establecer la contraseña para la cuenta de arriba usando el comando passwd.

El script ppplogin tendrá entonces este aspecto:

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

Además de estas opciones, se puede forzar alguna clase de autentificación, por ejemplo especificando auth en la línea de comando del pppd, o en el fichero de opciones globales. La página del manual también habla sobre opciones más especificas para activar o desactivar los protocolos de autentificación individuales.