Trabajo - DavidHorat.com

Práctica 5:
Servidor de Acceso a Internet a
través de Acceso Telefónico a
Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Índice
Introducción..........................................................................................................................................2
Obtención e Instalación del demonio mgetty....................................................................................... 3
Configuración del Servidor de Acceso a Internet a través de Acceso Telefónico a Redes.................. 5
Configuración de mgetty para gestionar el módem.....................................................................5
Configuración del Servidor PPP (pppd)......................................................................................8
Configuración de Cliente UNIX para acceder al Servidor................................................................. 16
1. Configuración de la opciones del demonio pppd (/etc/ppp/options).................................... 16
2. Script de conexión mediante la herramienta chat (/etc/ppp/char-script)...............................17
3. Fichero de autentificación mediant PAP (/etc/ppp/pap-secrets)........................................... 18
Conexión con el servidor PPP...................................................................................................18
Configuración de Cliente Windows para acceder al Servidor............................................................23
Pruebas de Conexión entre Cliente y Servidor................................................................................... 30
Cliente UNIX............................................................................................................................ 31
Cliente Windows.......................................................................................................................36
1
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Introducción
En esta práctica realizaremos la instalación y configuración de un servidor de acceso a
Internet a través de acceso telefónico a redes. Esto quiere decir, que en el equipo pasarela se
instalará y configurará el servidor de acceso a Internet que permitirá que el equipo PC se conecte a
él por acceso telefónico a redes. Cuando el equipo PC se conecte el servidor del equipo pasarela le
permitirá el acceso a Internet.
El equipo pasarela tendrá acceso a Internet gracias al servidor del Laboratorio, y usará una
conexión a Internet mediante trajetas de red tipo Ethernet. De este modo, cuando el equipo PC se
conecte con el servidor de acceso a Internet del equipo pasarela, a través de acceso telefónico a
redes, éste le facilitará el acceso a Internet por la conexión que éste ya tiene por Ethernet.
Durante el desarrollo de la práctica se comentará el proceso de instalación y configuración
del servidor en el equipo pasarela y la configuración del cliente para que realice el acceso telefónico
a redes al equipo pasarela, pudiendo así conectarse a Internet. Como se usará conexión de acceso
telefónico a red, se usará el demonio pppd, y además se hará uso de mgetty, que es una herramienta
que nos permitirá el control de los puertos serie del sistema.
2
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Obtención e Instalación del demonio mgetty
Como se especifica en el guión de prácticas, obtendremos el demonio mgetty del servidor ftp
del Laboratorio (ftp://172.16.1.1). Disponemos de él en la carpeta /ppp/, bajo el nombre de mgetty1.1.30-3.i386.rpm. En realidad, podremos instalar el mgetty y el mgetty-sendfax, para lo cual hay
que instalar otros paquetes, por motivos de dependencias entre ellos. A continuación se indican
todos los paquetes que intalaríamos en total, indicando qué son y que dependencias tienen entre
ellos; se muestran igualmente, en orden de instalación, en función de las dependencias entre ellos.
1. mgetty-1.1.30-2.i386.rpm --> mgetty propiamente dicho. No depende de ninguno de los otros
paquetes.
2. netpbm-9.24-10.i386.rpm --> Proporciona la librería de funciones libpb, de forma que permite
ciertas funciones sobre la red, que usarán los paquetes rpm siguientes. Depende de que el mgetty
esté instalado (mgetty-1.1.30-2.i386.rpm).
3. netpbm-progs-9.24-10.i386.rpm --> Programas de acceso a red que usará el mgetty-sendfax, y
que dependen de la librería libpb, disponible en el rpm netpbm-9.24-10.i386.rpm.
4. mgetty-sendfax-1.1.30-2.i386.rpm --> mgetty-sendfax, que permite además de las funciones del
mgetty, el envío de fax. Depende de la librería libpb y sus programas, es decir, del rpm netpbmprogs-9.24-10.i386.rpm (y como es obvio, de los que ya dependía éste).
Como en realidad sólo vamos a realizar una conexión de acceso telefónico a redes entre el
equipo PC y la Pasarela (en la que está instalado el servidor pppd con el mgetty), en la que sólo se
harán transferencias de datos, sólo será necesaria la instalación del mgetty-sendfax, pero por las
dependencias de paquetes se deben instalar los otros tres, de modo que habrá que empezar
instalando el rpm mgetty-1.1.30-2.i386.rpm y los netpbm.
Una vez dispongamos del rpm de instalación del mgetty (y si se desea la instalación del
mgetty-sendfax, de los otros 3 rpms), éste se instalará lanzando el siguiente comando:
rpm -ihv PAQUETE.rpm
Los modificadores empleados para el comando rpm tienen el siguiente significado:
3
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
-i --> Realiza la instalación del rpm.
-h --> Viene de hash, e indica que se imprimirán marcas de 50 hash (con -v se verán bien) al
desempaqueter el rpm.
-v --> verbose (es decir, que muestra información de la extracción/instalación del rpm; en
definitiva, de la ejecución del comando rpm).
En el caso de la instalación exclusiva del mgetty bastará con lanzar el comando:
rpm -ihv mgetty-1.1.30-2.i386.rpm
Una vez lanzado el comando, el demonio mgetty ya estará instalado correctamente en el
equipo, y podrá lanzarse directamente escribiendo su nombre en la línea de comandos de un
terminal, es decir, con mgetty. Sin embargo, para su correcto funcionamiento, será necesaria la
configuración del mismo, previamente, proceso descrito en los siguientes apartados de la memoria.
4
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Configuración del Servidor de Acceso a
Internet a través de Acceso Telefónico a
Redes
Como equipo servidor de acceso a Internet se debe usar un equipo que dispondrá de acceso a
Internet a través de tarjetas Ethernet, de modo, que usamos el equipo Pasarela. De este modo,
partiendo de que tenemos la conexión con Internet por tarjetas Ethernet mediante la interfaz eth0, en
el equipo Pasarela se habrá instalado el demonio mgetty como se indicó anteriormente. A
continuación se comenta la configuración de mgetty y posteriormente la configuración del servidor
PPP con el demonio pppd.
Configuración de mgetty para gestionar el módem
La configuración del demonio mgetty para que conteste las llamadas entrantes desde equipos
que actuarán como clientes del servidor de acceso a Internet a través de acceso telefónio a redes,
sigue los siguientes pasos:
1. Configuración del Comportamiento de mgetty
Para configurar el comportamiento del demonio mgetty debemos modificar el fichero
mgetty.config. Este fichero está ubicado en la siguiente ruta: /etc/mgetty+sendfax/mgetty.config. A
la hora de indicar el comportamiento de mgetty lo haremos en base a las especificaciones de la
práctica, de modo que se tendrá el siguiente contenido en el fichero:
port /dev/modem
data-only yes
rings 2
modem-type auto
speed 115200
A continuación se indican las especificaciones de comportamiento para el demonio mgetty
según el guión de prácticas y con que línea del fichero mgetty.config, visto arriba, se consigue.
5
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
1. Sólo datos --> data-only yes --> Esto hace que las transferencias que se hará con el mgetty sean
sólo para datos, ya que podría proporcionar servicios más complejos, como fax, etc.
2. 2 rings antes de contestar --> rings 2 --> Antes de que el demonio mgetty conestre una llamada
entrada de lo que será un equipo cliente, espera a que el módem detecte 2 rings.
3. Puerto serie 1 --> port /dev/modem --> Establece como puerto de serie el que tiene asignado el
módem. En nuestro equipo el fichero /dev/modem es un enlace simbólico duro al puerto de serie
en el que está conectado el módem del equipo. Dado que estamos en la Pasarela, por defecto se
usa el módem interno, de módem que el enlace simbólico señala realmente al puerto de sere /
dev/ttySHSF0, que se correpondería con el puerto de serie 1.
4. Velocidad de transmisión máxima --> speed115200 --> El valor 115200 indica la velocidad de
conexión a intentar, de modo que el valor de 115200 (expresado en baudios) es la velocidad
máxima posible en una conexión entre módems.
5. Detección automática del tipo de módem --> modem-type auto --> Permite que se detecte
automáticamente el tipo de módem que tiene el sistema instalado, para que trabaje correctamente
con él.
El demonio mgetty permite muchas más configuraciones, pero con éstas será suficiente para
su correcto funcionamiento, y de hecho, la mayoría de ellas son necesarias para un correcto
funcionamiento en la comunicación que se producirá entre los equipos cliente y servidor.
2. Configuración de la Respuesta del Sistema una vez establecida la conexión entre
cliente-servidor
Para indicar al demonio mgetty que debe hacer una vez la conexión haya sido establecida, se
deberá indicar dicho aspecto en el fichero /etc/mgetty+sendfax/login.config. Como nuestro
propósito es de instalar y configurar un servidor de acceso telefónico a redes, lo cual se hace con
una conexión PPP, con el demonio pppd, debemos indicar que se lance el demonio pppd. De este
modo, el contenido del fichero será el siguiente:
/AutoPPP/ - a_ppp /usr/sbin/pppd
Esta única línea hace que se inicie el demonio pppd, con la conexión ya establecida entre
6
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
cliente y servidor, lo cual ha sido tarea exclusiva del demonio mgetty. Esta línea consta de 4
columnas, en la que el demonio se inicia con el AutoPPP, que es como si dijéramos el usuario por
defecto o automático.
Por otro lado, es importante señalar que el demonio se inicia sin pasarle ningún parámetro de
configuración de comportamiento del mismo, pues la configuración de su comportamiento se
realizará en los ficheros de opciones (options) y contraseñas (pap-secrets y/o chap-secrets) que usa
el demonio pppd; no obstante, siempre sería posible indicar los parámetros en la llamada al
demonio pppd, si bien el fichero de contraseñas debe configurarse manualmente en cualquier caso.
3. Configuración de la tabla de programas con autoinicio para que mgetty esté
activo para contestar a los clientes
Con las configuraciones anteriores el demonio mgetty realizará correctamente su tarea de
conexión entre cliente y servidor e iniciación del demonio pppd para la conexión PPP entre ambos.
No obstante, si lanzamos el demonio mgetty con esta configuración exclusivamente, en el sistema
UNIX, ocurrirá que el demonio mgetty se cerrará y habrá que volver a abrirlo. Por este motivo
debemos introducir una entrada en el fichero inittab para que el demonio mgetty se esté
continuamente ejecutando, como si estuviera en segundo plano.
El fichero inittab tiene por finalidad contener un listado de programas o demonios que se
deben lanzar automáticamente en el caso de que estos se cierren o mueren. Así, como se indica en el
guión de la práctica, cuando se cierre una conexión y el demonio mgetty muera, el hecho de tener la
línea que se verá a continuación el fichero inittab, permitirá que el demonio mgetty se vuelva a abrir
y puede establecer nuevas conexión de un cliente y el servidor. Dichas línea será:
...
# para que "mgetty" se ejecute cada vez que finalice una conexión
S1:2345:respawn:/sbin/mgetty modem
...
En el fichero inittab se indica con 4 columnas el demonio que se lanzará automática si
muere. La forma de lanzar el mgett será pasándole como parámetro el dispositivo módem que usará,
que en nuestro caso es el modem, ya que disponemos de un enlace simbólico, como se indicó con
7
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
anterioridad (la ruta no es necesaria en este caso, pues ya se usa por defecto /dev/). Los valores de
las anteriores columnas tienen como finalidad indicar el módem de iniciación del demonio o
proceso que se indica en dicha línea.
Con este último paso, el demonio mgetty estará completamente operativo, de modo que sólo
queda pendiente la configuración del pppd para que funcione como servidor para permitir el acceso
a Internet de equipos clientes a través de acceso telefónico a redes, es decir, por el protocolo PPP;
este proceso de configuración se ve a continuación.
Aunque se a parte del mgetty, hay que recordar que el fichero de resolución de nombres, es
decir, el fichero que indica la ubicación o dirección IP de servidores DNS, debe estar correctamente
configurado. Estamos hablando del fichero /etc/resolv.conf, cuyo contenido será el siguiente:
search redes.dis.ulpgc.es
nameserver 172.16.1.1
nameserver 193.145.143.100
En este caso se busca en la URL redes.dis.ulpgc.es y se tienen servidores DNS en las
direcciones IP 172.16.1.1 (servidor del Laboratorio) y 193.145.143.100 (servidor del DIS).
Configuración del Servidor PPP (pppd)
La configuración del demonio pppd se realiza fundamentalmente en el fichero /
etc/ppp/options, y en el fichero /etc/ppp/pap-secrets se configuran o indican los usuarios y
contraseñas de los mismos, que se enviarán por el protocolo PAP, en el caso de usar dicho fichero,
que será efectivamente el que se use.
De este modo, a continuación se muestra el fichero de opciones options ques se ha creado de
forma que cumpla las especificaciones del guión de prácticas, consiguiendo que la conexión a
Internet por parte del cliente se haga efectiva, es decir, que se cree la interfaz ppp0 de conexión en
red y que sea lo más standard posible, de modo que el cliente puede estar bajo una plataforma tipo
Windows.
8
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
/dev/modem
115200
proxyarp # Necesario para compatibilidad con Windows
# Se establece que el control de flujo sea por hardware.
crtscts
# Con el comando 'lock' aseguramos el uso exclusivo del puerto.
lock # Es opcional
# Mediante modem le indicamos a pppd que debe usar la línea
# telefónica.
modem
# Solicita al sistema remoto que se autentifique.
auth
# Autentificación mediante protocolo PAP
require-pap
refuse-chap
# Autentificación para usuarios que estén declarados en el sistema
#login
# Asignación de direcciones de servidor de nombres por parte del
# servidor para clientes Windows
ms-dns 172.16.1.1
ms-dns 193.145.143.100
# Asignación de máscara de red
netmask 255.255.255.0
# Tiempo máximo de conexión 2 minutos = 120 segundos
maxconnect 120
# El valor 115.200 es la velocidad de nuestro puerto (no del modem)
# en bps. Respecto a la velocidad real de conexión, Linux
# la negocia automáticamente tratando de obtener la máxima posible.
# Asignamos dirección local y dirección remota.
172.16.3.70:172.16.3.72 # Libre eleccion
A continuación se comentan la funcionalidad que aporta cada línea o conjunto de ellas,
relacionándolas en el caso de que se posible con las especificaciones del guión de la práctica.
Incluso en algunos casos, las líneas pueden ponerse o no de forma que variará el funcionamiento del
demonio pppd o el mecanismo de autentificación de los clientes al acceder al servidor.
1. /dev/modem --> Indica el dispositivo módem que se usará para la comunicación PPP que hará el
9
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
demonio pppd.
2. 115200 --> Si es posible la velocidad de conexión será la máxima.
3. proxyarp --> Activa el protocolo ARP para que se cree el proxy con la tarjeta Ethernet que
proporciona el acceso a Internet en el equipo Pasarela, que actua como servidor PPP; en este caso
será con la interfaz eth0. Este parámetro no es necesario en el caso de que los clientes usen la
plataforma UNIX. Sin embargo, para que puedan conectarse clientes Windows es necesario
indicarlo, de modo que siguiendo la filosofía de una configuración standard, este parámetro se
mantiene activado.
4. crtscts --> Activa el control de flujo por hardware, de modo que las conexiones entre módems de
distintas velocidades pueden realizarse sin problemas; el cliente también deberá habilitar el
control de flujo por hardware. [1ª especificación del guión de prácticas].
5. lock --> Bloquea el acceso al módem a aplicaciones distintas del pppd, en el equipo servidor
PPP. Esto evita que la conexión se vea alterada por el acceso al módem por parte de otros
programas, como podría ser el minicom. Este parámetro será por tanto opcional, si bien es
recomendable.
6. modem --> Se indica al pppd que debe hacer uso de la línea telefónica, mediante el uso del
módem.
7. auth --> Se solicita al sistema remoto, es decir, al cliente que acceda al servidor PPP, ques e
autentifique.
8. require-pap y refuse-chap --> Consigue que la autentificación antes indicada se realiza por el
protocolo de autentificación tipo PAP, nunca por el tipo CHAP. [2ª especificación del guión de
prácticas].
9. login --> Si se pone este parámetro sólo podrán acceder usuarios que estén declarados como tales
en el sistema, es decir, que sean usarios UNIX en el equipo del servidor PPP. Si no se pone, no
será necesario que los usuarios sean usuarios UNIX en el equipo del servidor PPP, en cuyo caso,
el proceso de autentificación sólo depende del contenido del fichero pap-secrets. Si login está
puesto, la autentificación depende del fichero pap-secrets y de la lista de usuarios UNIX al
mismo tiempo.
10.ms-dns 172.16.1.1 y ms-dns 193.145.143.100 --> Se indican los servidor DNS que podrán usar
los clientes de Windows que se conecten al servidor PPP; en el caso de clientes UNIX no es
necesario indicar ningún servidor DNS, pues ya se usaré el que use el servidor PPP a través de la
interfaz eth0. [4ª especificación del guión de prácticas].
10
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
11.netmask 255.255.255.0 --> Realiza la asignación de máscara de red. [5ª especificación del guión
de prácticas].
12.maxconnect 120 --> Hace que la duración de la conexión PPP sólo dura 120 segundos (2
minutos). La conexión durará este tiempo tanto si se usa como si no, es decir, no importa que
está ociosa (idle) o haya mucho tráfico de red. Este parámetro, como es obvio, es opcional. Si no
se pone, simplemente, la duración de la conexión será ilimitada y se puede terminar por parte del
cliente relanzando el pppd, que provocará el cierre de la misma; para conectarse simplemente
lanza el demonio pppd, correctamente configurado como se verá en apartados posteriores. [6ª
especificación del guión de prácticas].
13.172.16.3.70:172.16.3.72 --> Asigna la IP 172.16.3.70 al servidor PPP y la IP 172.16.3.72 al
cliente que se conecte con el servidor PPP. Los valores de las IP deben estar de acuerdo con la
máscara antes vista, es decir, la 255.255.255.0. De este modo, puede usarse otras direcciones IP,
cumpliendo siempre que tengan la forma 172.16.3.*, donde * puede tomar valores desde 1 hasta
254 (el 0 es para el servidor y el 255 es para el broadcast); pero tampoco podrán poners IPs
duplicadas. Por este motivo, como la 172.16.3.1 ya está asignada a la interfaz Ethernet eth0, no
podrá usarse, de modo que se usan las indicadas en el fichero. El formato para indicar las IPs es:
IPservidor:IPcliente. En principio podría ponerse solamente la IP del cliente (:IPcliente), pero es
mejor la otra opción, porque así se tiene una IP concreta y conecidad para la conexión PPP, con
lo que será la interfaz ppp0.
Cuando se realicen conexiones podrá jugarse con el login, de forma que se podrá poner o no
para obligar a que los usuarios que se conecten sean usuarios UNIX o no. Estos casos de distintos
tipos de conexiones se verán en un apartado a tal efecto, que está más adelante.
Por otro lado se configurará el fichero /etc/ppp/pap-secrets. En este fichero se indican los
usuarios permitidos según la base de datos del pppd. En el caso de que está indicado el parámetro
login en el fichero options, también afectará el hecho de que los usuarios sean usuarios UNIX del
sistema. De este modo el contenido de este fichero permitira múltiples variaciones, que darán
mucho juego y se verán más adelante, junto con las posibles variaciones del uso o no de login.
Como ejemplo, un posible contenido del mismo, permitiendo acceso a cualquier usuario, sería:
# Secrets for authentication using PAP
11
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
#cliente server
*
*
secret
""
David Jesús Horat Flotats
Enrique Fernández Perdomo
acceptable local IP addresses
*
Puede versre en el propio fichero que se indica en 4 columnas el usuario, su servidor
(normalmente una URL o nombre de un equipo), su contraseña (o secreto) y su IP. Como tratamos
la autentificación conectándonos siempre desde un mismo equipo, sólo se jugará con el nombre del
usuario y su contraseña, tratando a ambos como un todo, es decir, no es necesario demostrar que si
el usuario no usa una contraseña correcta no entra, pues es obvio. Como ya se mencionó, esto se
verá más adelante para diversos casos.
De forma opcional, cabe indicar que ciertas configuraciones de ficheros también son
realizables pasando parámetros a los demonios, y por lo general los comandos o parámetros pasados
son ligeramente diferentes. Como ejemplo se indica a continuación como sería la llamada a mgetty
indicando su configuración/comportamiento. Se trata de indicarle por parámetros lo mismo que se le
indicaba en el fichero mgetty.config. De este modo, para llamar a mgetty se usa la siguiente forma:
mgetty OPCIONES modem, donde modem es un enlace simbólico al módem. Las OPCIONES
serían:
-s 115200
--> velocidad máxima
-n 2
--> esperar 2 rings antes de descolgar
-D
--> sólo datos (también valdría -C "data")
-C "auto"
--> detección automática del tipo de módem
Como es obvio, dado que el mgetty está en memoria continuamente, cargado por el inittab,
habría que pasarle estos parámetros al escribir la entrada del mgetty en la línea que se ponga para el
mismo en dicho fichero.
Finalmente, podemos ver como varían las interfaces de red y la tabla de ruta del equipo
Pasarela, en el momento de establecerse la conexión PPP. Así, las conexiones antes de la conexión
son:
[root@pasarela3 ppp]# ifconfig
12
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
eth0
David Jesús Horat Flotats
Enrique Fernández Perdomo
Link encap:Ethernet HWaddr 00:0C:F1:6D:71:F4
inet addr:172.16.3.1 Bcast:172.16.3.255 Mask:255.255.255.0
inet6 addr: fe80::20c:f1ff:fe6d:71f4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3160 (3.0 Kb) TX bytes:22670 (22.1 Kb)
eth1
Link encap:Ethernet HWaddr 00:C0:49:B2:BF:F4
inet addr:172.16.1.3 Bcast:172.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::2c0:49ff:feb2:bff4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:397 errors:0 dropped:0 overruns:0 frame:0
TX packets:239 errors:0 dropped:0 overruns:0 carrier:0
collisions:15 txqueuelen:1000
RX bytes:102393 (99.9 Kb) TX bytes:20388 (19.9 Kb)
Interrupt:3 Base address:0x2c00
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1610 errors:0 dropped:0 overruns:0 frame:0
TX packets:1610 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1860644 (1.7 Mb) TX bytes:1860644 (1.7 Mb)
Por contra, con posterioridad a la conexión PPP se tendrá el dispositivo ppp0, que realiza la
conexión entre el servirdor, con IP 172.16.3.70, y el cliente, con IP 172.16.3.72 (el P-t-P).
[root@pasarela3 ppp]# ifconfig
eth0
Link encap:Ethernet HWaddr 00:0C:F1:6D:71:F4
inet addr:172.16.3.1 Bcast:172.16.3.255 Mask:255.255.255.0
inet6 addr: fe80::20c:f1ff:fe6d:71f4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39 errors:0 dropped:0 overruns:0 frame:0
13
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3160 (3.0 Kb) TX bytes:22670 (22.1 Kb)
eth1
Link encap:Ethernet HWaddr 00:C0:49:B2:BF:F4
inet addr:172.16.1.3 Bcast:172.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::2c0:49ff:feb2:bff4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:403 errors:0 dropped:0 overruns:0 frame:0
TX packets:245 errors:0 dropped:0 overruns:0 carrier:0
collisions:15 txqueuelen:1000
RX bytes:103139 (100.7 Kb) TX bytes:20889 (20.3 Kb)
Interrupt:3 Base address:0x2c00
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1634 errors:0 dropped:0 overruns:0 frame:0
TX packets:1634 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1863379 (1.7 Mb) TX bytes:1863379 (1.7 Mb)
ppp0
Link encap:Point-to-Point Protocol
inet addr:172.16.3.70 P-t-P:172.16.3.72 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:72 (72.0 b) TX bytes:66 (66.0 b)
En cuanto a la tabla de ruta, antes de la conexión es la siguiente:
[root@pasarela3 ppp]# route
Kernel IP routing table
Destination
Gateway
172.16.3.0
*
Genmask
255.255.255.0 U
Flags Metric Ref
0
0
Use Iface
0 eth0
14
David Jesús Horat Flotats
Enrique Fernández Perdomo
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
172.16.1.0
*
255.255.255.0 U
0
0
0 eth1
169.254.0.0
*
255.255.0.0
0
0
0 eth1
127.0.0.0
default
*
255.0.0.0
U
U
servidor.redes. 0.0.0.0
0
UG
0
David Jesús Horat Flotats
Enrique Fernández Perdomo
0 lo
0
0
0 eth1
Y después de la conexión PPP será:
[root@pasarela3 ppp]# route
Kernel IP routing table
Destination
Gateway
172.16.3.72
*
255.255.255.255 UH 0
172.16.3.0
*
255.255.255.0 U
0
0
0 eth0
172.16.1.0
*
255.255.255.0 U
0
0
0 eth1
169.254.0.0
*
255.255.0.0
0
0
0 eth1
127.0.0.0
default
*
Genmask
255.0.0.0
servidor.redes. 0.0.0.0
Flags Metric Ref
U
U
0
UG
0
0
0
Use Iface
0 ppp0
0 lo
0
0 eth1
Si la entrada default no fuerea correcta habría que borrar e introducir la correcta; no
obstante, si no existe antes de la conexión PPP, cuando ésta se establezca se generará correctamente
de forma automática.
Por otro lado, con el tcpdump podemos ver que la conexión con el cliente se hace realmente
con el dispositivo ppp0, como puede verse a continuación si se hace un ping a la máquina del
cliente (172.16.3.72) desde el equipo Pasarel, con el servidor PPP.
[root@pasarela3 ppp]# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
13:49:45.240824 IP 172.16.3.70 > 172.16.3.72: icmp 64: echo request seq 0
13:49:45.506224 IP 172.16.3.72 > 172.16.3.70: icmp 64: echo reply seq 0
13:49:46.242130 IP 172.16.3.70 > 172.16.3.72: icmp 64: echo request seq 1
13:49:46.493082 IP 172.16.3.72 > 172.16.3.70: icmp 64: echo reply seq 1
AL HACER: ping 172.16.3.72 -c 2
15
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Configuración de Cliente UNIX para acceder
al Servidor
El cliente no necesitará el demonio mgetty, pero sí el demonio pppd, para establecer el
enlace PPP entre el cliente y el servidor PPP, con la interfaz ppp0. De este modo, tendremos que
configurar el cliente PPP para el demonio pppd, de modo que se conecte con el servidor PPP y se
autentifique correctamente.
En este caso, no habrá que modificar necesariamente el fichero /etc/resolv.conf, si bien
podríamos dejarlo con el siguiente contenido, con similar explicación a la que tiene en el servidor.
search redes.dis.ulpgc.es
nameserver 172.16.1.1
nameserver 193.145.143.100
Los ficheros que deben ser necesariamente modificados/creados son los siguientes:
1. Configuración de la opciones del demonio pppd (/etc/ppp/options)
El fichero options deberá tener el siguiente contenido:
/dev/modem
115200
crtscts
defaultroute
noauth
debug
noipdefault
connect "/usr/sbin/chat -v -f /etc/ppp/chat-script"
name prueba
La explicación del mismo es similar a la de la práctica 4, no obstante se explica cada línea
brevemente a continuación:
16
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
1. /dev/modem --> Dispositivo del módem.
2. 115200 --> Velocidad máxima de conexión.
3. crtscts --> Control de flujo por hardware.
4. defaultroute --> Establece la ruta por defecto para la conexión PPP.
5. noauth --> No exige autentificación al servidor.
6. debug --> Activa la depuración (no es necesario).
7. noipdefault --> No hay IP por defecto; en este caso será el servidor el que le asigne al cliente la
IP que debe usar.
8. connect "/usr/sbin/chat -v -f /etc/ppp/chat-script" --> La cadena de conexión se realizará
mediante el script para la herramienta chat, contenido en el fichero chat-script, que se verá más
adelante.
9. name prueba --> Se indica el nombre del usuario que se conectará. Es parámetro es de vital
importancia en la autentificación, pues cuando se conecte, será este el parámetro el que indique
que usuario es el que se conecta. Cuando se juegue con los valores del fichero pap-secrets, habrá
que actualizar en name, para que se entre con el usuario correcto.
2. Script de conexión mediante la herramienta chat (/etc/ppp/charscript)
El servidor se encuentra en el número telefónico 21, de forma que el script de chat
inicializará el módem (ATZ), lo pondrá en modo de llamada por pulsos (ATP) y llamará al servidor
(ATD21). Su contenido será el siguiente, cuya explicación es conocida de la práctica 4.
''
atz
OK
atp
OK
atd21
CONNECT
Este script realizará la llamada al servidor PPP, en el cual el mgetty descolgará la llamda y
pasará el control al demonio pppd, que se encargará de realizar el enlace PPP con la interfaz ppp0
entre el cliente y servidor, para que el cliente tenga acceso a Internet a través de PPP (acceso
telefónico a redes).
17
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
3. Fichero de autentificación mediant PAP (/etc/ppp/pap-secrets)
El fichero pap-secrets podrá tomar múltiples valores, que se comentarán más adelante, y
dependerán del fichero pap-secrets del servidor, así como la opción login del fichero options del
servidor. Como ejemplo, dado que en el fichero options del cliente teníamos name prueba, nos
conectaremos como usario prueba, y el fichero pap-secrets definirá el nombre de usuario prueba y
su contraseña; de la siguiente forma:
# client server
secret
IP addresses
prueba * "prueba" *
Conexión con el servidor PPP
A continuación vamos a ver como cambia en el equipo cliente la tabla de ruta y las
conexiones de red disponibles, una vez se produce la conexión con el servidor PPP. Para realizar la
conexión con el servidor PPP bastará con lanzar el demonio pppd desde un terminal, escribiendo
simplemente pppd; para terminar la conexión, si ésta está establecida, bastará volver a llamar a pppd
y ésta se concluirá.
Antes del establecimiento de la conexión con el servidor PPP, la conexiones de red del
equipo cliente son:
[root@localhost root]# ifconfig
eth0
Link encap:Ethernet HWaddr 00:0C:F1:6B:2F:32
inet addr:172.16.3.2 Bcast:172.16.3.255 Mask:255.255.255.0
inet6 addr: fe80::20c:f1ff:fe6b:2f32/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:31 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:22178 (21.6 Kb) TX bytes:3412 (3.3 Kb)
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
18
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2306 errors:0 dropped:0 overruns:0 frame:0
TX packets:2306 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2645476 (2.5 Mb) TX bytes:2645476 (2.5 Mb)
Una vez se realice la conexión, se tendrá:
[root@localhost root]# pppd
[root@localhost root]# ifconfig
eth0
Link encap:Ethernet HWaddr 00:0C:F1:6B:2F:32
inet addr:172.16.3.2 Bcast:172.16.3.255 Mask:255.255.255.0
inet6 addr: fe80::20c:f1ff:fe6b:2f32/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:31 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:22178 (21.6 Kb) TX bytes:3412 (3.3 Kb)
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2306 errors:0 dropped:0 overruns:0 frame:0
TX packets:2306 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2645476 (2.5 Mb) TX bytes:2645476 (2.5 Mb)
ppp0
Link encap:Point-to-Point Protocol
inet addr:172.16.3.72 P-t-P:172.16.3.70 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:5 errors:1 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:66 (66.0 b) TX bytes:72 (72.0 b)
19
David Jesús Horat Flotats
Enrique Fernández Perdomo
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Se observa como aparece una nueva conexión, la ppp0. Puede verse como la asignación de
IP al cliente es correcta (172.16.3.72) al igual que indica que es punto a punto (P-t-P) con el
servirdor PPP, cuya IP es la 172.16.3.70.
También puede verse como la tabla de rutas varía. Así, antes de la conexión tiene:
[root@localhost root]# route
Kernel IP routing table
Destination
Gateway
172.16.3.0
*
255.255.255.0 U
0
0
0 eth0
169.254.0.0
*
255.255.0.0
0
0
0 eth0
127.0.0.0
default
*
Genmask
255.0.0.0
172.16.3.1
Flags Metric Ref
U
U
0.0.0.0
0
0
UG 0
Use Iface
0 lo
0
0 eth0
Para asegurarnos de que la IP default se establezca correctamente es conveniente eliminarla
antes de la conexión, como se observa a continuación:
[root@localhost root]# route del default
[root@localhost root]# route
Kernel IP routing table
Destination
Gateway
172.16.3.0
*
255.255.255.0 U
0
0
0 eth0
169.254.0.0
*
255.255.0.0
0
0
0 eth0
127.0.0.0
*
Genmask
255.0.0.0
Flags Metric Ref
U
U
0
0
Use Iface
0 lo
Tras estalecerse la conexión con el servidor PPP, la tabla de ruta quedará así:
[root@localhost root]# pppd
[root@localhost root]# route
Kernel IP routing table
Destination
Gateway
172.16.3.70
*
255.255.255.255 UH 0
172.16.3.0
*
255.255.255.0 U
0
0
0 eth0
169.254.0.0
*
255.255.0.0
0
0
0 eth0
127.0.0.0
*
Genmask
255.0.0.0
Flags Metric Ref
U
U
0
0
0
Use Iface
0 ppp0
0 lo
20
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
default
172.16.3.70
0.0.0.0
UG
0
0
David Jesús Horat Flotats
Enrique Fernández Perdomo
0 ppp0
Ahora la entrada default es para la conexión ppp0 y señala a la IP del servidor PPP, que es la
172.16.3.70.
Además, haciendo uso de la herramienta de visualización de tráfico de red conocida como
tcpdump, puede verse que realmente la conexión a Internet se hace por el ppp0 y no a través de las
tarjetas Ethernet. Para ello se activa el tcpdump para el dispositivo ppp0, con el comando que se ve
a continuación, y se hace un ping al servidor PPP, para ver que la conexión está correctamente
establecida.
[root@localhost ppp]# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:29:44.068814 IP 172.16.3.72 > 172.16.3.70: icmp 64: echo request seq 0
14:29:44.408302 IP 172.16.3.70 > 172.16.3.72: icmp 64: echo reply seq 0
14:29:45.070222 IP 172.16.3.72 > 172.16.3.70: icmp 64: echo request seq 1
14:29:45.295175 IP 172.16.3.70 > 172.16.3.72: icmp 64: echo reply seq 1
AL HACER: ping 172.16.3.70 -c 2 (a la Pasarela)
Por otro lado, si el ping lo hacemos a Internet, por ejemplo a www.google.es, tendremos el
siguiente resultado:
[root@localhost ppp]# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:36:37.081677 IP 172.16.3.72.32769 > servidor.redes.dis.ulpgc.es.domain: 9658+ A? www.google.es. (31)
14:36:37.082140 IP 172.16.3.72.32770 > servidor.redes.dis.ulpgc.es.domain: 62806+ PTR? 1.1.16.172.inaddr.arpa. (41)
14:36:37.342533 IP servidor.redes.dis.ulpgc.es.domain > 172.16.3.72.32770: 62806* 1/1/0 (103)
14:36:37.342774 IP 172.16.3.72.32770 > servidor.redes.dis.ulpgc.es.domain: 62807+ PTR? 72.3.16.172.inaddr.arpa. (42)
14:36:37.585507 IP servidor.redes.dis.ulpgc.es.domain > 172.16.3.72.32769: 9658 4/11/2 CNAME[|domain]
14:36:37.585736 IP 172.16.3.72 > 216.239.59.104: icmp 64: echo request seq 0
21
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
14:36:37.604489 IP servidor.redes.dis.ulpgc.es.domain > 172.16.3.72.32770: 62807 NXDomain 0/1/0 (119)
14:36:37.604819 IP 172.16.3.72.32771 > servidor.redes.dis.ulpgc.es.domain: 62808+ PTR? 104.59.239.216.inaddr.arpa. (45)
14:36:37.879455 IP servidor.redes.dis.ulpgc.es.domain > 172.16.3.72.32771: 62808 NXDomain 0/1/0 (105)
14:36:37.915448 IP 216.239.59.104 > 172.16.3.72: icmp 64: echo reply seq 0
14:36:37.915672 IP 172.16.3.72.32771 > servidor.redes.dis.ulpgc.es.domain: 9659+ PTR? 104.59.239.216.inaddr.arpa. (45)
14:36:38.122415 IP servidor.redes.dis.ulpgc.es.domain > 172.16.3.72.32771: 9659 NXDomain 0/1/0 (105)
14:36:38.586365 IP 172.16.3.72 > 216.239.59.104: icmp 64: echo request seq 1
14:36:38.905297 IP 216.239.59.104 > 172.16.3.72: icmp 64: echo reply seq 1
AL HACER: ping www.google.es -c 2
Si rastreáramos el dispositivo eth0 (de la interfaz Ethernet), no veríamos nada, pues la
conexión a Internet está correctamente establecida por el protocolo PPP con el servidor PPP, del
equipo Pasarela.
22
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Configuración de Cliente Windows para
acceder al Servidor
En el caso de los clientes de Windows se creará una conexión de acceso telefónico a redes
con el equipo servidor PPP. Esta tarea se hace en modo gráfico desde la carpeta de Conexiones de
red, en la que crearemos un nueva conexión que será de acceso telefónico a redes mediante un
módem. Una vez se cree dicha conexión se tendrá que configurar correctamente, según los
siguientes puntos:
1. Poner el nombre de usuario y contraseña, que son prueba y prueba, respectivamente. Además se
indica que se llama al número 21, que es el del equipo Pasarela, en el que está hospedado el
servidor PPP.
23
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
2. Como ya se ve en la ilustración del punto anterior, debemos Usar reglas de marcado. Se trata de
que el módem use la marcación por pulsos, pues por defecto usaría la marcación por tonos y
entonces la conexión no se produciría.
24
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
25
David Jesús Horat Flotats
Enrique Fernández Perdomo
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
No será necesario ninguna configuración más, es decir, no se tiene que indicar ningún valor
de IP o DNS, pues el servidor PPP al que nos conectaremos nos proporcionará ambas direcciones en
el momento de conectarnos y activarse el demonio pppd en el servidor PPP.
De este modo, podremos conectarnos picando en Marcar, en la conexión que hemos llamado
ppp0. De este modo se producirá la conexión. Si se desea se podrá alterar el nombre de usuario y
contraseña con el que se conectará con el servidor PPP; más adelante se tratan los diversos casos de
autentificación.
Durante la conexión se marcará el número 21 y sólo en caso de fallo de la conexión
aparecerán mensajes informativos, lo cual se verá en las pruebas realizadas más adelante.
26
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Cuando se haya producido la conexión, podremos verlo en el estado de la conexión ppp0.
Con ello puede observarse que la conexión se hace efectiva y que la velocidad de la misma es de
115.200 kbps (la máxima).
Para tener una mejor noción del cambio que se produce en la conexión de red en el equipo
cliente, puede verse la variación que sufre la tabla de ruta. Esto puede verse con el comando route
print. Antes de establecerse la conexión, el equipo cliente de Windows, tiene la siguiente tabla de
ruta:
27
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
===========================================================================
ILista de interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c f1 6b 2f 32 ...... Intel(R) PRO/100 VE Network Connection Minipue
rto del administrador de paquetes
===========================================================================
===========================================================================
Rutas activas:
Destino de red
Máscara de red
Puerta de acceso
Interfaz
Métrica
0.0.0.0
0.0.0.0
172.16.3.1
172.16.3.2
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
172.16.3.0
255.255.255.0
172.16.3.2
172.16.3.2
20
172.16.3.2
255.255.255.255
127.0.0.1
127.0.0.1
20
172.16.255.255
255.255.255.255
172.16.3.2
172.16.3.2
20
224.0.0.0
240.0.0.0
172.16.3.2
172.16.3.2
20
255.255.255.255
255.255.255.255
172.16.3.2
172.16.3.2
1
Puerta de enlace predeterminada:
20
1
172.16.3.1
===========================================================================
Rutas persistentes:
ninguno
Una vez establecida la conexión de acceso telefónico a redes con el servidor PPP, la tabla de
ruta será:
===========================================================================
ILista de interfaces
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c f1 6b 2f 32 ...... Intel(R) PRO/100 VE Network Connection Minipue
rto del administrador de paquetes
0x80004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Rutas activas:
Destino de red
Máscara de red
Puerta de acceso
Interfaz
0.0.0.0
0.0.0.0
172.16.3.1
172.16.3.2
0.0.0.0
0.0.0.0
172.16.3.72
172.16.3.72
28
Métrica
21
1
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
172.16.3.0
255.255.255.0
172.16.3.2
172.16.3.2
20
172.16.3.2
255.255.255.255
127.0.0.1
127.0.0.1
20
172.16.3.70
255.255.255.255
172.16.3.72
172.16.3.72
172.16.3.72
255.255.255.255
127.0.0.1
127.0.0.1
50
172.16.255.255
255.255.255.255
172.16.3.2
172.16.3.2
20
172.16.255.255
255.255.255.255
172.16.3.72
172.16.3.72
50
224.0.0.0
240.0.0.0
172.16.3.2
172.16.3.2
20
224.0.0.0
240.0.0.0
172.16.3.72
172.16.3.72
1
255.255.255.255
255.255.255.255
172.16.3.2
172.16.3.2
1
255.255.255.255
255.255.255.255
172.16.3.72
172.16.3.72
1
Puerta de enlace predeterminada:
1
1
172.16.3.72
===========================================================================
Rutas persistentes:
ninguno
Se observa como el cliente recibe la IP 172.16.3.72 y que mandará los paquetes IP a la
dirección IP 172.16.3.70, que es la del servidor PPP (el equipo Pasarela).
En este caso la puerta de enlace predeterminada (default) es correcta, pues es la IP asignada
al cliente (172.16.3.72), pero si no lo fuera habría que proceder de la siguiente forma:
1. Borrar la IP supuestamente errónea de la puerta de enlace predeterminada, con el comando route
delete IP.
2. A continuación se pone la correcta, o bien si no estaba establecida la conexión de ppp0, se realiza
dicha conexión y al establecerse la IP de la puerta de enlace será la correcta, si todo el proceso de
conexión es correcto.
29
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Pruebas de Conexión entre Cliente y
Servidor
A continuación se enumeran diversos casos de conexión con diferentes valores en los
ficheros que afectan al proceso de autentificación del cliente en el servidor PPP. Se dividen las
pruebas según el cliente sea UNIX o Windows, si bien se verá que se obtienen idénticos resultados,
aunque la forma en que se perciben no es la misma.
Antes de todo ello se indican a continuación los usuarios del sistemas UNIX en el equipo
con el servidor PPP, que serán los que afectarán y se usarán en las siguientes pruebas de
autentificación:
A continuación se indica el nombre del usuario y su contraseña:
30
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
zacho --> zachotio
prueba --> prueba
brueba --> brueba
Cliente UNIX
Las modificaciones posibles son las siguientes:
1. Modificar el fichero options, para indicar si los usuarios deben estar declarados en el sistema
UNIX del servidor PPP (se pone la opción login) o no es necesario que estén declarados (no se
pone la opcón login).
2. Modificar los ficheros pap-secrets del equipo cliente y el servidor, para permitir el acceso a
determinados usuarios o bien rechazarlos.
Para mayor facilidad en la comprensión de los casos se dispone de la siguiente tabla para la
que posteriormente se indicarán los resultados que se obtienen, en forma de salidas en el fichero
messages del equipo con el servidor PPP (con el comando tail -f /var/log/messages).
Cliente: pap-secrets
Servidor: pap-secrets
Servidor: options
Resultado
prueba * “prueba” *
* * “” *
Con login
Se conecta
zacho * “zachotio” *
zacho * - *
Con login
El servidor no acepta el
usuario y lo echa
jou * “joujou” *
* * “” *
Con login
ó
El servidor no acepta el
usuario y lo echa
jou * “joujou” *
jou * “joujou” *
* * “” *
Sin login
Se conecta
Sin login
El servidor rechaza el
ó
jou * “joujou” *
jou * “joujou” *
* * “” *
jou * - *
usuario jou, pero acepta
al resto
31
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
Cliente: pap-secrets
zacho * “zachotio” *
Servidor: pap-secrets
* * “” *
David Jesús Horat Flotats
Enrique Fernández Perdomo
Servidor: options
Sin login
ó
Resultado
Se conecta, el servidor
acepta al cliente
zacho* “zachotio” *
zacho * “zachotio” *
* * “” *
Sin login
zacho * - *
El servidor rechaza al
cliente
Para todos los casos anteriores hay que mencionar el hecho de que en el fichero options del
equipo cliente debe configurarse correctamente el usuario con el que se realizará la conexión, es
decir, hay que indicarlo con el comando name USUARIO. De este modo, si en el fichero pap-secrets
tenemos la declaración de un usuario como prueba, deberemos tener name prueba en el fichero
options, de lo contrario la autentificación fallará.
Dicho esto, y sabiendo que el hecho de que el fichero options del servidor no tenga la opción
login indica que el usuario no tiene que estar necesariamente declarado en el sistema UNIX, y la
presencia de dicha opción login denota la obligatoriedad de que el usuario esté declarado en el
sistema UNIX, procedemos a comentar cada resultado. Nos referiremos a cada caso por su posición
en la tabla anterior. De este modo, se tendrán salidas que concluyen los resultados antes expuestos.
1. Caso 1:
Como el usuario prueba está declarado en el sistema y el fichero pap-secrets del servidor
admite a cualquier usuario, se conectará sin problemas, como se ve a continuación:
Nov 29 14:02:25 pasarela3 mgetty[3745]: data dev=modem, pid=3745, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 14:02:25 pasarela3 pppd[3745]: pppd 2.4.2 started by root, uid 0
Nov 29 14:02:25 pasarela3 pppd[3745]: Using interface ppp0
Nov 29 14:02:25 pasarela3 pppd[3745]: Connect: ppp0 <--> /dev/modem
Nov 29 14:02:25 pasarela3 pppd[3745]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:02:28 pasarela3 pppd[3745]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:02:28 pasarela3 ppp(pam_unix)[3745]: session opened for user prueba by (uid=0)
Nov 29 14:02:28 pasarela3 pppd[3745]: user prueba logged in
Nov 29 14:02:28 pasarela3 pppd[3745]: PAP peer authentication succeeded for prueba
32
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Nov 29 14:02:29 pasarela3 pppd[3745]: Deflate (15) compression enabled
Nov 29 14:02:29 pasarela3 pppd[3745]: found interface eth0 for proxy arp
Nov 29 14:02:29 pasarela3 pppd[3745]: local IP address 172.16.3.70
Nov 29 14:02:29 pasarela3 pppd[3745]: remote IP address 172.16.3.72
Se observa que la autentificación es correcta para el usuario prueba y posteriormente se le
asigna la IP al equipo local (el servidor PPP) y al remoto (el cliente).
2. Caso 2:
El usuario zacho está declarado en el sistema, pero el fichero pap-secrets del servidor lo
rechaza; para rechar usuario se pone una línea con el siguiente formato:
USUARIO SERVIDOR – IP
La claves está en poner un guión (-) para recharzarlo. De este modo, el usuario será
rechazado por el servidor.
Nov 29 14:04:48 pasarela3 mgetty[3799]: data dev=modem, pid=3799, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 14:04:48 pasarela3 pppd[3799]: pppd 2.4.2 started by root, uid 0
Nov 29 14:04:48 pasarela3 pppd[3799]: Using interface ppp0
Nov 29 14:04:48 pasarela3 pppd[3799]: Connect: ppp0 <--> /dev/modem
Nov 29 14:04:48 pasarela3 pppd[3799]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:04:51 pasarela3 pppd[3799]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:04:51 pasarela3 ppp(pam_unix)[3799]: session opened for user zacho by (uid=0)
Nov 29 14:04:51 pasarela3 pppd[3799]: user zacho logged in
Nov 29 14:04:51 pasarela3 pppd[3799]: PAP peer authentication failed for zacho
Nov 29 14:04:51 pasarela3 ppp(pam_unix)[3799]: session closed for user zacho
Nov 29 14:04:51 pasarela3 pppd[3799]: Connection terminated.
Nov 29 14:04:52 pasarela3 pppd[3799]: Hangup (SIGHUP)
Nov 29 14:04:52 pasarela3 pppd[3799]: ioctl(TIOCSETD, N_TTY): Interrupted system call (line 573)
Nov 29 14:04:52 pasarela3 pppd[3799]: Exit.
Nov 29 14:04:52 pasarela3 init: open(/dev/pts/0): No such file or directory
Se puede ver que la autenteficación PAP falla para el usuario zacho, por lo que es rechazado
por el servidor.
33
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
3. Caso 3:
El usuario jou no está declarado en el sistema, por lo que será rechazado.
Nov 29 14:06:50 pasarela3 mgetty[3817]: data dev=modem, pid=3817, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 14:06:50 pasarela3 pppd[3817]: pppd 2.4.2 started by root, uid 0
Nov 29 14:06:50 pasarela3 pppd[3817]: Using interface ppp0
Nov 29 14:06:50 pasarela3 pppd[3817]: Connect: ppp0 <--> /dev/modem
Nov 29 14:06:50 pasarela3 pppd[3817]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:06:53 pasarela3 pppd[3817]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:06:53 pasarela3 ppp(pam_unix)[3817]: check pass; user unknown
Nov 29 14:06:53 pasarela3 ppp(pam_unix)[3817]: authentication failure; logname= uid=0 euid=0 tty=/dev/modem
ruser= rhost=
Nov 29 14:06:55 pasarela3 pppd[3817]: PAP peer authentication failed for jou
Nov 29 14:06:56 pasarela3 pppd[3817]: Connection terminated.
Nov 29 14:06:57 pasarela3 pppd[3817]: Hangup (SIGHUP)
Nov 29 14:06:57 pasarela3 pppd[3817]: ioctl(TIOCSETD, N_TTY): Interrupted system call (line 573)
Nov 29 14:06:57 pasarela3 pppd[3817]: Exit.
Nov 29 14:06:57 pasarela3 init: open(/dev/pts/0): No such file or directory
En este caso es rechazado porque no es un usuario del sistema, lo cual puede verse porque al
chequear al usuario, no lo conoce: check pass; user unknown.
4. Caso 4:
En este como en los casos siguientes, al no poner la opción login, los ficheros del sistema no
son relevantes y no se tiene en cuenta en la autentificación. Para este caso concreto, el usuario jou
entrará, porque el fichero pap-secrets permite que entre cualquier usuario o bien el usuario en
concreto con el que se conectará el cliente. Si permite la entrada a todos, se tiene:
Nov 29 14:10:05 pasarela3 mgetty[3847]: data dev=modem, pid=3847, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 14:10:06 pasarela3 pppd[3847]: pppd 2.4.2 started by root, uid 0
Nov 29 14:10:06 pasarela3 pppd[3847]: Using interface ppp0
Nov 29 14:10:06 pasarela3 pppd[3847]: Connect: ppp0 <--> /dev/modem
34
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Nov 29 14:10:06 pasarela3 pppd[3847]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:10:09 pasarela3 pppd[3847]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:10:09 pasarela3 pppd[3847]: PAP peer authentication succeeded for jou
Nov 29 14:10:09 pasarela3 pppd[3847]: Deflate (15) compression enabled
Nov 29 14:10:09 pasarela3 pppd[3847]: found interface eth0 for proxy arp
Nov 29 14:10:09 pasarela3 pppd[3847]: local IP address 172.16.3.70
Nov 29 14:10:09 pasarela3 pppd[3847]: remote IP address 172.16.3.72
Si se permite la entrada exclusiva al usuario (con jou * “joujou” *), se tiene:
Nov 29 14:13:27 pasarela3 mgetty[4571]: data dev=modem, pid=4571, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 14:13:27 pasarela3 pppd[4571]: pppd 2.4.2 started by root, uid 0
Nov 29 14:13:27 pasarela3 pppd[4571]: Using interface ppp0
Nov 29 14:13:27 pasarela3 pppd[4571]: Connect: ppp0 <--> /dev/modem
Nov 29 14:13:27 pasarela3 pppd[4571]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:13:30 pasarela3 pppd[4571]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:13:30 pasarela3 pppd[4571]: PAP peer authentication succeeded for jou
Nov 29 14:13:30 pasarela3 pppd[4571]: Deflate (15) compression enabled
Nov 29 14:13:31 pasarela3 pppd[4571]: found interface eth0 for proxy arp
Nov 29 14:13:31 pasarela3 pppd[4571]: local IP address 172.16.3.70
Nov 29 14:13:31 pasarela3 pppd[4571]: remote IP address 172.16.3.72
En ambos casos se acepta la conexión y se observa que no existe ninguna diferencia en el
proceso.
5. Caso 5:
En este caso falla la conexión porque el pap-secrets del servidor rechaza al usuario jou.
Nov 29 14:20:18 pasarela3 mgetty[4652]: data dev=modem, pid=4652, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 14:20:18 pasarela3 pppd[4652]: pppd 2.4.2 started by root, uid 0
Nov 29 14:20:18 pasarela3 pppd[4652]: Using interface ppp0
Nov 29 14:20:18 pasarela3 pppd[4652]: Connect: ppp0 <--> /dev/modem
Nov 29 14:20:18 pasarela3 pppd[4652]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:20:21 pasarela3 pppd[4652]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
35
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Nov 29 14:20:21 pasarela3 pppd[4652]: PAP peer authentication failed for jou
Nov 29 14:20:22 pasarela3 pppd[4652]: Connection terminated.
Nov 29 14:20:23 pasarela3 pppd[4652]: Hangup (SIGHUP)
Nov 29 14:20:23 pasarela3 pppd[4652]: ioctl(TIOCSETD, N_TTY): Interrupted system call (line 573)
Nov 29 14:20:23 pasarela3 pppd[4652]: Exit.
Nov 29 14:20:23 pasarela3 init: open(/dev/pts/0): No such file or directory
Si se entrara como otro usuario por parte del cliente, por ejemplo, poniendo name prueba en
el fichero options y prueba * “prueba” * en el fichero pap-secrets, la conexión sí se conseguirá.
Nov 29 14:21:30 pasarela3 mgetty[4693]: data dev=modem, pid=4693, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 14:21:30 pasarela3 pppd[4693]: pppd 2.4.2 started by root, uid 0
Nov 29 14:21:30 pasarela3 pppd[4693]: Using interface ppp0
Nov 29 14:21:30 pasarela3 pppd[4693]: Connect: ppp0 <--> /dev/modem
Nov 29 14:21:30 pasarela3 pppd[4693]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:21:33 pasarela3 pppd[4693]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 14:21:33 pasarela3 pppd[4693]: PAP peer authentication succeeded for prueba
Nov 29 14:21:33 pasarela3 pppd[4693]: Deflate (15) compression enabled
Nov 29 14:21:33 pasarela3 pppd[4693]: found interface eth0 for proxy arp
Nov 29 14:21:33 pasarela3 pppd[4693]: local IP address 172.16.3.70
Nov 29 14:21:33 pasarela3 pppd[4693]: remote IP address 172.16.3.72
Para los casos 6 y 7 se produciría los mismo que para los casos 4 y 5, respectivamente.
Cliente Windows
Se aprovecha para decir lo que ocurre con la tabla de ruta del equipo Pasarela con el servidor
PPP, al producirse la conexión PPP de un cliente Windows. Antes de la conexión tenemos:
[root@pasarela3 ppp]# route
Kernel IP routing table
Destination
Gateway
Genmask
Flags Metric Ref
172.16.3.0
*
255.255.255.0 U
0
0
0 eth0
172.16.1.0
*
255.255.255.0 U
0
0
0 eth1
169.254.0.0
*
255.255.0.0
0
0
0 eth1
U
36
Use Iface
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
127.0.0.0
default
*
255.0.0.0
U
servidor.redes. 0.0.0.0
0
UG
0
0
David Jesús Horat Flotats
Enrique Fernández Perdomo
0 lo
0
0 eth1
Después de la conexión ppp0 tendremos:
[root@pasarela3 ppp]# route
Kernel IP routing table
Destination
Gateway
172.16.3.72
*
255.255.255.255 UH 0
172.16.3.0
*
255.255.255.0 U
0
0
0 eth0
172.16.1.0
*
255.255.255.0 U
0
0
0 eth1
169.254.0.0
*
255.255.0.0
0
0
0 eth1
127.0.0.0
default
*
Genmask
255.0.0.0
servidor.redes. 0.0.0.0
Flags Metric Ref
U
U
0
UG
0
0
0
Use Iface
0 ppp0
0 lo
0
0 eth1
Si lanzamos el tcpdump podemos ver que la conexión ppp0 es correcta y usada para que el
cliente se conecte a Internet. Al hacer un ping www.google.es, en el dispositivo ppp0 se ve tráfico:
[root@pasarela3 ppp]# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
15:49:02.359281 IP 172.16.3.72.1043 > servidor.redes.dis.ulpgc.es.domain: 33082+ A? www.google.es. (31)
15:49:02.359815 IP servidor.redes.dis.ulpgc.es.domain > 172.16.3.72.1043: 33082 4/11/2 CNAME[|domain]
15:49:02.802147 IP 172.16.3.72 > 216.239.59.104: icmp 40: echo request seq 256
15:49:02.877792 IP 216.239.59.104 > 172.16.3.72: icmp 40: echo reply seq 256
15:49:03.726010 IP 172.16.3.72 > 216.239.59.104: icmp 40: echo request seq 512
15:49:03.803074 IP 216.239.59.104 > 172.16.3.72: icmp 40: echo reply seq 512
15:49:04.712860 IP 172.16.3.72 > 216.239.59.104: icmp 40: echo request seq 768
15:49:04.788366 IP 216.239.59.104 > 172.16.3.72: icmp 40: echo reply seq 768
15:49:05.720704 IP 172.16.3.72 > 216.239.59.104: icmp 40: echo request seq 1024
15:49:05.797248 IP 216.239.59.104 > 172.16.3.72: icmp 40: echo reply seq 1024
Mientras que en la interfaz eth0 no se ve ningún tráfico, como es de esperar.
37
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
[root@pasarela3 ppp]# tcpdump -i eth0
^[[3~tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
A continuación se muestra una tabla con los casos probados para el caso de clientes
Windows, que serán equivalentes a los tratados para clientes UNIX, aunque por comodidad ahora se
usan otros usuarios, ya que en Windows no existe ni fichero options ni pap-secrets.
Cliente:
Servidor: pap-secrets
Servidor: options
Resultado
Usuario y Contraseña
prueba prueba
* * “” *
Sin login
Se conecta
prueba prueba
prueba * prueba *
Sin login
El servidor no acepta el
usuario y lo echa
prueba prueba
* * “” *
Sin login
prueba * - *
El servidor no acepta el
usuario y lo echa
prueba prueba
* * “” *
Con login
Se conecta
zacho zachotio
zacho * - *
Con login
El servidor rechaza el
usuario jou, pero acepta
al resto
jou joujou
* * “” *
Con login
ó
Se conecta, el servidor
acepta al cliente
jou* “joujou” *
A continuación se comenta cada caso:
1. Caso 1:
Como el servidor admite cualquier usuario y no usa login, es decir, no se requiere que el
usuario esté declarado en el sistema (aunque en realidad lo está), se conectará satisfactoriamente.
Nov 29 15:39:53 pasarela3 mgetty[6419]: data dev=modem, pid=6419, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 15:39:53 pasarela3 pppd[6419]: pppd 2.4.2 started by root, uid 0
Nov 29 15:39:53 pasarela3 pppd[6419]: Using interface ppp0
Nov 29 15:39:53 pasarela3 pppd[6419]: Connect: ppp0 <--> /dev/modem
Nov 29 15:39:53 pasarela3 pppd[6419]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
38
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Nov 29 15:39:56 pasarela3 pppd[6419]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 15:39:56 pasarela3 pppd[6419]: PAP peer authentication succeeded for prueba
Nov 29 15:39:57 pasarela3 pppd[6419]: found interface eth0 for proxy arp
Nov 29 15:39:57 pasarela3 pppd[6419]: local IP address 172.16.3.70
Nov 29 15:39:57 pasarela3 pppd[6419]: remote IP address 172.16.3.72
2. Caso 2:
En este caso se deja pasar exclusivamente al usuario prueba, por lo que se tendrá lo mismo
que antes.
Nov 29 15:53:54 pasarela3 mgetty[6613]: data dev=modem, pid=6613, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 15:53:54 pasarela3 pppd[6613]: pppd 2.4.2 started by root, uid 0
Nov 29 15:53:54 pasarela3 pppd[6613]: Using interface ppp0
Nov 29 15:53:54 pasarela3 pppd[6613]: Connect: ppp0 <--> /dev/modem
Nov 29 15:53:54 pasarela3 pppd[6613]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 15:53:58 pasarela3 pppd[6613]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 15:53:58 pasarela3 pppd[6613]: PAP peer authentication succeeded for prueba
Nov 29 15:53:59 pasarela3 pppd[6613]: found interface eth0 for proxy arp
Nov 29 15:53:59 pasarela3 pppd[6613]: local IP address 172.16.3.70
Nov 29 15:53:59 pasarela3 pppd[6613]: remote IP address 172.16.3.72
3. Caso 3:
En este caso no se conecta, dado que se rechaza al usuario prueba, en el fichero pap-secrets.
Nov 29 15:52:28 pasarela3 mgetty[6595]: data dev=modem, pid=6595, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 15:52:28 pasarela3 pppd[6595]: pppd 2.4.2 started by root, uid 0
Nov 29 15:52:28 pasarela3 pppd[6595]: Using interface ppp0
Nov 29 15:52:28 pasarela3 pppd[6595]: Connect: ppp0 <--> /dev/modem
Nov 29 15:52:28 pasarela3 pppd[6595]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 15:52:32 pasarela3 pppd[6595]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 15:52:32 pasarela3 pppd[6595]: PAP peer authentication failed for prueba
Nov 29 15:52:32 pasarela3 pppd[6595]: Connection terminated.
Nov 29 15:52:33 pasarela3 pppd[6595]: Hangup (SIGHUP)
Nov 29 15:52:33 pasarela3 pppd[6595]: ioctl(TIOCSETD, N_TTY): Interrupted system call (line 573)
Nov 29 15:52:33 pasarela3 pppd[6595]: Exit.
39
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Nov 29 15:52:33 pasarela3 init: open(/dev/pts/0): No such file or directory
4. Caso 4:
A partir de este caso se usa login, por lo que se comprobará que el usuario del cliente esté
declarado en el sistema; los usuarios serán los vistos con anterioridad para el caso de clientes UNIX.
En este caso en concreto sí se conectará, dado que el fichero pap-secrets permite cualquier usuario y
el usuario prueba está declarado en el sistema.
Nov 29 15:59:23 pasarela3 mgetty[6679]: data dev=modem, pid=6679, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 15:59:23 pasarela3 pppd[6679]: pppd 2.4.2 started by root, uid 0
Nov 29 15:59:23 pasarela3 pppd[6679]: Using interface ppp0
Nov 29 15:59:23 pasarela3 pppd[6679]: Connect: ppp0 <--> /dev/modem
Nov 29 15:59:23 pasarela3 pppd[6679]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 15:59:27 pasarela3 pppd[6679]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 15:59:27 pasarela3 ppp(pam_unix)[6679]: session opened for user prueba by (uid=0)
Nov 29 15:59:27 pasarela3 pppd[6679]: user prueba logged in
Nov 29 15:59:27 pasarela3 pppd[6679]: PAP peer authentication succeeded for prueba
Nov 29 15:59:28 pasarela3 pppd[6679]: found interface eth0 for proxy arp
Nov 29 15:59:28 pasarela3 pppd[6679]: local IP address 172.16.3.70
Nov 29 15:59:28 pasarela3 pppd[6679]: remote IP address 172.16.3.72
5. Caso 5:
En este caso no se conecta el usuario zacho, pues aunque está declarado en el sistema, el
fichero pap-secrets lo rechaza.
Nov 29 16:02:12 pasarela3 mgetty[6726]: data dev=modem, pid=6726, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 16:02:12 pasarela3 pppd[6726]: pppd 2.4.2 started by root, uid 0
Nov 29 16:02:12 pasarela3 pppd[6726]: Using interface ppp0
Nov 29 16:02:12 pasarela3 pppd[6726]: Connect: ppp0 <--> /dev/modem
Nov 29 16:02:12 pasarela3 pppd[6726]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 16:02:16 pasarela3 pppd[6726]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 16:02:16 pasarela3 ppp(pam_unix)[6726]: session opened for user zacho by (uid=0)
Nov 29 16:02:16 pasarela3 pppd[6726]: user zacho logged in
Nov 29 16:02:16 pasarela3 pppd[6726]: PAP peer authentication failed for zacho
Nov 29 16:02:16 pasarela3 ppp(pam_unix)[6726]: session closed for user zacho
Nov 29 16:02:16 pasarela3 pppd[6726]: Connection terminated.
Nov 29 16:02:17 pasarela3 pppd[6726]: Hangup (SIGHUP)
40
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Nov 29 16:02:17 pasarela3 pppd[6726]: ioctl(TIOCSETD, N_TTY): Interrupted system call (line 573)
Nov 29 16:02:17 pasarela3 pppd[6726]: Exit.
Nov 29 16:02:17 pasarela3 init: open(/dev/pts/0): No such file or directory
Desde el cliente se habrá lanzado la siguiente conexión:
Debido a que la autentificación falla, se tendrá el siguiente mensaje de error en el proceso de
conexión con el servidor PPP. No obstante, la información que proporciona no es todo lo completa
posible, de modo que los mensajes del servidor son más específicos y acertados.
41
Práctica 5: Servidor de Acceso a Internet a través de Acceso Telefónico a Redes
Redes de Computadores – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
6. Caso 6:
En este caso tampoco se produce la conexión, tanto si el fichero pap-secrets permite la
conexión a cualquie usuario o simplemente al usuario jou, pues el usuario jou no está declarado en
el sistema.
Nov 29 16:04:10 pasarela3 mgetty[6752]: data dev=modem, pid=6752, caller='none', conn='38400', name='',
cmd='/usr/sbin/pppd', user='/AutoPPP/'
Nov 29 16:04:10 pasarela3 pppd[6752]: pppd 2.4.2 started by root, uid 0
Nov 29 16:04:10 pasarela3 pppd[6752]: Using interface ppp0
Nov 29 16:04:10 pasarela3 pppd[6752]: Connect: ppp0 <--> /dev/modem
Nov 29 16:04:10 pasarela3 pppd[6752]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 16:04:13 pasarela3 pppd[6752]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 29 16:04:13 pasarela3 ppp(pam_unix)[6752]: check pass; user unknown
Nov 29 16:04:13 pasarela3 ppp(pam_unix)[6752]: authentication failure; logname= uid=0 euid=0 tty=/dev/modem
ruser= rhost=
Nov 29 16:04:16 pasarela3 pppd[6752]: PAP peer authentication failed for jou
Nov 29 16:04:16 pasarela3 pppd[6752]: Connection terminated.
Nov 29 16:04:16 pasarela3 pppd[6752]: Exit.
Nov 29 16:04:16 pasarela3 init: open(/dev/pts/0): No such file or directory
42