CONEXIÓN EN RED

Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
CONEXIÓN EN RED
4.1 RUTEO DE IP
4.1.1 Introducción
El Protocolo de Internet (IP), es un protocolo no orientado a conexión y es no confiable. Esto
significa que los paquetes que el genera no siempre llegan a destino, o bien pueden llegar en un
orden distinto al que fueron conformados (incluso pueden llegar con errores). Lo que sí asegura, es
que en caso de que los paquetes lleguen, lo hagan al destino indicado.
Y de esto se trata el ruteo o encaminamiento (routing), que lo podríamos definir como el
procedimiento para que los paquetes generados en un computador, lleguen al destino correcto.
Obviamente, si las máquinas origen y destino están en la misma red, entonces el ruteo es sencillo. De
otro modo, IP tiene que decidir por que rutas (o caminos) enviarlos hacia su destino.
La decisión por dónde enviar los paquetes, es un proceso implementado por un dispositivo
denominado ruteador o encaminador (“router”). El mismo está conectado a más de una red, y es
capaz de recibir paquetes originados en una de esas redes que están destinado hacia otra, y
encaminarlo adecuadamente. Es el elemento indispensable para hacer llegar un paquete originado en
una red con destino en otra red.
Cabe revisar también el concepto de gateway, originalmente asignado a una máquina que convertía
de un protocolo a otro, por ejemplo, Ethernet a PPP. Actualmente la diferencia entre router y
gateway es borrosa, y en general se utilizan ambos términos indistintamente.
4.1.2 Como se envian los paquetes IP sobre Ethernet
Vamos a aclarar el mecanismo por el cual un paquete IP es enviado hacia su destino. Cada vez que
un host decide enviar un paquete hacia una dirección IP determinada, compara las redes origen y
destino valiéndose de la máscara de red configurada.
Si la dirección destino pertenece a la red del host que origina el paquete, el paso siguiente es buscar,
mediante un protocolo llamado ARP (“Address Resolution Protocol”), la dirección física (también
llamada “MAC address”) del host destino. Finalmente, se utiliza esta dirección para generar la trama
Ethernet que saldrá a través de la interfase de red hacia su destino.
Si en cambio la dirección de destino no pertenece a la red origen, hay que tomar la decisión de
ruteo. Supongamos que se resuelve rutear el paquete a través de un host (que debe pertenecer a la
Módulo IV: Conexión en Red
1
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
red origen). En este caso, el protocolo ARP buscará la dirección física del router, y la trama ethernet
será destinada hacia él.
No está de más aclarar que no se cambia la dirección IP destino de un paquete ruteado, pues
de hacerlo, el router no sabría luego por dónde reenviar el paquete, que ciertamente no está
destinado hacia él, sino sólo encaminado a través de él.
4.1.3 Ruteo estático
El camino que un paquete recorre desde su origen hasta su destino, es llamado ruta. Cada máquina
puede tener una o más rutas definidas estáticamente para cada destino.
Figura 1: Ejemplo de una Inter-red.
En la figura 1 vemos 4 redes Ethernet, A, B, C y D que constituriría una especie de backbone.
También hay 4 hosts de Linux funcionando como routers, llamados L1, L2a, L2b y L3, cuya
función principal es conectar las redes A, B y C con el backbone. L2a tiene la particularidad de
poseer una interfase conectada a la red C.
En Linux, el paquete iproute2 nos brinda las herramientas necesarias para el ruteo. Contiene un
comando, ip, con el que haremos todas las operaciones necesarias. Más información sobre este
paquete se encuentra en http://snafu.freedom.org/linux2.2/docs/ip-cref/ipcref.html.
Por ejemplo, si quisiéramos ver la tabla de ruteo del router L3, deberiamos ejecutar:
L3:~ # ip route show
Módulo IV: Conexión en Red
2
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
10.3.0.0/16 dev eth0 proto kernel scope link src 10.3.0.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.3
El resultado nos indica que hay dos interfases físicas activas en el router, eth0 y eth1. Muestra las
redes a las que pertenecen (10.3.0.0/16 y 192.168.0.0/24 respectivamente), y las direcciones de
origen que tendrán los paquetes que salgan por esas interfases. En otras palabras, este router “sabe”
cómo comunicarse con hosts en las dos redes a las que está directamente conectado.
El parámetro proto kernel indica que las rutas fueron establecidas por el kernel durante la
autoconfiguración (cuando se levantaron las interfases). Las rutas que sean agregadas a mano,
acusarán proto static.
El parámetro scope link indica que la dirección sólo tiene sentido dentro de esta conexión.
Veamos ahora la tabla de ruteo del host LC5, dentro de la red C:
LC5:~ # ip route show
10.3.0.0/24 dev eth0
proto kernel
scope link
src 10.3.0.5
Lo que se puede observar es que tiene sólo una interfase de red activa, y que no podrá enviar
paquetes fuera de la red C a la cual pertenece. Si quisieramos comunicarla con cualquier máquina en
la red B, deberíamos agregar una ruta a través de L2a:
LC5:~ # ip route add 10.2.0.0/16 via 10.3.0.2 dev eth0 proto static
LC5:~ # ip route show
10.3.0.0/16 dev eth0 proto kernel scope link
10.2.0.0/16 via 10.3.0.2 dev eth0 proto static
src 10.3.0.5
Con esta ruta LC5 podrá enviar exitósamente paquetes a cualquier host de la red B, por ejemplo, a
LB9. No hay que olvidar que para que LB9 pueda enviar respuestas a LC5 de ser necesario, debe
contar con un mecanismo para rutear los paquetes de vuelta.
Con la información que contamos hasta ahora, una forma de asegurarse de que LB9 sea capaz de
enviar paquetes hacia LC5 es configurándole una ruta hacia la red C, a traves de L2a.
Una ruta más larga, a traves de L2b o incluso L2a, saliendo hacia el backbone y entrando a la red C
por L3 también sería una opción. Configuremos L2b para este fin:
L2b:~ # ip route show
10.2.0.0/16 dev eth0 proto kernel scope link src 10.2.0.2
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.21
L2b:~ # ip route add 10.3.0.0/16 via 192.168.0.3 proto static
L2b:~ # ip route show
Módulo IV: Conexión en Red
3
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
10.2.0.0/16 dev eth0 proto kernel scope link src 10.2.0.2
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.21
10.3.0.0/16 via 192.168.0.3 dev eth1 proto static
No fue necesario especificar dev eth1 dado que el kernel puede en general determinar este
parámetro por sí mismo. Podría ser útil al contar con más de una interfase configuradas en la misma
red; en este caso, el kernel elegiría siempre la primera (la ethx con el menor valor de x posible) para
todas las rutas que salgan por la red, y lo deseable puede ser distribuirlas estáticamente entre las
interfases disponibles.
Ahora, las máquinas de B tienen una ruta a través de la pasarela, router o gateway L2b para
responder a las de C.
Devolvamos nuestra atención a L2a, el caso más particular, dado que posee 2 caminos para
alcanzar C. Supongamos que originalmente, L2a no estaba conectado a C; a medida que transcurrió
el tiempo, el tráfico entre B y C se hizo muy intenso y comenzó a verse limitado por la velocidad de
la conexión al backbone. Por diversos motivos, los diseñadores optaron por realizar la conexión que
ahora une L2a con C.
A continuación, dirigieron todo el tráfico entre B y C para que se realice por L2a, configurando este
router y todos los hosts de B y C a tales fines. Pero el tiempo siguió pasando, y el tráfico,
aumentando. Gracias a la característica particular del tráfico entre estas redes de no ser muy sensible
al retardo, tenemos la opción de enviar la mitad a traves del backbone. Para hacer esto, utilizaremos
el balance de carga que iproute2 nos permite:
L2a:~ # ip route show
10.2.0.0/16 dev eth0 proto kernel scope link src 10.2.0.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.2
10.3.0.0/16 dev eth2 proto kernel scope link src 10.3.0.2
L2a:~ # ip route del 10.3.0.0/16
L2a:~ # ip route add 10.3.0.0/16 proto static \
nexthop via 10.3.0.2 dev eth2 weight 1 \
nexthop via 192.168.0.3 dev eth1 weight 1
L2a:~ # ip route show
10.2.0.0/16 dev eth0 proto kernel scope link src 10.2.0.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.2
10.3.0.0/16 proto static
nexthop via 10.3.0.2 dev eth2 weight 1
nexthop via 192.168.0.3 dev eth1 weight 1
Lo primero que hicimos fue eliminar la ruta que el kernel crea por defecto para la interfase eth2,
especificando lo mínimo indispensable para la identificación de dicha ruta en la tabla.
Módulo IV: Conexión en Red
4
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Luego se creó la nueva ruta, la palabra clave nexthop permite especificar varios caminos para una
misma ruta, y weight es un parámetro de preferencia. De este modo, la comunicación entre las
redes a traves de L2a será balanceada en partes iguales por ambas rutas, la directa y la que pasa
por L3.
Lo que resta sería configurar las rutas de los hosts de B y C para que usen L2a al intercomunicarse.
Esto es una tarea trivial para las máquinas en B, pero no para las de C, que tienen que observar el
balance de carga en el sentido inverso, por lo que veremos un ejemplo de estas:
LC5:~ # ip route show
10.3.0.0/16 dev eth0 proto kernel scope link
10.2.0.0/16 via 10.3.0.2 dev eth0 proto static
src 10.3.0.5
LC5:~ # ip route del 10.2.0.0/16
LC5:~ # ip route add 10.2.0.0/16 proto static \
nexthop via 10.3.0.2 dev eth0 weight 1 \
nexthop via 10.3.0.1 dev eth0 weight 1
LC5:~ # ip route show
10.3.0.0/16 dev eth0 proto kernel scope link src 10.3.0.5
10.2.0.0/16 proto static
nexthop via 10.3.0.2 dev eth0 weight 1
nexthop via 10.3.0.1 dev eth0 weight 1
No hay que olvidar configurar L3 para que pueda manejar el tráfico de C hacia B:
L3:~ # ip route add 10.2.07.0/16 via 192.168.0.2 proto static
Con esto quedaría configurado los hosts Linux actuando como router para la interred mostrada en la
figura 1.
4.1.4 Default Gateway
Vamos a destacar una particularidad del esquema de ruteo estático visto anteriormente. Llevemos la
atención al hecho de que hay que configurar las rutas estáticas en cada host de la red que las
necesite. En ciertos casos, principalmente en redes pequeñas, donde no se desea dar comunicación
entre redes más que lo necesario y no se preven modificaciones en la topología, puede ser un
método práctico.
Si, por el contrario, la red es grande, con un gran número de hosts que necesitan interconexión, o se
desea tener la posibilidad de hacer cambios rápidos en el ruteo, es más conveniente definir un
default gateway (gateway por defecto).
Módulo IV: Conexión en Red
5
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Este router, pasarela o gateway contiene las rutas de manera centralizada, haciendo innecesario el
mantenimiento de todas las rutas en cada uno de los hosts, consecuentemente aliviando el trabajo de
los administradores y el fastidio de los usuarios a la hora de hacer cambios y resolver problemas.
Cuando un host no encuentre una ruta adecuada para enviar un paquete, lo enviará al router por
defecto, quien se encargará de encaminarlo hacia su destino según su conocimiento de las rutas de la
red.
En nuestro esquema de redes, esto se traduce en 3 default gateways, L1 para los hosts en la red
A, L2a para B, y L3 para C. Veamos una posible configuración del más sencillo, L1:
L1:~ # ip route show
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.0.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
L1:~ # ip route add 10.2.0.0/16 via 192.168.0.21 proto static
L1:~ # ip route add 10.3.0.0/16 via 192.168.0.3 proto static
L1:~ # ip route show
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.0.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
10.2.0.0/16 via 192.168.0.21 dev eth1 proto static
10.3.0.0/16 via 192.168.0.3 dev eth1 proto static
En esta topología es posible encaminar el tráfico hacia la red C tanto por L2a como por L3. El
tráfico hacia B se rutea por L2b para no congestionar más el vínculo del backbone a L2a.
Ahora hay que hacer saber a L2a, L2b y L3 sobre cómo llegar a la red A, y a partir de ese
momento, cualquier host de las 3 redes podrá comunicarse con cualquier otro con sólo tener una
ruta a su default gateway. Veamos LC5 de nuevo:
LC5:~ # ip route show
10.3.0.0/16 dev eth0 proto kernel scope link src 10.3.0.5
10.2.0.0/16 proto static
nexthop via 10.3.0.2 dev eth0 weight 1
nexthop via 10.3.0.1 dev eth0 weight 1
LC5:~ # ip route del 10.2.0.0/16
LC5:~ # ip route add default via 10.3.0.1
LC5:~ # ip route show
10.3.0.0/16 dev eth0
default via 10.3.0.1
proto kernel
dev eth0
scope link
src 10.3.0.5
Pero resulta que aquí hemos perdido el balance de carga en un sentido. Entonces, configuremos L3:
L3:~ # ip route show
Módulo IV: Conexión en Red
6
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
10.3.0.0/16 dev eth0 proto kernel scope link src 10.3.0.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.3
10.2.0.0/16 via 192.168.0.2 dev eth1 proto static
L3:~ # ip route del 10.2.0.0/16
L3:~ # ip route add 10.2.0.0/16 proto static \
nexthop via 10.3.0.2 dev eth0 weight 1 \
nexthop via 192.168.0.2 dev eth1 weight 1
L3:~ # ip route show
10.3.0.0/16 dev eth0 proto kernel scope link src 10.3.0.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.3
10.2.0.0/16 proto static
nexthop via 10.3.0.2 dev eth0 weight 1
nexthop via 192.168.0.2 dev eth1 weight 1
Y con esto obtenemos casi la misma configuración que teníamos antes de usar los default
gateways. Es bueno saber que la estructura de routers por defecto puede anidarse. Por ejemplo,
sería posible (aunque probablemente no bueno) definir a L2a como default gateway de la red D,
mantener todas las reglas ahí (quitarlas de los demás routers), y que L1, L2b y L3 le reenvíen el
tráfico que no sea local.
Otra opción sería que L1 de pronto contase con conexión a Internet. Para que las máquinas de B y
C puedan “salir” por L1, habría que establecerla como default gateway de los otros routers.
4.1.5 Reglas de ruteo
Este esquema de default gateway parece uniformizar o generalizar lo que antes estaba
particularizado. Por ejemplo, supongamos que anteriormente un subconjunto de máquinas de la red
A tenía la ruta para llegar a C a través de L2a. Ahora eso desapareció. Una solución sería configurar
esas rutas nuevamente en esos hosts, pero sería un retroceso. Otra solución, es usar reglas de ruteo.
Si hemos configurado el kernel con las opciones “IP: advanced router” e “IP: policy routing” (SuSE
las tiene) podemos crear reglas de ruteo para aplicarlas a casos particulares.
Cuando el kernel necesita tomar una decisión de ruteo, consulta una tabla donde se encuentran las
reglas. Inicialmente, hay tres tablas: local, main y default. La herramienta ip tal cual la
estuvimos utilizando, modifica las dos primeras, al igual que el antiguo comando route (en desuso).
A continuación crearemos nuevas tablas con rutas especiales, y reglas que al cumplirse envíen al
kernel a buscar en estas nuevas tablas, permitiéndonos saltear las rutas generales que uniformizaban
el encaminamiento.
Módulo IV: Conexión en Red
7
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Cuando veíamos las rutas con el comando ip route list, Linux nos estaba mostrando sólo las
que estaban en la tabla main. Ahora ip rule list nos mostrará las demás tablas existentes:
L1:~ # ip rule list
0:
from all lookup local
32766: from all lookup main
32767: from all lookup default
Las tablas pueden ser llamadas por números, o por nombres. Los nombres deben estar en el archivo
/etc/iproute2/rt_tables. Es algo muy conveniente poner nombres a las tablas, pues hacen
más clara la lectura. Crearemos una tabla llamada especiales_A y una regla para solucionar el
problema de las máquinas de la red A que deben llegar a C a través de L2a:
L1:~
L1:~
L1:~
L1:~
#
#
#
#
echo 200 especiales_A >> /etc/iproute2/rt_tables
ip route add 10.3.0.0/16 via 192.168.0.2 table especiales_A
ip rule add from 10.1.250.0/24 table especiales_A
ip route flush cache
El último comando borra el cache de ruteo, lo que obliga a conexiones ya establecidas a ser tratadas
como nuevas.
Tener en cuenta que puede haber tablas sin reglas que apunten a ellas, y que permanecerán cargadas
hasta que las rutas que contienen sean eliminadas. Esto quiere decir que ip rule list puede no
mostrar todas las tablas. Para ver las reglas de todas las tablas hay que usar ip route list
table all.
Para eliminar todas las reglas de una tabla, podemos utilizar ip route flush table nombre.
Pero hay que tener mucho cuidado pues si especificamos la tabla main, el host dejará de rutear
paquetes. Esto podría ser especialmente catastrófico si estamos conectados remotamente.
Mediante el uso de reglas, Linux desarrolla su máximo espectro de ruteo, dado que pueden
configurarse para esperar coincidencias en IP de origen o destino, TOS (Type of Service), interfase
de entrada, y la más amplia de todas, fwmark, que es una marca que iptables puede asociar a un
paquete dentro del host.
4.1.6 Ruteo dinámico
El gran problema con el ruteo estático que aquí se ha descrito, es que si un gateway o enlace falla
en la red, entonces la única manera en que podrá dirigir sus datagramas por otra dirección, si es que
existe, es interviniendo manualmente y ejecutando las órdenes apropiadas. Naturalmente esto es
poco elegante, lento, nada práctico y peligroso. Se han desarrollado varias técnicas para ajustar
automáticamente las tablas de encaminamiento en el caso de fallos en la red donde hubiera caminos
Módulo IV: Conexión en Red
8
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
alternativos. Todas estas técnicas se agrupan de manera no muy oficial bajo la definición protocolos
de ruteo dinámico.
Consideremos a modo de ejemplo la red mostrada en la figura 2:
Figura 2: Red de ejemplo para Protocolos de Ruteo Dinámicos
Tenemos tres routers L1, L2 y L3. Cada uno da servicio a un segmento Ethernet con una red IP de
clase C y además se conecta con uno de los otros encaminadores a traves de un vínculo o enlace
PPP para formar un triángulo entre ellos.
Debería estar claro que la tabla de encaminamiento de L1 podría ser algo como:
L1:~ # ip route show
192.168.1.0/24 dev
10.0.0.2 dev ppp0
10.0.0.3 dev ppp1
192.168.2.0/24 via
192.168.3.0/24 via
eth0 proto kernel scope link src 192.168.1.1
proto kernel scope link src 10.0.0.1
proto kernel scope link src 10.0.0.101
10.0.0.2 dev ppp0 proto static
10.0.0.3 dev ppp1 proto static
Esto funcionaría bien hasta que el enlace entre los encaminadores L1 y L2 fallase. A partir de ese
momento, las máquinas del segmento Ethernet de L1 (red A) no podrán alcanzar a las del segmento
Ethernet de L2 (red B) porque sus datagramas serán dirigidos al enlace ppp0 de L1 que está mal.
Podrían seguir comunicándose todavía con las máquinas que están detrás de L3, y las de la red C
con las de B, porque el enlace entre L2 y L3 aún está intacto.
Entonces, si L1 puede hablar con L3 y éste con L2, ¿por qué no puede L1 encaminar sus
datagramas para L2 a través de L3 y dejar que éste los encamine hacia la L2? Para este tipo de
problemas fueron diseñados los protocolos de encaminamiento dinámico. Si cada uno de los routers
L1, L2 y L3 está ejecutando el demonio de encaminamiento, entonces sus tablas deberían ser
ajustadas automáticamente para reflejar el nuevo estado de la red si alguno de los enlaces falla.
Es probable que RIP (“Routing Information Protocol”), junto con OSPF (“Open Shortest Path First
Protocol”) sean los protocolos de ruteo dinámico más comunes en la actualidad. RIP es muy común
Módulo IV: Conexión en Red
9
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
en redes pequeñas, como las redes corporativas pequeñas y medianas. OSPF es más moderno y
más capaz de gestionar grandes configuraciones de red, y está mejor preparado para entornos
donde haya un gran número de caminos posibles a través de la red. Las implementaciones habituales
de estos protocolos son: routed (RIP) y gated (RIP, OSPF y otros). El programa routed suele
venir incluido en las distribuciones de Linux, y si no, estará incluido en el paquete NetKit.
4.1.7 RIP
RIP fue originalmente desarrollado por Xerox y llamado Gateway Info (GWInfo), y luego
evolucionó hacia routed. La razón de su popularidad radica en su simplicidad y en que está
incorporado en el código de encaminamiento del BSD UNIX que constituye la base para muchas
implementaciones de UNIX.
RIP es un protocolo de vector-distancia que envía la tabla de ruteo completa en broadcast a cada
router vecino a determinados intervalos. El intervalo por defecto es de 30 segundos. RIP utiliza el
número de saltos como métrica de las rutas, siendo 15 el número máximo de saltos. Una métrica de
16 significa que la red destino no se puede alcanzar.
El hecho de que use un protocolo de vector-distancia implica que a la hora de elegir una ruta entre
varias posibles, RIP tomará la de menor métrica, esto es, la que pase por menos routers. Hay que
prestar atención a este detalle, porque esta ruta puede no ser la más rápida.
Cada vez que un router reciba un mensaje de otro diciendo que puede alcanzar la red X a un costo
de N saltos, el primero actualizará su tabla de ruteo indicando que puede alcanzar la red X a un
costo de N+1 enviando los paquetes al segundo router.
4.1.7.1 Limitaciones de RIP
RIP no está diseñado para resolver cualquier posible problema de encaminamiento. El RFC 1720
(STD 1) describe estas limitaciones técnicas de RIP como "graves" y el IETF está evaluando
candidatos para reemplazarlo. Entre los posibles candidatos están OSPF("Open Shortest Path First
Protocol" Versión 2) y el IS-IS de OSI IS-IS (ver IS-IS("Intermediate System to Intermediate
System" de OSI)). Sin embargo, RIP está muy extendido y es probable que permanezca sin sustituir
durante algún tiempo. Tiene las siguientes limitaciones:
?
El coste máximo permitido en RIP es 16, que significa que la red es inalcanzable. De esta
forma, RIP es inadecuado para redes grandes (es decir, aquellas en las que la cuenta de
saltos puede aproximarse perfectamente a 16).
Módulo IV: Conexión en Red
10
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
?
RIP no soporta máscaras de subred de longitud variable(variable subnetting). En un
mensaje RIP no hay ningún modo de especificar una máscara de subred asociada a una
dirección IP.
?
RIP carece de servicios para garantizar que las actualizaciones proceden de routers
autorizados. Es un protocolo inseguro.
?
RIP sólo usa métricas fijas para comparar rutas alternativas. No es apropiado para
situaciones en las que las rutas necesitan elegirse basándose en parámetros de tiempo real
tales como el retardo, la fiabilidad o la carga.
?
Convergencia lenta. El algoritmo vector-distancia está diseñado para que todos los routers
compartan su información de encaminamiento regularmente. Eventualmente, todos los
routers deben poseer la misma información. Esto es llamado convergencia.
Desafortunadamente, el algoritmo de RIP es lento para conseguir convergencia,
especialmente cuando la información que debe propagarse es de cambios en la topología. Si
consideramos el peor caso de redes separadas a 15 saltos, con la frecuencia de
actualización por defecto de 30 segundos, tomaría varios minutos en que ambos routers
tengan la misma información.
?
El protocolo necesita utilizar algoritmos especiales para evitar la cueanta hasta infinito (un
lazo de ruteo), lo que limita su operatividad a redes pequeñas. La resolución de la cuenta
hasta infinito se efectúa usando las técnicas split horizon, poisoned reverse y triggered
updates.
De todas maneras, el atractivo de RIP nunca fue su capacidad técnica, sino su sencillez y su amplia
distribución y uso. Para aquellos que usaban RIP tenía más sentido migrar a una nueva versión de
RIP que solucionara algunos problemas de RIP-1 que pasar a un protocolo totalmente distindo. Así
se desarrolló RIP Versión 2 (RIP-2), definido en la RFC 2453 ( Noviembre de 1998).
4.1.7.2 RIP y SuSE
Configurar las máquinas para solucionar el problema con ruteo dinámico usando RIPv2 es más
sencillo que administrar las rutas estáticas. SuSE incluye en el paquete quagga todas las
herramientas necesarias para este propósito. Estas serían, básicamente zebra, que administra las
rutas del kernel, y ripd, el demonio de RIP versiones 1, 2 y 3. También hay demonios para OSPF
2 y 3 y BGPv4.
La arquitectura de Quagga dispone que ripd maneje el protocolo RIP y comunique la información de
rutas a zebra, quien finalmente refleja la topología en el kernel en ejecución.
Módulo IV: Conexión en Red
11
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Los archivos de configuración necesarios, zebra.conf y ripd.conf, se encuentran en
/etc/quagga, y una configuración básica sería la siguiente:
!zebra.conf
!
hostname quagga
password quagga
enable password quagga
log file /var/log/quagga/quagga.log
!ripd.conf
!
hostname ripd
password ripd
enable password ripd
!
router rip
network eth0
!
El primer archivo define el nombre del host y password de la consola de zebra. El segundo hace lo
mismo para ripd, con el adicional de que activa el protocolo RIPv2 en las redes conectadas a la
interfaz eth0.
La consola de ambos “demonios” puede ser accedida por medio del protocolo telnet, en el puerto
especificado por el parámetro --vty_port en la línea de comando al llamar a los programas. Lo
que nosotros veremos es la consola de ripd, y para llegar a ella hará falta editar /etc/init.d/ripd y
agregar el parámetro mencionado en la llamada al demonio, por ejemplo para un puerto elegido
arbitrariamente:
startproc $RIPD_BIN –d --vty_port=2606
Luego, rczebra start && rcripd start para iniciar los demonios. A partir de este momento,
podremos acceder a su consola con telnet localhost 2606. Allí encontraremos una interfaz
similar al IOS de Cisco desde donde se puede controlar ripd.
El demonio de encaminamiento buscará mensajes RIPv2 en eth0 para poder actualizar la tabla de
encaminamiento en el host.
Los puntos importantes relacionados con el encaminamiento dinámico son:
1. Sólo necesita ejecutar un protocolo de encaminamiento dinámico cuando su máquina Linux
tenga la posibilidad de elegir entre múltiples caminos para llegar a un destino.
Módulo IV: Conexión en Red
12
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
2. El demonio de encaminamiento dinámico modificará automáticamente la tabla de
encaminamiento para ajustarla a los cambios en la red.
3. RIP es adecuado para redes de tamaño pequeño y medio.
Para obtener mayor información sobre el encaminamiento dinámico de SuSE, buscar en
http://www.quagga.net.
4.2 T UNELES
4.2.1 Introducción
Un túnel es un vínculo que conecta dos redes de forma transparente desde el punto de vista del
protocolo IP. Los datagramas entran por un extremo, son transportados de alguna forma y salen por
el otro extremo inalterados. En otras palabras, es un método para conectar redes a través de otras
redes.
Son útiles a la hora de interconectar dos redes IP que normalmente no podrían hacerlo, por tener
espacio de direcciones privadas, por ejemplo.
Muchas empresas actualmente utilizan túneles para implementar una VPN (Virtual Private
Network) y de esta manera mantener su red empresarial agrupada y además posibilitar a sus
empleados conectarse a ella desde cualquier parte del mundo como si estuvieran en la oficina.
Los túneles mal configurados, sin embargo, pueden traer muchas complicaciones (y constituir un
riesgo a la seguridad), por lo que hay que ser muy cuidadoso en el momento de la implementación
de esta funcionalidad.
Los túneles incrementan el overhead dado que necesitan un conjunto extra de encabezados IP
(típicamente 20 bytes). Esto implica que si el MTU de las redes es de 1500 bytes, por el túnel sólo
podrán pasar 1480 en un paquete. Esto no necesariamente constituye un problema, pero es un tema
a tener en cuenta.
Este tipo de túneles (también conocido como IP-IP) está soportado en Linux desde sus primeras
versiones (kernel 1.3). Requiere los módulos ipip y new_tunnel. Su configuración es bastante
sencilla. Consideremos el esquema mostrado en la figura 3:
Módulo IV: Conexión en Red
13
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Figura 3: Diagrama para ejemplificar Tuneles IP
Se desea establecer un túnel entre las redes A y B a través de C. Para ello, configuraremos L1 y L2
de la siguiente manera:
L1:~ # ifconfig tunl0 10.0.1.1 pointopoint 172.19.20.21
L1:~ # ip route add 10.0.2.0/24 dev tunl0
L2:~ # ifconfig tunl0 10.0.2.1 pointopoint 172.16.17.18
L2:~ # ip route add 10.0.1.0/24 dev tunl0
Con eso se termina la configuración. Cuando el túnel no sea necesario, hay que deshabilitarlo con
ifconfig tunl0 down en caso de L1.
Las limitaciones de este tipo de túneles es que no se puede hacer broadcast ni hacer pasar tráfico
IPv6 a través de ellos. Tampoco es compatible con otros sistemas operativos o routers.
4.2.3 Túneles GRE
GRE es un protocolo de túnel que fue inicialmente desarrollado por Cisco, y es más versátil que IP
en IP. Por ejemplo, se puede enviar tráfico multicast e IPv6 por un túnel GRE. Es necesario el
módulo ip_gre.
Supongamos tener el mismo esquema visto para los túneles IP en IP, la configuración de L1 y L2,
sería:
L1:~ # ip
ttl 255
L1:~ # ip
L1:~ # ip
L1:~ # ip
tunnel add tunl0 mode gre remote 172.19.20.21 local 172.16.17.18
link set tunl0 up
addr add 10.0.1.1 dev tunl0
route add 10.0.2.0/24 dev tunl0
El primer comando crea un túnel y lo llama tunl0, avisa que se usará el protocolo GRE, que la
dirección remota es 172.19.20.21 (L2), que la dirección local del túnel es 172.16.17.18 (lo que
Módulo IV: Conexión en Red
14
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
permite elegir una entre varias posibles conexiones a la red C) y que establecemos el TTL de los
paquetes en 255.
El segundo comando habilita el funcionamiento del dispositivo tunl0, y el tercero le asigna la
dirección 10.0.1.1.
Finalmente, con la cuarta línea se establece la ruta para alcanzar la red B.
Recíprocamente configuraremos L2:
L2:~ # ip
ttl 255
L2:~ # ip
L2:~ # ip
L2:~ # ip
tunnel add tunl1 mode gre remote 172.16.17.18 local 172.19.20.21
link set tunl1 up
addr add 10.0.2.1 dev tunl1
route add 10.0.1.0/24 dev tunl1
Al momento de retirar el túnel en L2, por ejemplo:
L2:~ # ifconfig tunl1 down
L2:~ # ip tunnel del tunl1
Los túneles GRE son actualmente los más utilizados, dado que constituyen un estándar ampliamente
adoptado fuera de la comunidad Linux.
4.3 CONFIGURACIÓN DE CLIENTES Y SERVIDORES
4.3.1 DNS
El Domain Name System (DNS) o Sistema de Nombres de Dominio, permite asociar a cada
dirección IP uno o más nombres. De esta forma, podemos llamar a los hosts de una manera más
significativa y fácil de recordar, como router1.midominio.com.ar.
Actualmente DNS es una herramienta fundamental para Internet. Basta con ponerse a pensar en
todos los sitios que visitamos cuando navegamos y si recordamos la dirección IP de alguno de ellos.
Si en lugar de escribir http://www.google.com.ar para entrar al famoso buscador tuviéramos que
poner http://216.239.59.104, la navegación por Internet sería un proceso bastante tedioso.
El DNS se basa en un esquema cliente-servidor. Hay servidores que contienen las relaciones las
relaciones entre IPs y nombres, y clientes que las consultan.
El DNS es un sistema jerárquico, un sistema con estructura de árbol. La raíz se escribe como “.” y
se denomina root como es habitual para estructuras en árbol. Debajo hay cierto número de
Dominios de Nivel Superior (Top Level Domains, TLDs), los más conocidos son ORG, COM, EDU
y NET, pero hay muchos más.
Módulo IV: Conexión en Red
15
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Cuando se busca una máquina, la pregunta procede recursivamente en la jerarquía comenzando
desde la raíz. Si queremos localizar la dirección de prep.ai.mit.edu, el servidor de nombres tiene
que empezar preguntando en algún sitio. Comienza mirando en el cache. Si sabe la respuesta, por
tenerla en el cache de antes, responderá de inmediato. Caso contrario eliminará partes del nombre
comenzando por la izquierda, comprobando si sabe algo de ai.mit.edu., después mit.edu.,
después edu. y si no, lo que conoce de “.” es lo que tiene el archivo
/var/lib/named/root.hint. Entonces preguntará al servidor . sobre prep.ai.mit.edu. Este
servidor . desconoce la respuesta, pero ayudará a nuestro servidor a encontrar el camino dando la
referencia sobre donde buscar. Estas referencias le dirigen al servidor de nombres que conoce la
respuesta. Ilustramos eso ahora. +norec significa que dig está preguntando consultas no recursivas
para que la obtengamos nosotros mismos. La otras opciones son para reducir lo que dig genera para
no obtener muchas páginas, y @127.0.0.1 indica que la búsqueda debe realizarse en nuestro
servidor de nombres local.
$ dig +norec +noques +nostats +nocmd google.com.ar @127.0.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6092
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 9
;; AUTHORITY SECTION:
.
.
.
.
.
.
.
.
.
.
.
.
.
517227
517227
517227
517227
517227
517227
517227
517227
517227
517227
517227
517227
517227
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
G.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
603627
603627
603627
603627
603627
603627
603627
603627
603627
IN
IN
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
A
A
A
A
A
192.228.79.201
192.33.4.12
128.8.10.90
192.203.230.10
192.112.36.4
128.63.2.53
192.36.148.17
198.32.64.12
202.12.27.33
Esto es una referencia. Nos devuelve una "Authority section" exclusivamente, sin "Answer section".
Nuestro propio servidor de nombres nos envía a un servidor de nombres. Elijamos uno al azar.
Módulo IV: Conexión en Red
16
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
$ dig +norec +noques +nostats +nocmd google.com.ar. @I.ROOT-SERVERS.NET.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53386
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9
;; AUTHORITY SECTION:
ar.
ar.
ar.
ar.
ar.
ar.
ar.
ar.
172800
172800
172800
172800
172800
172800
172800
172800
IN
IN
IN
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
NS
NS
NS
NS.UU.NET.
NS.RIPE.NET.
NS1.RETINA.ar.
ATHEA.ar.
CTINA.ar.
MERAPI.SWITCH.CH.
UUCP-GW-1.PA.DEC.COM.
UUCP-GW-2.PA.DEC.COM.
;; ADDITIONAL SECTION:
NS.UU.NET.
NS.RIPE.NET.
NS1.RETINA.ar.
ATHEA.ar.
CTINA.ar.
MERAPI.SWITCH.CH.
MERAPI.SWITCH.CH.
UUCP-GW-1.PA.DEC.COM.
UUCP-GW-2.PA.DEC.COM.
172800
172800
172800
172800
172800
172800
172800
172800
172800
IN
IN
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
A
A
AAAA
A
A
137.39.1.3
193.0.0.193
200.10.202.3
200.16.98.2
200.16.97.17
130.59.211.10
2001:620::5
204.123.2.18
204.123.2.19
Estos son los servidores de nombres de .ar.
$ dig +norec +noques +nostats +nocmd google.com.ar @ATHEA.ar
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32770
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
google.com.ar.
google.com.ar.
14400
14400
IN
IN
NS
NS
ns.google.com.
ns2.google.com.
Ahora nos envía a los servidores de Google, de donde finalmente obtendremos la respuesta:
$ dig +norec +noques +nostats +nocmd google.com.ar. @ns2.google.com.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12627
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
google.com.ar.
google.com.ar.
google.com.ar.
1800
1800
1800
IN
IN
IN
A
A
A
216.239.57.99
216.239.39.99
216.239.37.99
;; AUTHORITY SECTION:
Módulo IV: Conexión en Red
17
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
google.com.ar.
google.com.ar.
google.com.ar.
google.com.ar.
345600
345600
345600
345600
IN
IN
IN
IN
NS
NS
NS
NS
ns1.google.com.
ns2.google.com.
ns3.google.com.
ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com.
ns2.google.com.
ns3.google.com.
ns4.google.com.
345600
345600
345600
345600
IN
IN
IN
IN
A
A
A
A
216.239.32.10
216.239.34.10
216.239.36.10
216.239.38.10
Podemos ver que hay 3 IPs para el nombre de dominio de google.com.ar. Notar que se puede
agregar el punto final de los nombres de dominio sin problemas. No sucede lo mismo si ponemos un
punto final a la dirección IP; esto llevará a un error.
4.3.1.1 Servidor de Nombres de Dominio
En Linux, el servidor DNS se llama named, y es parte del paquete bind. Como siempre, SuSE
provee el script rcnamed para manejar el servicio desde la consola.
Actualmente hay dos versiones circulando, la 4 (con vulnerabilidades conocidas) y la 8 (sin
vulnerabilidades conocidas). Una forma sencilla de averiguar la versión que estamos utilizando es
fijándonos en la página del manual de named (man named), si al final menciona named.conf, es la
versión 8, si menciona named.boot, es la 4.
La configuración de named se controla desde el archivo /etc/named.conf. A continuación se ve
un extracto de ese archivo con los parámetros más importantes:
options {
# El parámetro directory indica el directorio de trabajo
# del servidor DNS.
directory "/var/lib/named";
# Lista de hasta 3 servidores a los cuales reenviar las consultas
# que no puedan resolverse basándose en las zonas locales.
#forwarders { 192.0.2.1; 192.0.2.2; };
# Habilitar la siguiente línea para dar preferencia al uso
# de los forwarders.
#forward first;
#
#
#
#
El siguiente registro es una lista de las interfases locales
en las cuales el servidor debe escuchar. Opcionalmente se puede
especificar el Puerto. El valor por defecto es
todas las interfases en el puerto 53.
Módulo IV: Conexión en Red
18
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
#listen-on port 53 { 127.0.0.1; };
};
# Las tres siguientes definiciones de zonas no deben ser modificadas.
# La primera es para los servidores raíz, la segunda define este host,
# y la tercera define la búsqueda inverse para este host.
zone "." in {
type hint;
file "root.hint";
};
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
# A partir de aquí se pueden inserter registros de zonas para sus
# propios dominios.
Este servidor configurado de esta manera sirve sólo de caché DNS, puesto que no tiene zonas de
dominios particulares. Una prueba de esto la obtenemos buscando nuevamente google.com.ar en
127.0.0.1. Veremos que la respuesta es inmediata porque el resultado está en el caché.
Los forwarders son útiles para ahorrar ancho de banda, pues cuando una consulta es reenviada,
todo el trabajo de la búsqueda recae sobre el otro servidor, mientras el nuestro se comporta como
un cliente DNS ordinario. La diferencia puede ser significativa si estamos usando un módem
telefónico o si el vínculo al exterior está muy cargado y lento.
Cabe destacar que el archivo root.hint especificado para la zona “.” es fundamental para
búsquedas tales como la que hicimos anteriormente, porque contiene las direcciones IP de los
servidores raíz. Es importante que este archivo esté actualizado, pues de nada sirve que contenga las
viejas IPs de los servidores raíz.
Con el comando dig @G.ROOT-SERVERS.NET. . ns > root.hint.nuevo podemos obtener
directamente una versión actualizada. Hay que revisar el archivo para ver que contenga la palabra
NOERROR, y en caso afirmativo, reemplazar el viejo por éste.
La primera verificación de correcto funcionamiento de un servidor de nombres es:
$ dig -x 127.0.0.1 @127.0.0.1
; <<>> DiG 9.2.2 <<>> -x 127.0.0.1 @127.0.0.1
Módulo IV: Conexión en Red
19
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
;;
;;
;;
;;
global options: printcmd
Got answer:
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36238
flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.
IN
PTR
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 604800
IN
PTR
localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa.
604800
IN
NS
localhost.
;; ADDITIONAL SECTION:
localhost.
604800
IN
A
127.0.0.1
;;
;;
;;
;;
Query time: 2 msec
SERVER: 127.0.0.1#53(127.0.0.1)
WHEN: Mon Mar 14 11:21:31 2005
MSG SIZE rcvd: 93
Si se obtiene una respuesta similar, es porque está funcionando adecuadamente.
Aunque no sea tan mencionado, un dominio muy importante es in-addr.arpa. También se anida
como los dominios “normales”. in-addr.arpa nos permite obtener el nombre de host cuando
tenemos su dirección. Una cosa importante que tenemos que observar es que las direcciones IP se
escriben en orden inverso en el dominio in-addr.arpa. Si tiene la dirección de una máquina:
192.148.52.43 named procede igual que para el ejemplo de prep.ai.mit.edu: encuentra
servidores arpa.. Busca servidores in-addr.arpa., busca servidores 192.in-addr.arpa.,
busca servidores 148.192.in-addr.arpa., busca servidores52.148.192.in-addr.arpa..
Finalmente busca los registros que necesitamos para 43.52.148.192.in-addr.arpa.. Es un
buen método, aunque la inversión de números puede confundir bastante.
Ahora vamos a definir nuestro propio dominio. Vamos a crear el dominio linux.ldr y definir
máquinas en él.
Para los nombres de dominio no se permiten todos los caracteres en nombres de máquina. Estamos
restringidos a los caracteres del alfabeto inglés: a-z, números 0-9 y el carácter “-“ (guión del medio).
Las mayúsculas y minúsculas son indistintas para el DNS.
Hay que tener un cuidado especial con los puntos al final de los nombres de dominios. Estos no
deben ir en named.conf, pero en los archivos de zona, su ausencia indica que lo escrito es relativo
al dominio declarado. Un error aquí puede ser muy difícil de encontrar.
En primer lugar, hay que declarar la zona en named.conf, para lo cual agregamos al final:
Módulo IV: Conexión en Red
20
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
zone "linux.ldr" {
type master;
file "master/linux.ldr";
};
Ahora, hay que crear el archivo de la zona, que será /var/lib/named/master/linux.ldr:
;
; Fichero de zona para linux.ldr
;
; El fichero de zona completo
;
$TTL 3D
@
IN
SOA
ns.linux.ldr. hostmaster.linux.ldr. (
2003150201
; numero de serie
8H
; refresco
2H
; reintento
4W
; expira
1D )
; mínimo
;
TXT
"Linux.LDR, sus consutas DNS"
NS
ns
; Inet Address del SN
NS
ns.sec.ldr.
MX
10 mail
; Relay primario de correo
MX
20 mail.sec.ldr.; Relay secundario de correo
;
localhost
A
127.0.0.1
gw
A
192.168.196.1
ns
A
192.168.196.2
maquina3
A
192.168.196.3
mail
A
192.168.196.4
ftp
A
192.168.196.5
El registro SOA es el preámbulo de todos los archivos de zona y debe haber uno exactamente en
cada archivo de zona. El registro SOA describe la zona, de dónde proviene (una máquina llamada
linux.ldr), quién es el responsable de su contenido ([email protected]), qué versión del
archivo de zona es (Numero de Serie), y otras cosas que tienen que ver con el caché y los
servidores secundarios DNS. Para el resto de los campos (Tasa de Refresco, Tasa de
Reintento, Caducidad para secundario y Tiempo de Validez para Clientes) use los
valores que aparecen aquí para mayor seguridad. Antes de SOA viene una línea obligatoria, la línea
$TTL 3D.
Una vez hecho esto, reiniciamos named para que lea la nueva configuración con rcnamed
restart. Ya podemos probar los resultados con:
$ dig ns.linux.ldr
; <<>> DiG 9.2.2 <<>> ns.linux.ldr
Módulo IV: Conexión en Red
21
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
;;
;;
;;
;;
global options: printcmd
Got answer:
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56191
flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;ns.linux.ldr.
IN
A
;; ANSWER SECTION:
ns.linux.ldr.
259200
IN
A
192.168.196.2
;; AUTHORITY SECTION:
linux.ldr.
linux.ldr.
259200
259200
IN
IN
NS
NS
ns.sec.ldr.
ns.linux.ldr.
;;
;;
;;
;;
Query time: 1 msec
SERVER: 127.0.0.1#53(127.0.0.1)
WHEN: Mon Mar 14 16:21:48 2005
MSG SIZE rcvd: 81
Y con esto tenemos configurada una zona propia en nuestro servidor DNS.
4.3.1.2 Cliente DNS
No hay un “cliente DNS” para configurar. En general, las aplicaciones utilizan una librería que
provee el sistema operativo. Esta librería (llamada resolver) busca el nombre del dominio local por
defecto, y las direcciones IP de los servidores de nombres en el archivo /etc/resolv.conf.
Nuestro archivo debería contener, mínimamente:
search linux.ldr
nameserver 127.0.0.1
La primera línea establece una lista separada por espacios de hasta 6 dominios (o 256 caracteres)
para agregar en caso de que la resolución falle. Por ejemplo, si ponemos ping maquina3, el primer
intento de resolver fallará, entonces el resolver intentará con maquina3.linux.ldr, que tendrá éxito.
La segunda línea especifica la dirección IP de un servidor de nombre. Pueden haber hasta un
máximo de 3 líneas como esta, para especificar un servidor primario y dos de respaldo.
4.4. NFS
NFS (Network File System) permite acceder a archivos y directorios remotos de la misma forma
que se accedería a ellos si fuesen locales. Esto permite centralizar ficheros en una localización,
mientras se permite su acceso continuo a los usuarios autorizados.
Módulo IV: Conexión en Red
22
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Hay dos versiones de NFS actualmente en uso. La versión 2 de NFS, que tiene varios años, es
ampliamente soportada por muchos sistemas operativos. La versión 3 tiene más características y
mejor performance. SuSE soporta ambas, y por defecto utiliza la 3.
Linux usa una combinación de soporte a nivel de kernel y demonios en continua ejecución para
proporcionar compartición de ficheros NFS, y el soporte NFS debe estar activo en el kernel de
Linux para que funcione.
4.3.1 NFS y portmap
NFS se apoya en las llamadas de procedimientos remotos (RPC) para funcionar. Se requiere
portmap para trazar las peticiones RPC a los servicios correctos. Los procesos RPC notifican a
portmap cuando comienzan, revelando el número de puerto que ellos están monitoreando y el
número de programas RPC que esperan servir. El sistema cliente entonces contacta con el portmap
del servidor con un número de programa RPC particular. Entonces portmap redirecciona al cliente
al número del puerto apropiado para que se comunique con el servicio apropiado.
Como los servicios basados en RPC confian en portmap para hacer todas las conexiones con las
peticiones de clientes entrantes, portmap debe estar disponible antes que cualquiera de esos
servicios comienze. Si, por alguna razón, el servicio portmap inesperadamente se quita, reinicie
portmap y cualquier servicio que estuviera ejecutándose entonces. SuSE nos facilita la interacción
con este servicio por medio de rcportmap.
El servicio portmap revisa los ficheros de accesos de máquinas (/etc/hosts.allow y
/etc/hosts.deny) para controlar a qué sistemas remotos les son permitidos usar servicios
basados en RPC en su máquina. Las reglas de control de acceso para portmap afectarán a todos
los servicios basados en RPC. Alternativamente, puede especificar a cada uno de los demonios
RPC NFS para que sean afectados por una regla de control específica. Las páginas man de
rpc.mountd y rpc.statd contienen información relativa a la sintaxis precisa de estas reglas.
Como portmap proporciona la coordinación entre servicios RPC y los números de puertos
utilizados para comunicarlos, es útil plasmar una imagen de los servicios RPC actuales que están
usando portmap cuando estamos resolviendo algún problema. El comando rpcinfo muestra cada
servicio basado en RPC con su número de puerto, número de programa RPC, versión y tipo de
protocolo (TCP o UDP).
Para asegurarse que los servicios NFS basados en RPC están activos para portmap, rpcinfo
puede ser útil:
# rpcinfo -p nfs.linux.ldr
program vers proto
port
100000
2
tcp
111
100000
2
udp
111
100024
1
udp
1024
100024
1
tcp
1024
Módulo IV: Conexión en Red
portmapper
portmapper
status
status
23
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
100011
100011
100005
100005
100005
100005
100005
100005
100003
100003
100021
100021
100021
1
2
1
1
2
2
3
3
2
3
1
3
4
udp
udp
udp
tcp
udp
tcp
udp
tcp
udp
udp
udp
udp
udp
819
819
1027
1106
1027
1106
1027
1106
2049
2049
1028
1028
1028
rquotad
rquotad
mountd
mountd
mountd
mountd
mountd
mountd
nfs
nfs
nlockmgr
nlockmgr
nlockmgr
La opción -p prueba el portmap de la máquina especificada, o en la máquina local por defecto si
no se especifica ninguna máquina. Otras opciones están disponibles en la página de manual de
rpcinfo.
De la salida anterior, varios servicios NFS pueden verse ejecutándose. Si uno de los servicios NFS
no comienza correctamente, portmap puede ser incapaz de corresponder las peticiones RPC con
sus respectivos puertos. En muchos casos, reiniciando NFS como root (rcnfsserver restart)
provocará que estos servicios funcionen correctamente con portmap y empiecen a funcionar.
4.3.2 El servidor NFS
Trabajando con portmap, otros procesos se aseguran que una conexión particular NFS esté
permitida y pueda proceder sin error. Estos procesos constituyen el servidor NFS, y entre ellos
están rpc.mountd, y rpc.nfsd. Todos los procesos necesarios son controlados por el script
rcnfsserver que provee SuSE para controlar el funcionamiento del servidor.
Es sencillo configurar un sistema para compartir ficheros y directorios usando NFS. Cada Sistema
de ficheros que se exporta a usuarios remotos via NFS, así como los derechos de acceso relativos a
ellos, es localizado en el fichero /etc/exports. Este fichero es leído por el comando exportfs
que da a rpc.mountd y rpc.nfsd la información necesaria para permitir el montaje remoto de un
sistema de ficheros por una máquina autorizada.
El comando exportfs -a permite actualizar los directorios exportados luego de modificaciones en
/etc/exports sin reiniciar los servicios NFS.
El fichero /etc/exports es el estándar para controlar que sistemas de ficheros son exportados a
que máquinas, así como para especificar opciones particulares que controlen todo. Las líneas en
blanco son ignoradas, se pueden comentar líneas con #, y las líneas largas pueden ser divididas con
una barra invertida (\). Cada sistema de ficheros exportado debe tener su propia línea. La lista de
Módulo IV: Conexión en Red
24
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
máquinas autorizadas colocada después de un sistema de ficheros exportado, debe estar separada
por un espacio. Las opciones para cada uno de las máquinas deben ser colocadas entre paréntesis
directamente detrás del identificador de la máquina, sin ningún espacio de separación entre la
máquina y el primer paréntesis.
De esta sencilla manera, /etc/exports sólo necesita saber el directorio a exportar y las máquinas
que pueden utilizarlo:
/un/directorio bob.domain.com
/otro/directorio/exportado 192.168.0.3
Después de reexportar /etc/exports con el comando exportfs -a, la máquina
bob.domain.com será capaz de montar /un/directorio, y 192.168.0.3 podrá montar
/otro/directorio/exportado. Como no hay opciones especificadas en este ejemplo, varias
preferencias por defecto toman efecto:
?
ro
?
async
?
wdelay
?
root_squash
Sólo lectura (read-only). Las máquinas que monten este sistema de ficheros no podrán
cambiarlo. Para permitirlas que puedan hacer cambios en el sistema de ficheros, debe
especificar la opción rw (lectura-escritura - read-write).
Permite al servidor escribir los datos en el disco cuando lo crea conveniente.
Mientras que esto no tiene importancia en un sistema de sólo lectura, si una máquina hace
cambios en un sistema de ficheros de lectura-escritura y el servidor se cae o se apaga, se
pueden perder datos. Especificando la opción sync, todas las escrituras en el disco deben
hacerse antes de devolver el control al cliente. Esto bajará el rendimiento.
Provoca que el servidor NFS retrase el escribir a disco si sospecha que otra
petición de escritura es inminente. Esto puede mejorar el rendimiento reduciendo las veces
que se debe acceder al disco por comandos de escritura separados. Use no_wdelay para
desactivar esta opción, la cual sólo funciona si está usando la opción sync.
Hace que cualquier cliente que acceda al sistema de ficheros exportado
(como root en la máquina cliente), se convierta en el ID del usuario nobody. Esto
reconvierte el poder del usuario root remoto al de usuario local más bajo, previniendo que
los usuarios root remotos puedan convertirse en usuarios root en el sistema local.
Alternativamente, la opción no_root_squash lo descativa. Para reconvertir a todos los
usuarios, incluyendo a root, use la opción all_squash. Para especificar los ID de usuario y
grupo para usar con usuarios remotos desde una máquina particular, use las opciones
anonuid y anongid respectivamente. De esta manera, puede crear una cuenta de usuario
especial para usuarios NFS remotos para compartir y especificar (anonuid=<uidvalue>,anongid=<gid-value>), donde <uid-value> es el número ID de usuario y
<gid-value> es el número ID de grupo.
Módulo IV: Conexión en Red
25
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Para saltarse estas opciones predeterminadas, debe especificar la opción que desea cambiar. Por
ejemplo, si no especifica la opción rw, entonces se exportará en sólo lectura. Cada opción
predeterminada debe ser explícitamente sobreescrita con su opción correspondiente.
Adicionalmente, hay otra opciones que están disponibles que no afectan a las predeterminadas.
Estas incluyen desactivar el navegar por subdirectorios, permitir el acceso a puertos inseguros, y
permitir bloquear ficheros inseguros (necesario para algunas implementaciones antiguas de clientes
NFS). Vea la página man de exports para estas opciones menos usadas.
Para especificar máquinas a las que permitir usar un sistema de ficheros en concreto, podemos usar
varios métodos, entre los que se incluyen:
?
una sola máquina — Cuando una máquina en particular es especificada con nombre
completo de dominio, nombre de máquina o dirección IP.
?
comodines — Cuando usamos un caracter * o ? para referirnos a un grupo de nombres
completos de dominio o direcciones IP o que coincidan con una cadena particular de letras.
Sin embargo, sea cuidadoso cuando use comodines con nombres de dominios completos, e
intente ser lo más exacto que pueda. Por ejemplo, el uso de *.domain.com como comodín,
permitirá a ventas.domain.com acceder al sistema de ficheros exportado, pero no a
bob.ventas.domain.com. Para permitir ambas posibilidades, así como a
sam.corp.domain.com, debería usar *.domain.com *.*.domain.com.
?
redes IP — Permite el acceso a máquinas basadas en sus direcciones IP dentro de una red
más grande. Por ejemplo 192.168.0.0/24 y 192.168.0.0/255.255.255.0 son equivalentes.
?
grupos de redes — Permite que un nombre de grupo de red NIS, escrita como @<groupname>, sea usada. Esto pone al servidor NIS controlando el acceso de este sistema de
ficheros, donde los usuarios pueden ser añadidos o borrados de un grupo NIS sin que
afecte a /etc/exports.
La manera en que el fichero /etc/exports está organizado es muy importante, particularmente lo
que concierne a los espacios en blanco. Recuerde separar siempre los sistemas de ficheros
exportados de máquina a máquina y de uno a otro con un espacio. Sin embargo, no debería haber
otros espacios en el fichero a menos que se usen en líneas comentadas.
Por ejemplo, las siguientes dos líneas significan cosas distintas:
/home maquina3.linux.ldr(rw)
/home maquina3.linux.ldr (rw)
La primera línea permite sólo a los usuarios de maquina3.linux.ldr acceder en modo de lecturaescritura al directorio /home. La segunda línea permite a los usuarios de maquina3.linux.ldr
montar el directorio de sólo lectura (el predeterminado), pero el resto del mundo puede instalarlo
como lectura-escritura.
Módulo IV: Conexión en Red
26
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Otra cuestión a tener en cuenta, que ya fue mencionada, pero conviene recordarla, es que portmap
se fija en /etc/hosts.allow y /etc/hosts.deny para determinar si a una máquina particular le
debe ser explícitamente permitido o denegado su acceso. Por ende, el primer archivo debería
contener al menos:
statd: .linux.ldr
mountd: .linux.ldr
Estas dos líneas permitirán a los hosts del dominio linux.ldr conectarse a los servicios RPC
rpc.statd y rpc.mountd, y por ende, al servidor NFS de estar permitido esto en
/etc/exports.
Finalmente, es fundamental tener en cuenta que los privilegios de montajes NFS son permitidos
específicamente a máquinas, no a usuarios. Si permite a un sistema acceder a una parte en concreto
de su disco duro, los usuarios de esa máquina podrán acceder a esos datos compartidos.
Por ende, al configurar el fichero /etc/exports, sea extremadamente cuidadoso cuando comparta
directorios con permisos de lectura y escritura (rw) a un sistema remoto. Los usuarios de sistemas
remotos que monten su sistema de ficheros exportados, pueden modificar los datos, intentar ataques
de DoS, etc.
4.3.3 El cliente NFS
Como se ha comentado, para que una máquina cliente pueda utilizar un sistema de ficheros nfs, este
debe de haber sido compilado en el kernel estáticamente o como módulo.
Para que un cliente pueda utilizar un sistema de ficheros exportado por un servidor NFS, es
utilizando el comando mount. Es decir los volúmenes NFS se montan de la misma forma que el
resto de sistemas de ficheros:
mount -t nfs dirnfs dirlocal opciones
Por ejemplo:
# mount -t nfs mis01:/home /home
Las opciones son las típicas de mount, y pueden ser encontradas en su página de manual.
Para evitar el trabajo de escribir el comando con las opciones en volúmenes montados con
frecuencia, es posible incluirlos en /etc/fstab, por ejemplo:
server:/usr/local/pub
/pub
Módulo IV: Conexión en Red
nfs
rsize=8192,wsize=8192,timeo=14,intr
27
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Indica que hay que montar server:/usr/local/pub en /pub (local), que es un sistema de
archivos de tipo NFS y algunas opciones específicas de mount para NFS. De este modo, el
volumen se montará en el inicio del sistema, y por ende los beneficiarios del sistema no dependerán
de un superusuario que de la orden de montaje.
De haber muchos sistemas de archivos de red para montar, por cuestiones de uso de recursos no
conviene montar todos los NFSs en el arranque, puesto que tal vez muchos tengan baja utilización.
En estos casos, SuSE tiene un sistema de montaje automático, llamado automount, que resulta una
solución ideal. Ver la página de manual de automount y autofs para más información.
4.4 DHCP
DHCP (Dynamic Host Configuration Protocol) es un protocolo con arquitectura cliente / servidor
que ofrece un mecanismo automático para obtener los parámetros de configuración de una interfaz
de red TCP/IP a través de un servidor, que ofrece sus servicios en una red de área local. Fue
creado por el Grupo de Trabajo Dynamic Host Configuration del IETF, organización de
definición protocolos para Internet.
Es un protocolo de asignación de direcciones distribuidas basado en un mecanismo de consulta.
Normalmente se utiliza para simplificar la configuración de los equipos y también para escenarios
donde hay más equipos que direcciones disponibles.
Es útil para proporcionar de un modo rápido la configuración de red del cliente pues de esta forma
dicha configuración se reduce a la selección por parte del administrador del uso del protocolo
DHCP y nada mas. El cliente recupera esta información desde el servidor DHCP.
También es útil si un administrador desea cambiar la dirección de IP de muchos sistemas. En lugar
de volver a configurar todos los sistemas, puede modificar una fichero de configuración DHCP en el
servidor para establecer la nueva dirección IP. Si los servidores DNS de una organización cambian,
los cambios también se aplicarán en el servidor DHCP, no en todos los clientes DHCP.
Además, si un portátil o cualquier tipo de equipo móvil se configura para DHCP, podrá desplazarse
entre distintas subredes sin tener que volver a configurarlo, ya que cada idealmente cada subred
dispondrá de un servidor DHCP que permitirá su conexión a la red.
DHCP está basado en el protocolo BOOTP, creado con el fin de permitir la configuración
automática de máquinas que se arrancan conectadas a una red TCP/IP, asignando siempre la misma
dirección a las máquinas sin reutilizarlas. DHCP añadió la posibilidad de usar direcciones de red
reusables, de tal forma que no es necesario tener tantas direcciones IP como máquinas, siempre de
que se esté seguro de que no se utilizan todas las máquinas a la vez. Este es un sistema muy utilizado
por los proveedores de Internet por acceso telefónico y en redes a las que se conectan usuarios
esporádicos.
Módulo IV: Conexión en Red
28
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Está compuesto por dos componentes principales:
1. El protocolo para la transmisión de los parámetros de configuración de una interfaz TCP/IP
desde el servidor a los clientes. El formato de los paquetes está basado en el protocolo
BOOTP, y permite la compatibilidad entre los clientes de este tipo y los servidores de
DHCP.
2. El mecanismo para la asignación de las distintas direcciones a los clientes.
El servidor admite tres tipos de configuración de direcciones IP:
1. Estática. Se configura en el servidor la dirección de red que se corresponde con la dirección
LAN del cliente (equivalente a BOOTP).
2. Dinámica, por tiempo ilimitado. Se indica un rango de direcciones que se asignan a cada
cliente de carácter permanente, hasta que el cliente la libera.
3. Dinámica, arrendada. Las direcciones se otorgan por un tiempo ilimitado. Un cliente debe
renovar su dirección para poder seguir utilizándola.
El servidor DHCP tiene dos bases de datos, una de direcciones estáticas, y otra para las dinámicas.
Cuando recibe una petición, primero chequea su base de datos estática. Si existe una entrada para
esa dirección física, se devuelve la dirección IP estática correspondiente. Si no se encuentra la
entrada, el servidor selecciona una IP disponible de la base de datos dinámica y añade la nueva
asociación a la base de datos.
Cuando el período de tiempo de asignación de la dirección dinámica (que fue negociado al inicio)
expira, el cliente tiene que renovar el período o dejar de usar la dirección. El servidor tiene la opción
de aceptar o rechazar la renovación.
Para obtener una dirección, el procedimiento es de la siguiente manera:
?
El cliente envía un mensaje DHCPDISCOVER broadcast usando el puerto destino 67.
?
Aquellos servidores que puedan dar este tipo de servicio responden con un mensaje
DHCPOFFER, donde se ofrece una IP que será bloqueada. En estos mensajes también
puede ofrecer la duración del alquiler. Si el cliente no recibe dicho mensaje, intenta
establecer conexión cuatro veces más, cada dos segundos, si aún así no hay respuesta,
espera cinco minutos antes de intentarlo de nuevo.
?
El cliente elige una de las IPs ofertadas y envía un mensaje DHCPREQUEST al servidor
seleccionado.
?
El servidor responde con un mensaje DHCPACK y crea la asociación entre la dirección
física del cliente y su IP. Ahora el cliente usa la IP hasta que el alquiler expire.
Módulo IV: Conexión en Red
29
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
?
Al alcanzar el 50% del tiempo del alquiler, el cliente envía otro mensaje DHCPREQUEST
para renovar el alquiler.
?
Si el servidor responde con DHCPACK, el cliente puede seguir usando la IP durante otro
periodo de tiempo. Si se recibe un DHCPNACK, el cliente debe de dejar de usar esa IP y
empezar de nuevo el proceso de obtención de una IP.
?
Si después de transcurrir el 87.5% del alquiler no se recibe respuesta, se manda otro
DHCPREQUEST. Si se recibe un DHCPACK antes de que expire el tiempo de alquiler, se
obtiene más tiempo de alquiler. En caso contrario, se debe comenzar de nuevo el proceso
de obtención de una IP. El cliente puede terminar el alquiler antes de que expire el tiempo.
En este caso, el cliente envía un mensaje DHCPRELEASE al servidor.
4.4.1 El servidor DHCP
Podemos configurar un servidor DHCP mediante el fichero de configuración /etc/dhcpd.conf.
que almacena la información de red de los clientes. Se pueden declarar opciones globales para
todos los clientes y opciones para cada sistema particular. Para reflejar los cambios, hará falta
reiniciar el servicio con rcdhcpd restart.
El archivo de configuración puede contener tabulaciones o líneas en blanco adicionales para facilitar
el formato. Las palabras clave no distinguen entre mayúsculas y minúsculas, y las líneas que
empiezan con un cardina o numeral (#) se consideran comentarios.
Algunos parámetros deben empezar con la palabra clave option.
Los parámetros (incluidas las opciones) declarados antes de una sección encerrada entre llaves ({ })
se consideran parámetros globales. Los parámetros globales se aplican a todas las secciones
situadas (jerárquicamente con respecto a las llaves) “debajo” de ellos.
Tenemos que incluir una sección subnet para cada red que deseemos administrar mediante el
protocolo DHCP:
Todas las subredes que comparten la misma red física deben declararse dentro de una declaración
shared-network, como veremos a continuación. Los parámetros dentro de shared- network,
son globales para las declaraciones subset, pero no se aplican fuera de la shared-network:
shared-network laboratorio_redes {
# Parámetros globales para ambas subredes
option domain-name
"linux.ldr”;
option domain-name-servers
ns.linux.ldr, ns.sec.ldr;
option routers
192.168.1.254;
subnet 192.168.1.0 netmask 255.255.255.0 {
#parámetros deseados aplicables a esta subred
Módulo IV: Conexión en Red
30
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
default-lease-time 600; # 10 minutos
max-lease-time 7200; # 2 horas
range 192.168.1.1 192.168.1.31;
}
subnet 192.168.1.32 netmask 255.255.255.0 {
#parámetros deseados aplicables a esta subred
range 192.168.1.33 192.168.1.63;
}
}
Vemos también que una de las subredes tiene los parámetros default-lease-time y maxlease-time destinados a controlar el tiempo de alquiler de una dirección. Los tiempos se
especifican en segundos. Si los parámetros hubieran estado fuera de la red compartida, se aplicarían
a toda la red compartida y las demás definidas debajo.
El parámetro range permite especificar el rango de direcciones IP disponibles para la asignación
dinámica de una subred. De estar ausente, sólo los hosts declarados explícitamente como se verá
más adelante podrán obtener una dirección en dicha subred.
La declaración group puede utilizarse para aplicar parámetros globales a un grupo de
declaraciones. Puede agrupar redes compartidas, subredes, hosts u otros grupos:
group {
option routers
option subnet-mask
option domain-name
option domain-name-servers
192.168.1.254;
255.255.255.0;
"linux.ldr";
192.168.1.1;
host maquina3 {
option host-name "maquina3.linux.ldr";
hardware ethernet 00:A0:78:8E:9E:AA;
fixed-address 192.168.1.3;
}
host mail {
option host-name "mail.linux.ldr";
hardware ethernet 00:A1:DD:74:C3:F2;
fixed-address 192.168.1.6;
}
}
Se presentan acá 2 hosts configurados estáticamente por medio de su dirección MAC, gracias al
parámetro hardware ethernet de una declaración host. El parámetro opcional host-name
asigna un nombre host al cliente.
Módulo IV: Conexión en Red
31
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
Finalmente, el servidor DHCP está obligado a utilizar un esquema de actualización de DNS, por el
cual indica a un servidor DNS la dirección IP que asigna a ciertos hosts. Este tema está más allá del
alcance de este módulo, por lo que sólo diremos que hay que agregar la línea Ddns-update-style
ad-hoc; en el archivo dhcpd.conf como un parámetro global, o de otro modo no funcionará.
Para obtener una lista completa de sentencias de opciones e información relacionada, consulte la
página del manual de dhcp-options y dhcpd.conf.
4.4.2 El cliente DHCP
Para configurar un cliente DHCP manualmente en SuSE, debe modificar el archivo
/etc/sysconfig/network/ifcfg-eth0 si estamos intentando adquirir la dirección en eth0. Hay
un archivo similar para cada interfase de red instalada por YaST2.
Dentro del archivo basta con establecer el parámetro:
BOOTPROTO=dhcp
4.5 SERVIDOR FTP
El Protocolo de Transferencia de Archivos (File Transfer Protocol) representa un método para
compartir información que subsiste desde las primeras épocas de las redes TCP/IP, y está
ampliamente difundido. Todos los sistemas operativos actuales tienen incorporado por defecto un
cliente para este protocolo, lo que supone una gran ventaja a la hora de considerar implementar un
servidor.
El servidor Pure-FTPd viene incluido en la distribución SuSE bajo un paquete con el mismo nombre.
Su ventaja es ser eficiente, sencillo, y por ende seguro, frente a otros servidores que implementan un
sinnúmero de funciones raras veces utilizadas que les causan vulnerabilidades.
Su archivo de configuración se encuentra en /etc/pureftpd.conf, y a continuación, veremos
algunos de los parámetros importantes:
# Cage in every user in his home directory. Hace creer a cada usuario que
su directorio home es la raíz del sistema, haciendo imposible el acceso al
resto de la estructura real de directorios del sistema. Esto es muy bueno
para la seguridad, y la recomendación es no cambiarlo.
ChrootEveryone
yes
# Maximum number of simultaneous users. Número máximo de usuarios
simultaneos.
MaxClientsNumber
Módulo IV: Conexión en Red
20
32
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
# Fork in background. Para que se ejecute como un demonio.
Daemonize
yes
# Maximum number of sim clients with the same IP address. Número máximo de
conexiones abiertas por IP.
MaxClientsPerIP
3
# Don't allow authenticated users - have a public anonymous FTP only. Con
esto se crea un FTP solo público.
AnonymousOnly
no
# Disallow anonymous connections. Only allow authenticated users. Con esto
en yes, se crea un FTP solo anónimo.
NoAnonymous
no
# Syslog facility (auth, authpriv, daemon, ftp, security, user, local*)
# The default facility is "ftp". "none" disables logging.
# Acá se especifica el origen que declararán los mensajes del ftp en syslog
SyslogFacility
ftp
# 'ls' recursion limits. The first argument is the maximum number of
# files to be displayed. The second one is the max subdirectories depth
# Máximo número de archivos para mostrar y profundidad de directorios
LimitRecursion
2000 8
# Disallow downloading of files owned by "ftp", ie.
# files that were uploaded but not validated by a local admin.
# Los archivos subidos por usuarios no pueden ser bajados hasta haber sido
revisados por un administrador, que tiene que cambiar el propietario.
AntiWarez
yes
# IP address/port to listen to (default=all IP and port 21).
# Dirección IP y puerto en el cual escuchar (todos por defecto, puerto 21)
#Bind
192.168.0.2,21
# Maximum bandwidth for anonymous users in KB/s
# Máximo ancho de banda por cada usuario anónimo en KB/s
# AnonymousBandwidth
#
#
#
#
8
Maximum bandwidth for *all* users (including anonymous) in KB/s
Use AnonymousBandwidth *or* UserBandwidth, both makes no sense.
Máximo ancho de banda para todos los usuarios, en KB/s
Usar este o el anterior, no ambos pues no tiene sentido.
Módulo IV: Conexión en Red
33
Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
# UserBandwidth
8
# This option is useful with servers where anonymous upload is
# allowed. As /var/ftp is in /var, it save some space and protect
# the log files. When the partition is more that X percent full,
# new uploads are disallowed.
# No dejar que se suban archivos si el uso de la partición supera este
porcentaje
MaxDiskUsage
80
En realidad, una vez instalado, está listo para ejecutarse con rcpure-ftpd start sin realizar
modificación alguna a su archivo de configuración. Por defecto, los usuarios del sistema ya podrían
autenticarse por medio de sus cuentas en /etc/passwd y acceder con todos sus permisos a sus
directorios home.
Para realizar más ajustes a la configuración, conviene leer el archivo completo, y si no, dirigirse a
www.pureftpd.org, que es el sitio home del proyecto.
Módulo IV: Conexión en Red
34