Servidor de acceso remoto mediante PPP (ejemplo)

Santiago González Herrero, sgonzale@bigfoot.com
Agosto 1999

Este documento tan sólo pretende el equivalente a unos apuntes de la información mínima necesaria para configurar un servidor de acceso remoto por PPP mediante Linux. Caso de necesitar una información más exhaustiva, por favor visita la espléndida guía: Linux Dialin Server Setup Guide de Josh Gentry. Este documento no es más que el ejemplo de una realización basada en esa guía.

En Mayo de 1999 tuve la necesidad de conectar una red remota a la intranet de mi centro de trabajo para dos muestras de "Enseñanza" y "Formación y Empleo" respectivamente que tuvieron lugar en Oviedo y Avilés en las que el Instituto en que trabajo: IES Valliniello de Avilés (Asturias) estaría representado. En esas muestras se pretendía conectar una red de ordenadores (en el stand) a la intranet de nuestro centro, de forma que los visitantes se sentaran en los puestos y se encontraran en la misma situación que los alumnos del centro, con posibilidad de acceder a nuestros servidores internos y poder practicar en las mismas condiciones. Una posibilidad sería una videoconferencia entre un ordenador del stand y otro en nuestras aulas, acceder al servidor WWW local, utilizar el correo interno, nuestros servidores IRC, FTP, de noticias, etc.

Para ello, configuré un servidor de acceso remoto mediante PPP en un sistema Linux del centro, y en la red remota, el ordenador que conectado a la línea RDSI era también un Linux con el encaminamiento IP activado.

La conexión se realizó mediante RDSI, pero al utilizar adaptadores externos, la configuración es igual que si  hubiera usado módems analógicos normales (de hecho no he usado nunca una tarjeta RDSI). La única diferencia es que he necesitado tarjetas serie de alta velocidad.

Nota Importante: Este documento es una chuleta para un administrador de redes habituado a trabajar con Linux. En ningún caso pretende ser un tutorial. Como se puede comprobar hay muchos aspectos que no se tocan (compilación del kernel, del puerto serie, módem, nociones TCP/IP, etc). Para un manual más exhaustivo, te vuelvo a remitir a la guía de Josh Gentry.

Introducción

Un servidor de acceso remoto es un equipo que permite a otro conectarse a él mediante una línea telefónica a través de un módem. Aunque a los efectos del protocolo PPP, los dos extremos de la comunicación son equivalentes, denominaremos servidor PPP aquél equipo que recibe la llamada y, en su caso, valida la contraseña facilitada por el otro,  y llamaremos cliente al equipo que efectúa la llamada y solicita el establecimiento de la conexión.

Nuestro servidor PPP, permitirá la conexión de equipos que usen Linux como aquéllos  que usen Windows mediante el acceso telefónico a redes.

Requerimientos

Para poder recibir llamadas, obviamente debemos tener un módem conectado a un puerto serie, soporte en el kernel, directamente incluido o como módulo, para el protocolo PPP, así como los paquetes pppd y mgetty+sendfax. Este ejemplo está comprobado con las versiones incluidas en la distribución Red Hat 5.2

/etc/inittab

Para que el servidor atienda a otro terminal (en este caso la línea serie en que hayamos conectado el módem) es necesario informar de ello al sistema. Esto se hace en el fichero /etc/inittab. Este fichero indica qué procesos se ponen en marcha durante la operación de arranque del sistema. Si nuestro módem lo hemos conectado a la puerta serie ttyS1 (COM2), incluiremos la siguiente línea en el fichero:

    S2:2345:respawn:/sbin/mgetty ttyS1

Donde:

S2  Abreviatura del nombre de dispositivo que usará init.
2345  son los runlevel para los que se activará la atención a este terminal
respawn Indica a init que la entrada está activa.
/sbin/mgetty Es el programa que atenderá al terminal, mgetty puede detectar llamadas de FAX o de datos por PPP, y actuar en consecuencia. Las opciones están en /etc/mgetty+sendfax/mgetty.config
Una vez editado /etc/inittab, ejecutar la orden "kill -1 1" para forzar a que el proceso init vuelva a leerlo.
 

/etc/mgetty+sendfax/login.config

Este es uno de los ficheros de configuración del programa mgetty. Este programa es el que, según indica el /etc/inittab, recibirá el control cuando aparezca algo por el puerto serie /dev/ttyS1 (según nuestro ejemplo). Es decir, en cuanto llegue una llamada, mgetty se hará cargo de ella de acuerdo con la configuración de este fichero.

       /AutoPPP/ -     a_ppp   /usr/sbin/pppd file /etc/ppp/options.servidor

