garl8

 

Capítulo 8


El Protocolo Punto-a-Punto (PPP)

 

8.1 Desenredando las Pes
8.2 PPP en Linux
8.3 Conexiones con pppd
8.4 Los Ficheros de Opciones
8.5 Realización de la Llamada con chat
8.6 Depuración de la Configuración PPP
8.7 Opciones de Configuración IP

8.7.1 Elección de las Direcciones IP
8.7.2 Encaminamiento a través de una Conexión PPP

8.8 Opciones de Control de Enlace
8.9 Consideraciones Generales sobre Seguridad
8.10 Autentificación con PPP

8.10.1 CHAP frente a PAP
8.10.2 El fichero de claves CHAP
8.10.3 El Fichero de Claves PAP

8.11 Configuración de un Servidor PPP

8.1 Desenredando las Pes

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.

 

8.2 PPP en Linux

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.

 

8.3 Conexiones con 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:

# pppd /dev/cua3 38400 crtscts defaultroute

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.

 

8.4 Los Ficheros de Opciones

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.

 

8.5 Realización de la Llamada con chat

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:

ogin: b1ff ssword: s3kr3t

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

$ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN

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:

# pppd connect "chat -f dial-c3po" /dev/cua3 38400 -detach \
crtscts módem defaultroute

_____________________________________________
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:

$ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...

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:

ogin:-BREAK-ogin: ppp ssword: GaGariN

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.

 

8.6 Depuración de la Configuración PPP

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:

daemon.* /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.

 

8.7 Opciones de Configuración IP

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.

 

8.7.1 Elección de las Direcciones IP

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:

dir_local :dir_remota

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.

 

8.7.2 Encaminamiento a través de una Conexión PPP

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:

ip-up interface dispositivo velocidad dir_local dir_remota

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:

#!/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