Upload
jagui1
View
136
Download
9
Embed Size (px)
Citation preview
Curso de NFS, DHCP y CUPS en GNU/Linux (20 horas)
Teoría, Guía de prácticas y ejercicios
Página 1 de 58
Índice de contenidoObjetivos del curso..................................................................................................4
Requisitos............................................................................................................4
Network File System...........................................................................................5
(Sistema de Archivos en Red)..............................................................................5
Sistema de archivos de red (NFS).......................................................................6
Servicios requeridos........................................................................................8
NFS y portmap.................................................................................................8
Resolución de problemas de NFS y portmap...................................................8
Iniciar y detener NFS......................................................................................9
Configuración del servidor NFS....................................................................10
Archivos de configuración de clientes NFS...................................................14
El archivo /etc/fstab.......................................................................................14
Cómo proteger NFS.......................................................................................17
Uso de NFSv4................................................................................................18
Permisos de archivos.....................................................................................18
El cliente NFS....................................................................................................19
Precauciones con NFS ..................................................................................20
Corriendo NFSv4 a través de un túnel SSH .....................................................22
Configuración del servidor para NFSv4 sobre SSH:.....................................22
Configuración del cliente para NFSv4 sobre SSH:........................................22
Prácticas con NFS ............................................................................................23
Ejercicio 1......................................................................................................23
6. Hacer pruebas tanto en el cliente como en el servidor: Crear archivos, borrarlos, modificarlos y ver lo que pasa con ellos.......................................24
Ejercicio 2: ....................................................................................................24
Ejercicio 3......................................................................................................24
Ejercicio 4......................................................................................................25
Página 2 de 58
Servicio DHCP...................................................................................................26
(Configuración dinámica de clientes IP) ..........................................................26
El servicio DHCP ..................................................................................................27
Tipos de configuraciones y asignaciones con DHCP ........................................28
Operación: Pasos realizados por el cliente DHCP:........................................29
¿Qué ventajas da el DHCP?...............................................................................30
Opciones más importantes que un servidor DHCP puede asignar/proveer a cualquier cliente que lo solicite. ...................................................................31
Datos importantes al configurar servidor DHCP..........................................31
Configuración General del DHCP en GNU/Linux (cualquier distro).............32
Declaración de Subred...................................................................................37
Declaración de shared-network, o red compartida.......................................37
Consideraciones de seguridad.......................................................................39
Instalación y configuración del servidor DHCP en Debian etch / canaima v1.. 40
Practicas con el servicio DHCP..........................................................................41
Configuración de un servidor DHCP en una sola red ó sub-red....................41
Práctica avanzada. (Basado en un caso del examen de certificación LPI, Linux Professional Institute) Nivel: Profesional Avanzado de Linux o LPIC-2 y con modificaciones y adaptaciones de Tecno-Redes Sistemas VCG...........41
Servicio de impresión con el sistema CUPS Common UNIX Printing System..47
¿En qué consiste el sistema de impresión CUPS?.............................................49
Instalar una impresora local con CUPS.............................................................50
Compartir nuestra impresora............................................................................55
Imprimir desde Linux en una impresora Windows............................................59
Página 3 de 58
Objetivos del curso
Instalar y configurar los servicios de NFS (Sistema para compartir directorios
y archivos en una red) , CUPS (Sistema de impresión en Linux) y DHCP
(Configuración dinámicas de IP).
Requisitos
Requiere conocimientos básicos sobre GNU/Linux y Redes TCP/IP.
Página 4 de 58
Network File System
(Sistema de Archivos en Red)
Página 5 de 58
Sistema de archivos de red (NFS)
Un Sistema de archivos de red (NFS) permite a los hosts remotos montar
sistemas de archivos sobre la red e interactuar con esos sistemas de archivos
como si estuvieran montados localmente.
Todas las versiones de NFS pueden utilizar el Protocolo de control de
transmisiones (TCP) ejecutándose sobre una red IP. En el caso de NFSv4, éste lo
requiere. NFSv2 y NFSv3 pueden utilizar el Protocolo de datagrama de usuarios
(UDP) sobre una red IP para proporcionar conexiones de red sin supervisión
(stateless) entre el cliente y el servidor.
Cuando se utiliza NFSv2 o NFSv3 con UDP, bajo condiciones normales la
conexión UDP desatendida minimiza el tráfico de la red, ya que el servidor NFS
envía un cookie al cliente después que este tiene acceso al volumen compartido.
Este cookie es un valor aleatorio guardado en el lado del servidor y es pasado
junto con las peticiones RPC (llamadas remotas) desde el cliente. El servidor
NFS puede ser reiniciado sin afectar a los clientes y las cookies permanecen
intactas. Sin embargo, debido a que UDP es sin supervisión, si el servidor se cae
de forma inesperada, los clientes UDP continúan saturando la red con peticiones
para el servidor. Por esta razón, TCP es el protocolo preferido cuando se conecte
a un servidor NFS.
Cuando se autentifique utilizando NFSv4, se crea una conexión atenta y, de
forma opcional, está disponible la autenticación de usuarios y grupos con
Kerberos. NFSv4 no tiene interacción con portmapper, rpc.mountd, rpc.lockd y
rpc.statd, pues estos han sido incorporados en el kernel. NFSv4 escucha en el
puerto TCP 2049.
TCP es el protocolo por defecto para NFS. UDP se puede utilizar para propósitos
de compatibilidad si se necesita, pero no es recomendado para uso general.
Página 6 de 58
La única vez que NFS lleva a cabo la autenticación es cuando el cliente intenta
montar un recurso compartido NFS. Para limitar el acceso al servicio NFS, se
utilizan envolturas TCP (TCP wrappers). Los TCP wrappers leen los archivos /etc/
hosts.allow y /etc/hosts.deny para determinar si a un cliente particular o red
tiene acceso o no al servicio NFS.
Después de que al cliente se le permite acceso gracias a un TCP wrapper, el
servidor NFS recurre a su archivo de configuración, /etc/exports, para
determinar si el cliente tiene suficientes privilegios para acceder a los sistemas
de archivos exportados. Una vez otorgado el acceso, todas las operaciones de
archivos y de directorios están disponibles para el usuario.
Si se está utilizando NFSv2 o NFSv3, los cuales no son compatibles con la
autenticación Kerberos, los privilegios de montaje de NFS son otorgados al host
cliente, no para el usuario. Por lo tanto, se puede acceder a los sistemas de
archivos exportados por cualquier usuario en un host cliente con permisos de
acceso. Cuando se configuran las unidades compartidas NFS, tenga mucho
cuidado de cuáles hosts obtienen permisos de lectura/escritura (rw).
Para que NFS funcione con una instalación con un cortafuegos instalado,
se debe configurar IPTables con el puerto predeterminado TCP 2049. Sin
una configuración IPTables, NFS no funcionará correctamente. Por ejemplo, la
línea siguiente habilita NFS4 en un Firewall particular:
....iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
........
El script de inicialización NFS y el proceso rpc.nfsd ahora permiten la
vinculación a cualquier puerto especificado durante el inicio del sistema. Sin
embargo, esto puede ser susceptible a errores si el puerto no está disponible o si
entra en conflicto con otro demonio.
Página 7 de 58
Servicios requeridos
NFS y portmap
El servicio portmap bajo Linux asigna 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 supervisando 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 solicitado.
Como los servicios basados en RPC confían en portmap para hacer todas las
conexiones con las peticiones de clientes entrantes, portmap debe estar
disponible antes que cualquiera de esos servicios comience.
El servicio portmap puede utilizar TCP wrappers para el control de acceso, y las
reglas de control de acceso para portmap afectan a todos los servicios basados
en RPC. Alternativamente, es posible especificar reglas de control de acceso
para cada demonio RPC NFS. Las páginas man para rpc.mountd y rpc.statd
contienen información relativa a la sintaxis precisa de estas reglas.
Resolución de problemas de NFS y portmap
Como portmap proporciona la coordinación entre servicios RPC y los números de
puertos usados para comunicarlos, es útil poder visualizar el estado de los
servicios RPC actuales 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 están activos los servicios NFS basados en RPC para
Página 8 de 58
portmap, usar el comando siguiente:
#rpcinfo -p
A continuación se presenta una muestra de la salida de este comando:
programa vers proto puerto 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 1026 status 100024 1 tcp 3019 status 100011 1 udp 939 rquotad 100011 2 udp 939 rquotad 100011 1 tcp 942 rquotad 100011 2 tcp 942 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 udp 1033 nlockmgr 100021 3 udp 1033 nlockmgr 100021 4 udp 1033 nlockmgr 100021 1 tcp 2893 nlockmgr 100021 3 tcp 2893 nlockmgr 100021 4 tcp 2893 nlockmgr 100005 1 udp 960 mountd 100005 1 tcp 963 mountd 100005 2 udp 960 mountd 100005 2 tcp 963 mountd 100005 3 udp 960 mountd 100005 3 tcp 963 mountd
La salida de este comando revela que los servicios NFS correctos se están
ejecutando. Si uno de los servicios NFS no comienza correctamente, portmap
puede ser incapaz de corresponder las peticiones RPC de los clientes para ese
servicio con sus respectivos puertos. En muchos casos, si NFS no está presente
en la salida de rpcinfo, reiniciando NFS provocará que estos servicios se
registren correctamente con portmap y empiecen a funcionar.
Página 9 de 58
Iniciar y detener NFS
Para ejecutar un servidor NFS, debe estar ejecutándose el servicio portmap. Para
verificar que portmap está activo, ejecutar el comando siguiente:
#portmap status
Si el servicio portmap se está ejecutando, entonces se puede iniciar nfs. Para
iniciar un servidor NFS, ejecutar:
#/etc/init.d/nfs-kernel-server start
Para detener el servidor, ejecutar:
#/etc/init.d/nfs-kernel-server stop
La opción restart es un atajo para detener y luego iniciar NFS. Esta es la forma
más eficiente de hacer que los cambios en la configuración tomen efecto luego
de modificar el archivo de configuración por NFS.
Para reiniciar el servidor, ejecutar:
#/etc/init.d/nfs-kernel-server restart
Para reiniciar condicionalmente el servidor, ejecutar:
Para recargar el archivo de configuración del servidor NFS sin reiniciar el
servicio, ejecutar:
#/etc/init.d/nfs-kernel-server reload
Configuración del servidor NFS
El archivo de configuración /etc/exports
El archivo /etc/exports controla cuáles sistemas de archivos son exportados a las
Página 10 de 58
máquinas remotas y especifica opciones. Las líneas en blanco son ignoradas, se
pueden comentar líneas con el símbolo # y las líneas largas pueden ser divididas
con una barra invertida (\). Cada sistema de archivos exportado debe tener su
propia línea y cualquier lista de hosts autorizadas colocada después de un
sistema de archivos exportado, debe estar separada por un espacio. Las opciones
para cada uno de los hosts deben ser colocadas entre paréntesis directamente
detrás del identificador del host, sin ningún espacio de separación entre el host y
el primer paréntesis.
Una línea para un sistema de archivos exportado tiene la estructura siguiente:
() ()...
En esta estructura, reemplazar con el directorio a exportar, con el host o la red a
la cual va a compartir el directorio y con las opciones para ese host o red. Los
hosts adicionales se pueden especificar en una lista separada por espacios.
Se pueden usar los métodos siguientes para especificar nombres de host:
host único — Cuando una máquina en particular es especificada con nombre
completo de dominio, nombre de máquina o dirección IP.
comodines — Usamos un carácter * o ? para referirnos a un grupo de nombres
completos de dominio o direcciones IP o que coincidan con una cadena particular
de letras. Los comodines no se deberían de utilizar con direcciones IP; sin
embargo, es posible para estos funcionar accidentalmente si fallan las búsquedas
de DNS inversas.
Tener cuidado cuando se especifiquen comodines con nombres de dominio
completos, pues tienden a ser más exactos de lo que se cree. Por ejemplo, el uso
de *.ejemplo.com como comodín, permitirá a ventas.ejemplo.com acceder al
sistema de archivos exportado, pero no a tom.ventas.ejemplo.com. Para coincidir
ambas posibilidades, debería usar *.ejemplo.com y también *.*.ejemplo.com
Página 11 de 58
redes IP — Permite la coincidencia de hosts basados en sus direcciones IP
dentro de una red más grande. Por ejemplo, 192.168.0.0/28 permite al acceso a
las primeras 14 direcciones IP, desde la 192.168.0.1 a la 192.168.0.14, acceder
al sistema de archivos exportado, pero no a la 192.168.0.16 (0 y 15 no
permitidas) y superiores.
grupos de redes — Permite usar un nombre de grupo de red NIS, escrito como
@. Esto pone al servidor NIS controlando el acceso de este sistema de archivos,
donde los usuarios pueden ser añadidos o borrados de un grupo NIS sin que
afecte a /etc/exports.
En su forma más sencilla, el archivo /etc/exports sólo especifica el directorio a
exportar y los hosts que pueden usarlo, como en el ejemplo siguiente:
/exportado/home/vcasti vcasti.telecomvcg.net
En el ejemplo, vcasti.telecomvcg.net puede montar /exportado/home/vcasti/.
Como no se especifica ninguna opción en este ejemplo, tomarán efecto las
siguientes opciones predeterminadas de NFS:
ro — Se montan los sistemas de archivos como de sólo lectura (read-only). Los
host remotos no pueden hacer cambios a los datos compartidos en el sistema de
archivos. Para permitir que los hosts puedan hacer cambios, debe especificar la
opción rw (lectura-escritura, read-write).
wdelay — 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.
root_squash — Previene a los usuarios root conectados remotamente de tener
privilegios como root asignándoles el id del usuario de nobody. Esto reconvierte
Página 12 de 58
el poder del usuario root remoto al de usuario local más bajo, previniendo la
alteración desautorizada de archivos en el servidor remoto. Alternativamente, la
opción no_root_squash lo desactiva. 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 un host particular, utilice las
opciones anonuid y anongid, respectivamente. De esta manera, puede crear
una cuenta de usuario especial para que los usuarios NFS remotos compartan y
especificar (anonuid=nnnn,anongid=nnn), donde nnn es el número de ID del
usuario y es el número de ID del grupo.
Por defecto, las listas de control de acceso (ACLs) son soportadas por NFS. Para
desactivar esta funcionalidad, especifique la opción no_acl cuando esté
exportando el sistema de archivos.
Cada valor predeterminado para un sistema de archivos exportado debe ser
explícitamente ignorado. Por ejemplo, si no se especifica la opción rw, entonces
el sistema de archivos es exportado como de sólo lectura. Lo siguiente es una
línea de muestra de /etc/exports la cual sobreescribe dos opciones
predeterminadas:
/exportado/data 192.168.0.3(rw,sync)
En este ejemplo 192.168.0.3 puede montar /exportado/data/ como
lectura/escritura y todas las transferencias al disco son efectuadas antes de
completar la petición de escritura del cliente.
Adicionalmente, hay otras opciones que están disponibles que no tienen
especificado un valor predeterminado. Estas incluyen la habilidad de desactivar
la verificación por subdirectorios, permitir el acceso desde puertos inseguros y
permitir bloquear archivos inseguros (necesario para algunas implementaciones
antiguas de clientes NFS). Vea la página man de exports para estas opciones
menos usadas.
Página 13 de 58
La manera en que el archivo /etc/exports está organizado es muy importante,
particularmente lo que concierne a los espacios en blanco. Recuerde separar
siempre los sistemas de archivos exportados de una máquina a la otra, con un
espacio. Sin embargo, no debería haber otros espacios en el archivo a menos que
se usen en líneas comentadas.
Por ejemplo, las siguientes dos líneas significan cosas distintas:
/home vcasti.telecomvcg.net(rw)
/home vcasti.telecomvcg.net (rw)
La primera línea permite sólo a los usuarios de vcasti.telecomvcg.net acceder en
modo de lectura/escritura al directorio /home. La segunda línea permite a los
usuarios de vcasti.telecomvcg.net montar el directorio como de sólo lectura (el
predeterminado), pero el resto del mundo puede instalarlo como
lectura/escritura.
Archivos de configuración de clientes NFS
Las comparticiones NFS son montadas en el lado del cliente usando el comando
mount. El formato del comando es como sigue:
mount -t nfs 192.168.0.74:/home /mnt/prueba_home
Reemplazar con nfs para servidores NFSv2 o NFSv3, o nfs4 para servidores
NFSv4, con una lista de opciones separadas por comas para el sistema NFS, con
el host remoto, con el directorio remoto que está siendo montado y con el
directorio local donde el sistema de archivos remoto se montará.
Si está accediendo a una compartición NFS emitiendo manualmente el comando
mount, el sistema de archivos debe ser remontado manualmente después de
reiniciar el sistema.
Página 14 de 58
El archivo /etc/fstab
El archivo /etc/fstab lo referencia el servicio nfs al momento del arranque, por lo
que las líneas haciendo referencia a las comparticiones NFS tienen el mismo
efecto que escribir manualmente el comando mount durante el arranque.
Una muestra de línea de /etc/fstab para montar un NFS exportado será parecida
a:
valiente01:/usr/local /usr/local nfs osuid,hard,intr 0 0
Reemplazar con el nombre de la máquina, dirección IP o nombre de dominio
totalmente cualificado del servidor que exporta el sistema de archivos, con la
ruta al directorio exportado, con el sistema de archivos local en el cual se
montará el directorio exportado. Este punto de montaje debe existir antes de que
/etc/fstab sea leído o el montaje fallará, con nfs para servidores NFSv2 o NFSv3,
o con nfs4 para servidores NFSv4, con una lista de opciones separada por comas
para el sistema NFS
Opciones de montaje NFS
Aparte de montar un sistema de archivos a través de NFS en un host remoto,
existe un número de diferentes opciones que pueden ser especificadas al
momento del montaje que pueden hacerlo más fácil de usar. Estas opciones
pueden usarse con el comando manual mount, configuraciones /etc/fstab
Las siguientes son opciones populares utilizadas para montajes NFS:
fsid=num — Obliga a que las configuraciones de manejo y de atributos de
archivos en el cable, a ser num, en vez de un número derivado desde el número
menor y principal ('minor' y 'major') del dispositivo de bloques en el sistema de
archivos montado. El valor 0 tiene un significado especial cuando se utiliza con
NFSv4. NFSv4 tiene un concepto de raíz del sistema de archivos exportado en
general. El punto de exportación con fsid=0 se utiliza como esta raíz.
Página 15 de 58
hard o soft — Especifican si el programa que usa un archivo vía una conexión
NFS, debe parar y esperar (hard) a que el servidor vuelva a estar en línea, si el
host que sirve el sistema de archivos no está disponible, o si debe informar de un
error (soft).
Si se especifica la opción hard, el usuario no podrá terminar el proceso que está
esperando que la comunicación NFS se reanude a menos que especifique la
opción intr.
Si usa soft, puede usar la opción adicional timeo=, donde especifica el número
de segundos que deben pasar antes de informar del error.
intr — Permite que se interrumpan las peticiones NFS si el servidor se cae o no
puede ser accedido.
noacl — Apaga todo el procesamiento de ACL.
nolock — Desactiva el bloqueo de archivos.
noexec — No permite la ejecución de binarios en sistemas de archivos
montados. Esto es útil si el sistema está montando un sistema de archivos no
Linux a través de NFS que contiene binarios incompatibles.
nosuid — No permite que los bits set-user-identifier o set-group-identifier tomen
efecto. Esto previene que los usuarios remotos obtengan privilegios mayores
ejecutando un programa setuid.
port=num — Especifica el valor numérico del puerto del servidor NFS. Si num
es 0 (el valor predeterminado), entonces mount consulta al portmapper del host
remoto por el número de puerto. Si el demonio NFS del host remoto no está
registrado con su portmapper, se utilizará el número de puerto estándar de NFS,
TCP 2049.
rsize=num and wsize=num — Estas configuraciones pueden acelerar la
comunicación NFS tanto para lecturas (rsize) como para escrituras (wsize),
Página 16 de 58
configurando un tamaÑo de bloque de datos mayor, en bytes, que serán
transferidos de una sola vez. Tenga cuidado al cambiar estos valores; algunos
kernels antiguos de Linux y tarjetas de red no funcionan bien con grandes
tamaños de bloques. Para NFSv2 o NFSv3, los valores por defecto para ambos
parámetros está configurado a 8192. Para NFSv4, los valores por defecto para
ambos parámetros es 32768.
sec=mode — Especifica el tipo de seguridad a utilizar cuando se autentique una
conexión NFS.
sec=sys es la configuración por defecto, lo que utiliza UNIX UIDs y GIDs locales
a través de AUTH_SYS para autentificar las operaciones NFS.
sec=krb5 utiliza Kerberos V5 en vez de UNIX UIDs y GIDs locales para
autentificar a los usuarios.
sec=krb5i utiliza Kerberos V5 para la autenticación de usuarios y realiza la
verificación de integridad de las operaciones NFS usando sumas de verificación
para prevenir el daños de los datos.
sec=krb5p utiliza Kerberos V5 para la autenticación de usuarios, la verificación
de integridad y encriptar el tráfico NFS para prevenir el husmeo del mismo. Esta
es la configuración más segura, pero también tiene la sobrecarga de rendimiento
más grande.
tupe — Especifica que se utilice el protocolo TCP para el montaje NFS.
pudu — Especifica que NFS utilice el protocolo UDP para el montaje.
Página 17 de 58
Cómo proteger NFS
NFS trabaja muy bien compartiendo sistemas de archivos enteros con un gran
número de hosts conocidos de una manera muy transparente. Sin embargo, esta
facilidad de uso trae una variedad de problemas potenciales de seguridad.
Acceso al sistema
La versión de NFS que planee implementar, depende de su red existente y de sus
preocupaciones de seguridad. La sección siguiente explica las diferencias entre
las medidas de seguridad con NFSv2, NFSv3 y NFSv4. Si es posible, utilice
NFSv4. Es el más recomendado.
Uso de NFSv4
El lanzamiento de NFSv4 trajo consigo una revolución para la autenticación y la
seguridad cuando se comparten directorios a través de NFS. NFSv4 manda la
implementación del módulo del kernel RPCSEC_GSS, el mecanismo GSS-API de
la versión Kerberos 5, SPKM-3, y LIPKEY. Con NFSv4, los mecanismos de
seguridad obligatorios están orientados hacia la autenticación de usuarios
individuales y no a máquinas clientes, como lo hace NFSv2 y NFSv3.
Se asume que se tiene instalado un servidor de entrega de tíckets (KDC) y que
está configurado de la forma correcta, antes de configurar el servidor NFSv4.
NFSv4 incluye el soporte a ACL basado en el modelo de Microsoft Windows NT,
no en el modelo POSIX, por sus funcionalidades y porque es implementado
ampliamente. NFSv2 y NFSv3 no son compatibles con los atributos nativos de
ACL.
Otra funcionalidad de seguridad importante de NFSv4 es la eliminación del
demonio rpc.mountd. El demonio rpc.mountd presentaba posibles agujeros de
seguridad debido a la forma en que trataba con los manejadores de archivos.
Página 18 de 58
Permisos de archivos
Una vez que el sistema de archivos es montado como lectura/escritura por un
host remoto, la única protección que tiene cada archivo compartido son sus
permisos. Si dos usuarios que comparten el mismo valor de identificador de
usuario montan el mismo NFS, ellos podrán modificar sus archivos mutuamente.
Adicionalmente, cualquiera con acceso root en el sistema cliente puede usar el
comando su - para volverse un usuario que tenga acceso a determinados archivos
a través de la compartición NFS.
Por defecto, las listas de control de acceso (ACLs) son soportados por NFS. No se
recomienda desactivar esta funcionalidad.
El comportamiento predeterminado cuando se está exportando un sistema de
archivos a través NFS es usar aplastamiento de root (root_squash). Esto coloca
el identificador del usuario de cualquiera que esté accediendo a la compartición
NFS, como el usuario root en su máquina local a un valor de la cuenta de
nfsnobody. Nunca desactive el aplastamiento (squashing) de root.
Si se está exportando una compartición NFS como de sólo lectura,
considere usar la opción all_squash, la cual hace que todos los usuarios
accesando el sistema de archivos exportado tomen el ID de usuario del
nfsnobody.
El cliente NFS
El acceso al sistema de archivos exportado por NFS está controlado
directamente por el núcleo. El archivo /proc/filesystems contiene una lista con
todos los sistemas de archivos soportados directamente por el núcleo. Entonces,
lo único que tiene que hacer es decir al núcleo que quiere acceder a un sistema
exportado por NFS.
Página 19 de 58
El comando mount permite acceder a diferentes sistemas de ficheros.
Informa al núcleo que está disponible un nuevo sistema de ficheros indicando su
tipo, su dispositivo y su punto de montaje. Se puede usar la opción -t para indicar
el tipo del sistema de ficheros a usar. Para NFS, escribimos: -t nfs (para nfs
versión 3) o -t nfs4 (para nfs versión 4)
Supongamos que la máquina valiente01 tiene un servidor NFS y exporta
su directorio /home/abrito. Cuando quiera acceder desde la máquina powerman,
tendrá que montar el directorio exportado de valiente01 a powerman:
root@powerman:
#mount -t nfs -o nosuid,hard,intr valiente01:/usr/local /usr/local
Nótese que valiente01 puede ser sustituido por su ip.
El comando indica que estamos montando un sistema de ficheros NFS (-t
nfs), con las opciones nosuid, hard e intr. Los dos últimos argumentos son los
más interesantes. El primero de ellos especifica el dispositivo a montar. Para
NFS la sintaxis es distinta de la línea mount habitual, donde se especifica
dispositivo y directorio. Aquí especificamos servidor:directorio_exportado en vez
de dispositivo. El último argumento indica la localización del sistema de ficheros
en la parte cliente. Hemos compartido exactamente el /usr/local de valiente01
con powerman. Así podemos evitar el tener que instalar programas en /usr/local
más de una vez. Para hacer esta configuración permanente, podemos
especificarlo en el archivo /etc/fstab de powerman. fstab contiene todos los
dispositivos que serán montados en el arranque. La sintaxis para /etc/fstab es:
#device mount point file system options dump fsckorder
valiente01:/usr/local /usr/local nfs osuid,hard,intr 0 0
Sin embargo, deberá tener cuidado con una entrada permanente. Sólo
podrá usarlo cuando el servidor (valiente01) esté siempre encendido, o cuando
encienda valiente01 antes que powerman.
Página 20 de 58
Precauciones con NFS
Uno de los mayores problemas con NFS viene del hecho de que exista por
defecto una relación de confianza entre un cliente y un servidor NFS. En el caso
de que la cuenta root del servidor esté comprometida, la del cliente también lo
estará.
Un cliente no debe confiar ciegamente en un servidor, por ello debemos
especificar opciones restrictivas cuando usamos el comando mount. Ya hemos
mencionado la primera de ellas: nosuid. Cancela el efecto de los bits SUID y GID.
Con esto alguien que esté como root en el servidor, primero debe hacer login en
el cliente como un usuario normal y después hacerse root. Otra opción, más
restrictiva, es noexec. Prohíbe ejecutar programas en sistema de ficheros
exportado. Esta opción únicamente se utiliza en sistemas que sólo contengan
datos.
En el lado del servidor NFS, podemos especificar que no confíe en la
cuenta root del cliente. Tenemos que especificarlo en /etc/exports con la opción
root_squash. Entonces si un usuario con UID 0 (root) en el cliente accediese al
sistema de ficheros exportado por el servidor, tomaría el UID nobody para
consultar ficheros. Esta opción está activada por defecto bajo Linux pero se
puede desactivar con la opción no_root_squash. Se puede especificar qué
opciones deben aplicarse en un conjunto de UIDs. Recuerde también que las
opciones anonuid y anongid permiten cambiar los UID/GID de nobody por los de
otro usuario diferente.
Algunas opciones son más generales y se efectúan por el portmapper. Por
ejemplo, prohibimos el acceso a todas las máquinas con la siguiente línea en el
archivo /etc/hosts.deny:
#hosts.deny : absolute prohibition for every one to use the portmap
portmap: ALL
Página 21 de 58
Después en el archivo /etc/hosts.allow esta estricta prohibición se puede
contrarrestar permitiendo el acceso a las máquinas deseadas.
Unas buenas reglas de cortafuegos también contribuyen a una protección
mejor. Observe los puertos usados por los diferentes servicios y los protocolos
utilizados:
Servicio RPC Puerto Protocolos
portmap 111 upd / tcp
nfsd 2049 udp
mountd variable udp / tcp
Corriendo NFSv4 a través de un túnel SSH
La configuración es similar a un caso de montar un directorio Read/Write con
NFSv4. Lo único es que la IP se debe cambiar a 127.0.0.1 (dirección loopback ).
Configuración del servidor para NFSv4 sobre SSH:
1. En /etc/exports:
/exportfs 127.0.0.1(rw,fsid=0,insecure,no_subtree_check,sync)
2. re-exportar:
exportfs -rv
Configuración del cliente para NFSv4 sobre SSH:
1. en /etc/fstab:
127.0.0.1:/privado /mnt/privado nfs4 rw,hard,intr,proto=tcp,port=8888,noauto 0 0
Página 22 de 58
Ahora configuramos una sesión SSH con port forwarding. Usaremos encriptación
AES. En lugar de utilizar el puerto TCP 2049 para el puerto local, usaremos el
puerto TCP 8888, esto para mostrar que los clientes NFSv4 y SSH en túnel no
les importa que puertos están utilizando. Abrimos una sesión desde el cliente
NFS4 al servidor NFS:
# ssh -2 -x -c aes128-cbc -L 8888:127.0.0.1:2049 fc2
#password:
#
La sesión SSH puede ser establecida como usuario regular, no se necesita ser
"root".
En el cliente abrimos otro terminal como "root" y montamos el filesystem:
# mount -v /mnt/privado
127.0.0.1:/privado on /mnt/privado- type nfs4 (rw,hard,intr,proto=tcp,port=8888,addr=127.0.0.1)
Para desmontarlo, ejecutamos #umount -v /mnt/privado-nfs.
Prácticas con NFS
Ejercicio 1
Compartiendo un directorio (en toda la red local)
1. Crea un directorio llamado compartido_nfs (o el nombre que prefiera)
dentro de tu directorio de trabajo:
mkdir compartido_nfs (o mkdir /home/usuario/compartido_nfs)
2. Inicia sesión de root con el comando su y edita (con nano, vi, gedit, etc.)
elarchivo /etc/exports, para añadir una línea como la siguiente:
/home/usuario/compartido_nfs *(ro,sync)
3. Exportamos el filesystem: exportfs -r
Página 23 de 58
4. Reiniciamos el servicio nfs /etc/init.d/nfs-kernel-server restart
5.En el cliente: Creamos un directotio para el montaje. Por ejemplo: /mkdir /mnt/compartido y lo montamos:
mount -t nfs 192.168.1.10:/home/usuario/compartido_fs
6. Hacer pruebas tanto en el cliente como en el servidor: Crear archivos,
borrarlos, modificarlos y ver lo que pasa con ellos.
Ejercicio 2:
Compartiendo un directorio con permiso de lectura y escritura
1. Crear como usuario (use el suyo), sin iniciar sesión de root el
directorio /home/usuario/LE (LE abreviación de lectura y escritura).
2. ¿Qué tenemos que escribir en /etc/exports para compartirlo en modo rw?
3. ¿Qué comando tenemos que ejecutar, tras editar este archivo, para activar los
cambios en el servidor NFS?
4. Crear algún directorio y monta en él el directorio /home/usuario/LE
compartido por alguno de tus compañeros. ¿Puedes crear alguna carpeta
en este directorio? ¿En qué PC se crea dicha carpeta?
Ejercicio 3
Opciones de inicio en /etc/fstab
1. Edita el archivo /etc/fstab y establece las siguientes opciones para el
arranque: (cambia el valor de la IP por el que aplique en tu caso remoto)
El directorio remoto 192.168.0.250:/mnt/hda5/Compartido_NFS se montará
automáticamente en /mnt/nfs.
2. El directorio remoto 192.168.0.250:/home/usuario/Pruebas podrá ser
montado por cualquier usuario, en modo rw en el directorio (que habrá que
Página 24 de 58
crear) /home/usuario/Prueba_remota.
Ejercicio 4
Accediendo con permiso de root (muy peligroso)
Vamos a compartir el directorio /home de forma que el usuario root (uid=0)
remoto tenga sobre él permisos de administrador. Esto es muy peligro pues si
alguien conecta a la red local otra máquina en la que es capaz de iniciar sesión
como root, podría acceder a nuestro /home con tota libertad. Para ello:
1. Edita el archivo /etc/exports y escribe la siguiente línea
/home *(rw,no_root_squash,sync)
2. Reinicia el servicio NFS (/etc/init.d/nfs-kernel-server restart)
Crea en una máquina remota (o en el propio equipo) el directorio
/mnt/prueba_home
3. Monta en /mnt/prueba_home el directorio /home compartido mediante NFS:
mount -t nfs 192.168.0.74:/home /mnt/prueba_home
4. Accede, como root a /mnt/prueba_home y prueba a crear directorios,
renombrar archivos, etc, procurando no hacer demasiado daño.
Página 25 de 58
Servicio DHCP
Dinamic Host Configuration Protocol
(Configuración dinámica de clientes IP)
Página 26 de 58
El servicio DHCP Las siglas DHCP significan Dinamic Host Configuration Protocol. Es utilizado
para grandes redes. El daemon actúa dándole información de la red a las
estaciones de trabajo, tales como IP Address, Subnet Mask, DNS Server,
Gateway, entre otros.
DHCP se trata de un protocolo del tipo cliente/servidor en el que generalmente
un servidor posee una lista de direcciones IP dinámicas y las va asignando a los
clientes a medida que estas van estando disponibles, sabiendo en todo momento
quien ha estado en posesión de las IP asignadas, cuanto tiempo la ha tenido, y a
quien se le asignó después.
DHCP ha sido creado por el Grupo de Trabajo Dynamic Host Configuration del
IETF (Internet Engineering Task Force, organización de voluntarios que define
protocolos para su uso en Internet) en octubre de 1993. Su definición se
encuentra en los RFC's 2131(el protocolo DHCP) y el 2132(opciones de DHCP)
El protocolo de Configuración Dinámica de Hosts (DHCP) permite la transmisión
de la configuración de los hosts sobre una red TCP/IP. Este protocolo se encarga
de la configuración automática de los parámetros de red, utilizando direcciones.
Es común en la redes por su fácil configuración y mantenimiento.
DHCP es una extensión de BOOTP, es decir, mejora BOOTP, y es compatible con
él (un cliente puede realizar una petición estática BOOTP a un servidor DHCP)
DHCP es un protocolo que permite asignar direcciones IP dinámicas, de forma
totalmente automática. Por ello no pierde las prestaciones de BOOTP, su
predecesor, sino que las extiende permitiendo de esta manera nuevas formas de
asignación de direcciones y nuevas opciones para poder pasar a los clientes toda
la información necesaria.
DHCP es un protocolo implementado en los principales sistemas operativos así
Página 27 de 58
como otros dispositivos, como por ejemplos Router WIFI.
DHCP puede usarse cuando el número de IPs es menor que el número de
computadores y todos no están conectados a la vez, como en un proveedor de
servicio de Internet (ISP).
DHCP está formado por dos partes: un protocolo para el intercambio de los
parámetros de red específicos de cada host y un mecanismo para la asignación
de direcciones de red.
Un servidor DHCP tiene dos bases de datos. La primera es estática, al igual que
BOOTP y la segunda contiene una pila de direcciones IP disponibles. Esta
segunda base de datos hace a DHCP dinámico. Cuando un cliente DHCP pide
una dirección IP temporal, DHCP la coge de la pila de direcciones IP disponibles
y se la asigna durante un periodo de tiempo negociado.
Tipos de configuraciones y asignaciones con DHCP El servidor admite tres tipos de configuración de direcciones IP:
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).
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.
Dinámica arrendada. Las direcciones se otorgan por un tiempo ilimitado. Un
cliente debe renovar su dirección para poder seguir utilizándola.
Cuando el servidor DHCP 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
Página 28 de 58
una IP disponible de la base de datos dinámica y añade la nueva asociación a la
base de datos.
Alquiler:La dirección asignada desde la pila es temporal. El servidor DHCP
emite un alquiler por un periodo determinado de tiempo. Cuando el alquiler
termina, el cliente debe, dejar de usar la IP o renovar el alquiler. El servidor
tiene la opción de aceptar o denegar la renovación.
El protocolo DHCP incluye tres métodos de asignación de direcciones IP:
Asignación manual o estática: asigna una dirección IP a una máquina
determinada. Se suele utilizar cuando se quiere controlar la asignación de
dirección IP a cada cliente, y evitar, también, que se conecten clientes no
identificados.
Asignación automática: Asigna una dirección IP de forma permanente a una
máquina cliente la primera vez que hace la solicitud al servidor DHCP y hasta
que el cliente la libera. Se suele utilizar cuando el número de clientes no varía
demasiado.
Asignación dinámica: el único método que permite la reutilización dinámica de
las direcciones IP. El administrador de la red determina un rango de direcciones
IP y cada computadora conectada a la red está configurada para solicitar su
dirección IP al servidor cuando la tarjeta de interfaz de red se inicializa. El
procedimiento usa un concepto muy simple en un intervalo de tiempo
controlable. Esto facilita la instalación de nuevas máquinas clientes a la red.
Operación: Pasos realizados por el cliente DHCP: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 que por defecto es de
Página 29 de 58
una hora. Si los clientes no reciben dicho mensaje, intenta establecer conexión
cuatro veces más, cada dos segundos, si aún así no hay respuesta, el cliente
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.
● Antes de 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.
¿Qué ventajas da el DHCP?
El instalar un sistema DHCP en su red, le ahorra un trabajo de configuración
para su red. Todas las computadoras piden información de la red y se configuran
automáticamente, muy recomendable para un administración fácil.
Página 30 de 58
Opciones más importantes que un servidor DHCP puede asignar/proveer a cualquier cliente que lo solicite. 1. Dirección del servidor de DNS.
2. Nombre de DNS.
3. Puerta de enlace de la dirección IP.
4. Dirección IP.
5. Máscara de subred.
6. Tiempo máximo de espera de ARP (Addres Resolution Protocol).
7. MTU (Maximun Transfer Unit) para cada máquina.
8. Servidores NIS.
9.Dominios NIS.
10. Servidores NTP (Network Time Protocol).
11. Servidores POP3 (Post Office Protocol)
12. Servidor SMTP (Simple Mail Transport Agent).
13. Servidor TFTP (Trivial File Transfer Protocol).
14. Nombre del servidor WINS (Windows Internet Naming Service).
Datos importantes al configurar servidor DHCP
1.- Se puede asignar una dirección IP concreta (siempre que pertenezca al rango
disponible) a una dirección MAC de la red. Para ello sólo hay que crear un
elemento en la lista de asignaciones estáticas que contenga la dirección MAC de
Página 31 de 58
la máquina conocida y la IP que se le desea asignar.
2.- Una lista de direcciones IP disponibles para los equipos que autorice para
actuar como servidores DHCP en la red (solo cuando no se le asigne
estáticamente)
3.- La detección de servidores DHCP no autorizados y protección para que éstos
no se inicien ni ejecuten en la red.
4.- Cache DNS, es opcional, la mayoría de los router traen 2 opciones, el
administrador será el que decidirá si activa esta opción o no.
5. La dirección IP de los servidores DHCP debe ser estática (Obligatorio).
Cuando los servidores DHCP están configurados correctamente y se autoriza su
uso en una red, proporcionan un servicio administrativo útil para el que han sido
diseñados. Sin embargo, si se introduce en la red un servidor DHCP
incorrectamente configurado o no autorizado, puede causar problemas. Por
ejemplo, si se inicia un servidor DHCP no autorizado, podría comenzar a
conceder direcciones IP incorrectas a los clientes o reconocer negativamente a
los clientes DHCP que intentan renovar sus concesiones de direcciones actuales.
Cualquiera de estas configuraciones puede producir problemas adicionales a los
clientes habilitados para DHCP. Por ejemplo, es posible que los clientes que
obtienen una concesión de configuración del servidor no autorizado no
encuentren controladores de dominio válidos y no puedan iniciar sesión
correctamente en la red.
Configuración General del DHCP en GNU/Linux (cualquier distro)
Como podemos observar en el archivo /etc/dhcp3/dhcpd.conf, cada orden o
parámetro termina con un punto y coma (;), a excepción de las opciones que
necesitan de varios parámetros, que se agrupan entre llaves ({...}). Repasemos a
Página 32 de 58
continuación las opciones y parámetros más importantes a nuestra disposición
(para un detalle completo de todos los comandos accederemos al manual de
configuración dhcp.conf y dhcp-options):
authoritative - La configuración correcta para la red es la definida en el
servidor DHCP. Poner este parámetro al comienzo del archivo de configuración
supone que el servidor DHCP reasignará direcciones a los clientes mal
configurados por el motivo que sea, incluida una configuración nueva del
servidor.
not authoritative - La función de este parámetro es justo la contraria del
anterior. Es decir: la configuración del servidor de DHCP no es concluyente y los
clientes mal configurados que sean detectados por el servidor, seguirán con su
configuración intacta.
ignore|allow client-updates - Permite la actualización de las asignaciones
(allow) de un cliente a requerimiento de este, o bien las asignaciones se
actualizan cuando el servidor así lo requiera (ignore).
ddns-hostname <nombre> - Por defecto, el servidor DHCP utiliza como
nombre para la solicitud el nombre que el cliente tiene asignado a su máquina.
Mediante este parámetro se asigna un nombre concreto a una máquina o a todas
en general. Por ejemplo, para asignar un nombre a una dirección MAC concreta,
utilizaremos el código siguiente:
host "canaima01" {hardware ethernet 00:60:30:3f:2d:4a;ddns-hostname "nombre_del_host";}
Y para asignar, por ejemplo, la dirección MAC como parte del nombre del cliente,
podemos usar lo siguiente:
ddns-hostname = binary-to-ascii (16,8, "-", substring (hardware, 1, 6));
Página 33 de 58
Que devolverá algo como 0-50-56-b-b-b.dhcp.nombre.com.
ddns-domainname <nombre> - Mediante el uso de este parámetro, se añadirá
<nombre> al final del nombre de la máquina cliente, para formar un nombre de
dominio totalmente cualificado (FQDN).
ddns-update-style <tipo> - Define el método de actualización automática de
las DNS. Los valores pueden ser ad-hoc, interim y none.
ddns-updates <on|off> - Activa la actualización DNS mediante los valores
asignados por DHCP.
default-lease-time <duración> - Especifica la cantidad de tiempo, en
segundos, que será mantenida una asignación de direcciones, siempre y cuando
el cliente no haya especificado algo concreto.
fixed-address <direcciones> - Esta opción aparece únicamente en una
declaración de host. Define las direcciones estática a asignar a un host
determinado.
group - Inicia la declaración de Grupo.
hardware <tipo dirección> - Especifica el hardware de un cliente BOOTP para
que éste sea reconocido por el servidor de DHCP. tipo puede ser ethernet o
token-ring y dirección será una serie de octetos hexadecimales inequívocos de la
tarjeta (por ejemplo, hardware ethernet 00:50:b3:c5:60:23).
max-lease-time <duración> - Especifica la cantidad máxima de tiempo, en
segundos, que será mantenida una asignación de direcciones. No está sujeta a
esta especificación la asignación dinámica BOOTP.
min-lease-time <duración> - Especifica la cantidad mínima de tiempo, en
segundos, que será mantenida una asignación de direcciones.
Página 34 de 58
one-lease-per-client <on|off> - Cuando la opción se iguala a on y un cliente
solicita una asignación de dirección (DHCPREQUEST), el servidor libera de
forma automática cualquier otra asignación asociada a dicho cliente. Con esto se
supone que si el cliente solicita una nueva asignación es porque ha olvidado que
tuviera alguna, luego tiene una sola interfaz de red. No dándose esta situación
entre los clientes no es muy aconsejable el uso de esta opción.
range ip-menor ip-mayor - En una declaración de subred, este parámetro
define el rango de direcciones que serán asignadas. Pueden darse dos
instrucciones range seguidas del modo:
range 192.168.0.11 192.168.0.100;
range 192.168.0.125 192.168.0.210;
server-identifier <IP> - Identifica la máquina donde se aloja el servidor de
DHCP. Su uso se aplica cuando la máquina en cuestión tiene varias direcciones
asignadas en un mismo interfaz de red.
server-name <nombre> - Nombre del servidor que será suministrado al cliente
que solicita la asignación.
shared-network - Declaración de Subred compartida.
subnet - Declaración de Subred.
option domain-name <nombre> - Nombre de dominio que usará el cliente en
una resolución de nombres vía DNS. Normalmente, será el nombre de dominio
que se añadirá al host que realiza la petición de asignación.
option domain-name-servers <IP, [IP ...]> - Define el nombre de los
servidores DNS.
option finger-server <IP, [IP ...]> - Define el nombre de los servidores Finger
disponibles para el cliente.
Página 35 de 58
option host-name <nombre> - Especifica el nombre del cliente. Puede ser un
nombre cualificado o no, aunque se recomienda que el nombre del dominio se
asigne mediante option domain-name. Sólo se asignará el nombre al cliente en el
caso de no tener éste asignado ninguno.
option irc-server <IP, [IP ...]> - Define el nombre de los servidores de IRC
disponibles para el cliente.
option lpr-servers <IP, [IP ...]> - Define una lista de servidores de impresión
LPR conforme al estándar RFC 1179. Se listan por orden de preferencia.
option nds-servers <IP, [IP ...]> - Define una lista de servidores NDS
disponibles para el cliente. Se usa en conjunción de option nds-context
<nombre>, que establece el nombre de inicio de la red Netware y option-nds-
tree-name <nombre>, que especifica el nombre del árbol a usar por el cliente
solicitante.
option netbios-name-servers <IP, [IP ...]> - Especifica un listado con los
servidores WINS disponibles para los clientes.
option nis-servers <IP, [IP ...]> - Define la lista de servidores NIS (Sun
Network Information Server) disponibles. Los servidores se listan en orden de
preferencia. Para establecer el nombre del dominio NIS, se usará option nis-
domain <nombre>.
option ntp-server <IP, [IP ...]> - Define los servidores horarios de NTP
disponibles. Se listan en orden de preferencia.
option pop-server <IP, [IP ...]> - Define los servidores de POP3 disponibles,
listados en orden de preferencia.
option routers <IP, [IP ...]> - Se definen una serie de routers (en la práctica,
puertas de enlace), listadas en orden de preferencia, disponibles para el acceso
al exterior por parte del cliente.
Página 36 de 58
option smtp-server <IP, [IP ...]> - Define la lista de servidores SMTP
disponibles, listados en orden de preferencia.
option subnet-mask <IP> - Definición de la máscara de subred general.
Así, tal y como hemos visto en el archivo de configuración
/etc/dhcp3/dhcpd.conf, primero se escriben una serie de opciones generales
(authoritative, ignore client-updates, etc.), para seguidamente definir una red
compartida (shared-network) con todas sus opciones específicas. Dicha red
incluye tres definiciones: una subred (subnet) y dos hosts específicos (host). Se
puede advertir igualmente que las direcciones de estos dos hosts no tienen por
qué incluirse dentro del rango de la red general.
Declaración de SubredDebe incluir una declaración subnet para cada subred en su red. Si no es así, el
servidor DHCP no arrancará.
En este ejemplo, hay opciones globales para cada cliente DHCP en la subred y un
range declarado. A los clientes se les asignará una dirección IP dentro de las IP
declaradas en range.
subnet 192.168.1.0 netmask 255.255.255.0 {option routers 192.168.1.254;option subnet_mask 255.255.255.0;
option domain_name "example.com";option domain_name_servers 192.168.1.1;
option time_offset _18000;range 192.168.1.10 192.168.1.100;}
Declaración de shared-network, o red compartidaTodas las subredes que comparten la misma red física deben especificarse
Página 37 de 58
dentro de una declaración shared_network. Los parámetros dentro de
shared_network pero fuera del cerco de las declaraciones subnet se consideran
parámetros globales. El nombre de shared_network debe ser el título descriptivo
de la red, como, por ejemplo, mi_red_local. Dicho nombre puede ser igualmente
una dirección IP.
shared_network mi_red_local {option domain_name "test.telecomvcg.net";option domain_name_servers ns1.telecomvcg.net, ns2.telecomvcg.net;option routers 192.168.1.254;---Declaración de subredes específicas---subnet 192.168.1.0 netmask 255.255.255.0 {parameters for subnetrange 192.168.1.1 192.168.1.31;}subnet 192.168.1.32 netmask 255.255.255.0 {parameters for subnetrange 192.168.1.33 192.168.1.63;}}
Declaración de Grupo
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 192.168.1.254;option subnet_mask 255.255.255.0;
option domain_name "example.com";option domain_name_servers 192.168.1.1;
option time_offset _18000;
host apex {option host_name "apex.example.com";hardware ethernet 00:A0:78:8E:9E:AA;fixed_address 192.168.1.4;}
Página 38 de 58
host raleigh {option host_name "raleigh.example.com";
hardware ethernet 00:A1:DD:74:C3:F2;fixed_address 192.168.1.6;}}
Consideraciones de seguridad
El servidor de DHCP utiliza el puerto 67 y 68 a través de UDP para recibir y
enviar datos a los clientes. Es por esto que lo primero que deberemos retocar
serán las reglas de nuestro cortafuegos, si es que este existe y si es que el
servidor de DHCP comparte con él la misma máquina. Suponiendo que tenemos
instalado iptables, la regla a introducir en el fichero de configuración será la
siguiente:
#iptables -A INPUT -i eth0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT
Con esta regla se permite el tráfico hacia y desde los puertos UDP 67 y 68, lo
cual nos deja abierto un pequeño agujero en el cortafuegos que permite el
funcionamiento del servidor de DHCP.
En el caso de tener varios dispositivos de red configurados en la misma máquina,
habrá que asegurarse de que nuestro servidor de DHCP sólo se ejecuta sobre el
que tiene acceso a la red a la que va a proveer de servicio.
eth0 se cambiará por el interfaz usado por DHCP.
Instalación y configuración del servidor DHCP en Debian etch / canaima v1.1
1. #apt-get install dhcpd
Página 39 de 58
2. Luego hay que configurar el /etc/dhcpd.conf.
Antes de hacer los cambios, haga un respaldo del archivo dhcpd.conf.
3. Editar el archivo: #nano /etc/dhcpd.conf y agregar las siguientes líneas:
option domain-name "cantv.net"; option domain-name-servers 200.44.32.12, 200.11.248.12; option routers 192.168.1.10; default-lease-time 3600; max-lease-time 7200; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.254; option broadcast-address 192.168.1.255; }
#las siguientes líneas son ejemplo para configurar ip estáticas para alguna máquina #en particular que quisieramos
#host hostname { #hardware ethernet 00:B0:CF:8B:49:37; #fixed-address 192.168.1.80; #}
3. Chequear el archivo: /etc/default/dhcp3-server Verificar que a interfaz de red corresponde a la que asignamos como DHCP: INTERFACES="eth0"
4. Reiniciar el servicio: /etc/init.d/dhcp3-server restart Si existen errores, entonces chequeamos el log:
tail -20 /var/log/messages
5. En las estaciones clientes, configurarlos con el comando: dhclient
Página 40 de 58
6.Discutir otros procedimientos de configuración alternos para el cliente. 6. Modificando el archivo /etc/network/interfaces7. Utilizando la interfaz gráfica de GNOME:
7.1Sistema -->Administración -->Red
Practicas con el servicio DHCP.
■ Configuración de un servidor DHCP en una sola red ó sub-red.
1. Rangos de IP
2. IP fijas
■ Práctica avanzada. (Basado en un caso del examen de certificación LPI, Linux Professional Institute) Nivel: Profesional Avanzado de Linux o LPIC-2 y con modificaciones y adaptaciones de Tecno-Redes Sistemas VCG.
Considere una firma que tiene cuatro departamentos: Ventas,
Administración, Ingeniería y Gerencia. Todos los departamentos están ubicados
en el mismo edificio y cada departamento tiene tres pisos.
En cada piso, hay hasta 200 estaciones y una impresora láser (LPRT - xx).
Además cada departamento tiene su propia impresora láser de color (CLPRT - xx)
ubicada en el piso central de los 3 que le corresponde. Las impresoras pueden
ser usadas por usuarios del departamento a los que las impresoras pertenecen
solamente.
Todos los usuarios obtienen una IP del servidor corporativo DHCP. Existe un
servidor de correo entrante POP3 y uno saliente SMTP.
Una representación gráfica de la red de la compañía es mostrada abajo:
Página 41 de 58
La arquitectura de la red
La empresa utiliza la dirección privada 172.17.0.0. Cada departamento tiene su
propia red (determinado por una máscara de 24 bits). Las subredes son las
siguientes:
Tabla 01. IP departamentos. Los primeros dos octetos son 172.17
Departamento. Piso Alcance de IP Enrutador Descripción
0001 0001 172.17.17.0 - 172.17.17.255 Ventas piso1
0001 0010 172.17.18.0 - 172.17.18.255 172.17.17.1 Ventas Piso 2
0001 0011 172.17.19.0 - 172.17.19.255 Ventas Piso 3
0010 0100 172.17.36.0 - 172.17.36.255 # 4 Administración
0010 0101 172.17.37.0 - 172.17.37.255 172.17.36.1 # 5 Administración
0010 0110 172.17.37.0 - 172.17.37.255 # 6 Administración
0011 0111 172.17.55.0 - 172.17.55.255 Ingeniería # 7
Página 42 de 58
Departamento. Piso Alcance de IP Enrutador Descripción
0011 1000 172.17.56.0 - 172.17.56.255 172.17.55.1 Ingeniería # 8
0011 1001 172.17.57.0 - 172.17.57.255 Ingeniería # 9
0100 1010 172.17.74.0 - 172.17.74.255 Gerencia # 10
0100 1011 172.17.75.0 - 172.17.75.255 172.17.74.1 Gerencia# 11
0100 1100 172.17.76.0 - 172.17.76.255 Gerencia# 12
Servicios (subred independiente)
La tabla abajo indica esos servicios y sus IP fijas.
Tabla02. Servicios compañía
Servicio Descripción IP address Nombre del anfitrión
DHCP El DHCP - servidor de la compañía 172.17.0.1 Dhcp.telecomvcg.net
DNS El DNS de la compañía 172.17.0.2 Dns.telecomvcg.net
SMTP El SMTP - servidor de la compañía
172.17.0.3 Smtp.telecomvcg.net
POP3 El POP3 - servidor de la compañía
172.17.0.4 Pop3.telecomvcg.net
Noticias El NNTP - servidor de la compañía
172.17.0.5 News.telecomvcg.net
NTP El NTP - servidor de la compañía
172.17.0.6 Ntp.telecomvcg.net
Servicios dependientes de la subred
Los servicios subred -dependientes son los servicios que son solamente
disponible para las estaciones en la misma subred como el servicio. La tabla
abajo indica esos servicios y sus direcciones IP fijas.
Página 43 de 58
Tabla 03. Servicios subred -dependiente
Departamento Servicio Descripción IP address Name
Enrutador Router piso # 2 ventas 172.17.17.1 Rtr – 02.telecomvcg.net
Impresora Impresora láser piso 1 172.17.17.2 Lprt - 01.telecomvcg.net
Ventas Impresora Impresora láser piso 2 172.17.18.2 Lprt - 02.telecomvcg.net
Impresora Impresora láser piso 3 172.17.19.2 Lprt - 03.telecomvcg.net
Impresora Impresora láser color piso 2 172.17.18.3 Clprt - 02.telecomvcg.net
Enrutador Router piso # 5 administración
172.17.36.1 Rtr - 05.telecomvcg.net
Impresora Impresora láser # 4 de piso 172.17.36.2 Lprt - 04.telecomvcg.net
Administración
Impresora Impresora láser piso 5 172.17.37.2 Lprt - 05.telecomvcg.net
Impresora Impresora láser piso 6 172.17.38.2 Lprt - 06.telecomvcg.net
Impresora Impresora láser color piso 5 172.17.37.3 Clprt - 05.telecomvcg.net
Enrutador Router piso 8 ingeniería 172.17.55.1 Rtr - 08.telecomvcg.net
Impresora Impresora láser piso 7 172.17.55.2 Lprt - 07.telecomvcg.net
Ingeniería Impresora Impresora láser piso 8 172.17.56.2 Lprt - 08.telecomvcg.net
Impresora Impresora láser piso 9 172.17.57.2 Lprt - 09.telecomvcg.net
Impresora Impresora láser color piso 8 172.17.56.3 Clprt - 08.telecomvcg.net
Enrutador Router piso 11 Gerencia 172.17.74.1 Rtr - 11.telecomvcg.net
Impresora Impresora láser piso 10 172.17.74.2 Lprt - 10.telecomvcg.net
Página 44 de 58
Departamento Servicio Descripción IP address Name
Gerencia Impresora Impresora láser piso 11 172.17.75.2 Lprt - 11.telecomvcg.net
Impresora Impresora láser piso 12 172.17.76.2 Lprt - 12.telecomvcg.net
ImpresoraImpresora láser color
piso 11172.17.75.
3Clprt -
11.telecomvcg.net
Se pide:
1. Hacer un esquema de red donde se muestren los switches, servidor
DHCP corporativo, servidores Router-DHCP-relay, Firewall, servidor
DNS, impresoras y estaciones.
2. Desarrollar el archivo de configuración del servidor DHCP
corporativo.
3. Discutir interrelación DHCP corporativo con DHCP-Relay
(departamentales)
Página 45 de 58
Servicio de impresión con el sistema CUPS Common UNIX Printing System.
Página 46 de 58
El sistema C UPS (Common UNIX Printing System), actualmente es el sistema
estándar de impresión en Linux.
En el entorno gráfico, las aplicaciones que pueden imprimir son compatibles
tanto con lpr/lpd como con CUPS. Algunas aplicaciones (GNOME, KDE, Xfce y
OpenOffice) traen Administradores de impresión compatibles con los diferentes
sistemas de impresión que nos permiten gestionar las impresoras y los trabajos
de impresión, como KJobViewer (paquete kdeprint).
Muchas aplicaciones (OpenOffice, KDE...) incorporan dispositivos virtuales
que permiten imprimir un documento como PDF, generar emails o faxes.
Página 47 de 58
¿En qué consiste el sistema de impresión CUPS?
El sistema de impresión CUPS reemplaza al sistema de impresión lpr/lpd y
consiste en lo siguiente:
a. El demonio de impresión cupsd (print spooler daemon) vigila los
directorios spool buscando trabajos a imprimir. Cuando aparece alguno,
cupsd lanza una copia de sí mismo que imprimirá el archivo en la
impresora apropiada.
b. La cola de impresión (spool), ubicada en el directorio /var/spool/cups, es
donde se almacenan los trabajos a imprimir. Los nuevos trabajos a imprimir
se colocan en la cola de impresión a la espera, el primero que entra es el
primero que sale.
c. Los comandos lpr/lpd para manejar la cola de impresión: el sistema
lpr/lpd es uno de los estándares de UNIX, y las aplicaciones asumen que
tendrán los comandos de este sistema de impresión disponibles. Por este
motivo CUPS proporciona su propia versión de esos comandos, que son:
• lpr (o lp): enviar trabajos a la cola de impresión. Este comando copia
el archivo a imprimir en el directorio de spool, donde permanece
hasta que el demonio cupsd lo imprime. Su sintaxis es:
$ lpr <archivo>
• lpq: consultar los trabajos pendientes en la cola de impresión.
• lpc: configurar las impresoras.
• lprm: eliminar trabajos de la cola de impresión.
d. Los drivers PPD de las impresoras PostScript: en Linux, cuando una
aplicación envía un documento a la impresora genera un archivo
PostScript.
Si la impresora entiende el lenguaje PostScript puede imprimir el
documento directamente. Sólo tenemos que decirle a CUPS cuáles son las
características de la impresora, y eso lo hace el archivo PPD (Postscript
Página 48 de 58
Printer Description): contiene todas las características de la impresora,
como tamaños de papel, colores, resoluciones disponibles, entre otras.
Si la impresora no entiende PostScript debemos traducir los documentos
que generan las aplicaciones (PostScript) a un lenguaje que entienda la
impresora, por lo que necesitamos un filtro. De esto se encarga Foomatic
(paquete foomatic-db-engine) que proporciona el archivo PPD y los filtros
necesarios para traducir los documentos (trabaja sobre GhostScript).
En ambos casos, el archivo PPD de la impresora se puede descargar
desde LinuxPrinting (linuxprinting.org) o desde la web de CUPS
(cups.org) y se debe guardar en el directorio /usr/share/cups/model.
e. Los comandos CUPS para administrar las impresoras: lpinfo, lpadmin,
enable, disable, accept, reject, lpoptions y lpstat.
f. La interfaz web de CUPS: es la mejor opción para administrar CUPS.
Página 49 de 58
Instalar una impresora local con CUPS
Veamos cómo instalar una impresora local con CUPS utilizando su interfaz web:
• Conectamos la impresora.
• Conseguimos e instalamos el archivo PPD de nuestra impresora.
• Instalamos Foomatic si la impresora no es PostScript.
• Reiniciamos el demonio de CUPS:
# /etc/init.d/cupsys restart
• Accedemos al interfaz web de CUPS: http://localhost:631
• Entramos en Administración.
Página 50 de 58
• pulsamos Añadir impresora e introducimos Nombre de la impresora:por ejemplo, HPlaserjet1150,
• Ubicación: Laboratorio C: por ejemplo, Impresoras Laser HP.
Página 51 de 58
• En la siguiente pantalla nos preguntará Tipo de conexión: HP ML-2010 USB # 1.
• Seleccionamos el modelo.
• Nos pedirá Usuario y Contraseña, ya que para administrar impresoras hay
que tener permisos de root (la contraseña se envía en texto plano, sin
encriptar).
Página 52 de 58
y ya tenemos la impresora instalada. Pulsando en Impresoras iremos a la página
de la nueva impresora. Desde aquí podemos monitorizar los trabajos de
impresión, cambiar las opciones de configuración y seleccionarla como
impresora predeterminada.
Página 53 de 58
Para terminar, comprobamos que realmente funciona lanzando una página de
prueba con Imprimir página de prueba.
Compartir nuestra impresora
Tenemos dos posibilidades para compartir nuestra impresora:
1. CUPS escuchando conexiones de máquinas remotas
Los equipos que dispongan de un cliente IPP (Linux, Unix, Mac y Windows
XP) podrán conectar con el demonio de impresión cupsd de nuestra
máquina mediante el protocolo IPP (Internet Printing Protocol, puerto 631
TCP), e imprimir en nuestra impresora, una vez que les permitamos
acceder. Para ello, en el archivo de configuración de CUPS,
/etc/cups/cupsd.conf especificaremos qué máquinas tienen acceso a CUPS.
Buscaremos las líneas:
<Location />
Order Deny,Allow
Deny All
Allow 127.0.0.1
</Location>
Vemos que por defecto sólo puede acceder a CUPS la propia máquina
(127.0.0.1). Para que puedan acceder las máquinas de la LAN agregamos la
línea:
Allow 192.168.0.0/255.255.255.0
Para terminar reiniciamos el demonio de CUPS:
# /etc/init.d/cupsys restart
Una vez compartida la impresora, es muy sencillo imprimir desde Linux:
• Interfaz web de CUPS --> http://localhost:631
Página 54 de 58
• Administración --> Añadir impresora
• Introducimos Nombre de la impresora, Ubicación y Descripción
• Tipo de conexión -->Internet Printing Protocol (IPP).
• URL de la conexión --> ipp://192.168.0.2/printers/Canon.
• Modelo, Usuario y Contraseña y la impresora ya está instalada.
También es muy sencillo imprimir desde Windows XP:
• Asistente para agregar impresoras
• Impresora de red o una impresora conectada a otra computadora
• Conectarse a una impresora en Internet o en su red doméstica u
organización
• URL de la conexión, http://192.168.0.2:631/printers/hp.
Página 55 de 58
• Instalamos los drivers de la impresora desde el CD del fabricante y
listo.
2. Que el servidor Samba atienda peticiones remotas y las pase a CUPS
Los equipos que dispongan de un cliente SMB (Windows) podrán conectar
con el servidor Samba (paquete samba) de nuestra máquina mediante el
protocolo SMB (puerto 139 TCP), y éste se encargará de pasarle la petición
a CUPS.
Vamos a configurar el servidor Samba para compartir nuestra impresora.
Primero crearemos en nuestro sistema un usuario específico (smbprint)
para que acceda a la impresora mediante Samba. Si queremos permitir
acceso anónimo lo podemos crear sin contraseña:
# /usr/sbin/adduser --system --disabled-password smbprint
Para compartir nuestra impresora CUPS y que sólo el usuario smbprint
tenga acceso a ella, como invitado (por lo que todas las máquinas de la red
local y con conexión directa desde Internet podrán imprimir), editaremos el
archivo /etc/samba/smb.conf colocando:
[printers]
browseable = yes
Página 56 de 58
printable = yes
public = yes
guest only = yes
guest account = smbprint
path = /home/smbprint
Además tenemos que decirle a Samba que el sistema de impresión es CUPS,
no lpr/lpd, por lo que cambiaremos /etc/samba/smb.conf para que quede:
[global]
printcap name = cups
printing = cups
Grabamos los cambios y reiniciamos Samba:
# /etc/init.d/samba restart
Una vez compartida la impresora, es muy sencillo imprimir desde
Windows:
• localizamos nuestra máquina en el Explorador de archivos. Veremos
que tiene una impresora compartida.
• pulsamos Conectar e instalamos los drivers desde el CD del
fabricante.
Imprimir desde Linux en una impresora Windows
Para conectar desde Linux con un equipo remoto Windows que tiene una
impresora compartida usaremos el cliente Samba (paquete smbclient),
mediante el protocolo SMB, puerto 139 TCP. CUPS utiliza como back-end el
programa smbspool de Samba.
Página 57 de 58
Primero nos aseguraremos de que podemos acceder a la máquina Windows:
# smbclient -L 192.168.0.2 -U usuario
Una vez comprobado que la impresora remota es accesible, es muy sencillo
imprimir:
• Interfaz web de CUPS --> http://localhost:631
• Administración --> Añadir impresora
• Introducimos Nombre de la impresora, Ubicación y Descripción
• Tipo de conexión --> Windows Printer vía Samba.
• URL de la conexión --> smb://usuario:[email protected]/Canon (si el
usuario con permiso para imprimir en el servidor Samba se llama igual que
el usuario que lanza la impresión, no es necesario especificarlo).
• Modelo, Usuario y Contraseña para terminar .
Página 58 de 58