Una vez configurado esto, mgetty lanzará pppd automáticamente cuando reciba una petición de configuración LCP del otro extremo de la línea. La opción file indica a pppd que obtenga las opciones del fichero /etc/ppp/options.servidor en vez del habitual /etc/ppp/options.
 

/etc/mgetty+sendfax/mgetty.config

Este es un fichero de configuración particular para mgetty (opciones no incluidas en la llamada a mgetty de  inittab)

        # Mi modem en /dev/ttyS1
        port ttyS1
            debug 6
            speed 115200
            data-only yes
            init-chat "" \d+++\dAT&FH0 OK
            rings 1

donde:
    port ttyS1                                                indica el puerto al que hace referencia esta configuración
        debug 6                                               Nivel de depuración en ficheros de log
        speed 115200                                     Velocidad de conexión
        data-only yes                                       No fax, sólo datos
        init-chat "" \d+++\dAT&FH0 OK        Cadena de inicialización y descuelge
        rings 1                                                  Número de rings antes de descolgar
 

/etc/ppp/options.servidor

Es el archivo en el que se almacenan las opciones que se pasan al programa pppd para su ejecución, la diferencia más importante entre un servidor y un cliente, es que el servidor, normalmente, entrega una IP al cliente y le pregunta su contraseña para validarla en su base de datos local /etc/passwd. RedHat 5.2 y 6.0 están preparados para usar /etc/shadow, pero es posible que en otros sistemas no sea así, por lo que habrá que recompilar las fuentes de PPP con la orden:

    make HAS_SHADOW=1

Para usar también la opción MS-DNS (entregar la dirección IP del servidor DNS a clientes Windows), usar:

    make USE_MS_DNS=1 HAS_SHADOW=1

El contenido de /etc/ppp/options.servidor será:

        debug
        lock
        modem
        crtscts
        /dev/ttyS1
        115200
        asyncmap 0
        auth
        login
        :192.168.0.7
        proxyarp
        nodetach
        refuse-chap
        require-pap

Para mayor información sobre las opciones (man pppd) las opciones más importantes son:

auth, obliga al otro extremo a autentificarse antes de permitir el tráfico de paquetes.
login,  significa que utilizará la base de datos de usuario para la autentificación (/etc/passwd)
:192.168.0.7,  es la dirección IP que entrega al interfaz ppp0 del otro extremo.
proxyarp creará una entrada ARP para la IP del otro extremo asociada a la dirección Ethernet del servidor, esto hará el efecto de que el otro extremo está en la misma red que el servidor para otros equipos en la red del servidor. Si asignamos la ip remota dentro del rango de direcciones del segmento de red en que está el servidor, el extremo remoto es como si tuviera una tarjeta de red conectada a esta misma red, lo que simplifica el encaminamiento.
nodetach no se desconecta del terminal.
refuse-chap rehusa autentificación chap
require-pap solicita autentificación pap
 

/etc/ppp/pap-secrets

Este es el archivo donde se almacenan las contraseñas que entregamos cuando nos son solicitadas por PPP. Como en este caso somos servidor de acceso, aquí no hay claves, sino que las contrastaremos contra la base de datos de usuarios del sistemas /etc/passwd. De todas formas, se requiere la línea siguiente:

    *    *     ""     *

Nota, si hay problemas de autentificación, poner lo siguiente:

    *    *    ""    192.168.0.7
 

Encaminamiento

En este ejemplo, se pretende conectar una red externa 192.168.1.0/24 con otra local 192.168.0.0/24

El servidor (roxu) tiene la ip 192.168.0.6 asociada al interfaz eth0 conectado a uno de los segmentos de nuestra red local, al otro extremo (pinon) le entregaremos la ip 192.168.0.7 para su interfaz ppp0 (con la opción proxyarp es como si estuviera realmente en ese segmento, de ahí la ip corresponediente a la red local). La dirección ip del interfaz ppp0 del servidor (roxu) la dejamos sin asignar (según se ve en /etc/ppp/options.servidor) esto hará que sea la misma 192.168.0.6 que tiene asociado el interfaz eth0! (no hay problema, lo dice incluso Olaf Kirch en su Guía del Administrador de Redes). Por tanto:

a) Si es un único pc el que se conecta a nuestro servidor, ¡No hace falta ninguna entrada en las tablas de encaminamiento del/los routers de nuestra red local!

b) Si vamos a conectar una red local: El pc remoto también encamina paquetes IP, y su interfaz eth0 tiene la ip 192.168.1.1 de la red remota 192.168.1.0/24 (con lo que es el gateway por defecto para los puestos de la red remota), únicamente debemos añadir la ruta 192.168.0.6 para la red 192.168.1.0/24 a nuestros routers.

        route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.6

En el script que corresponda en cada router.

Santiago González Herrero, sgonzale@bigfoot.com
Agosto 1999