Manual Nfs Cups Dhcp

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

mailto:root@powerman

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




Enrutador Router piso 8 ingeniería 172.17.55.1 Rtr - 08.telecomvcg.net


Ingeniería Impresora Impresora láser piso 8 172.17.56.2 Lprt - 08.telecomvcg.net



Enrutador Router piso 11 Gerencia 172.17.74.1 Rtr - 11.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


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

http://es.wikipedia.org/wiki/Common_Unix_Printing_System

http://es.wikipedia.org/wiki/Common_Unix_Printing_System

¿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

http://en.wikipedia.org/wiki/PostScript_Printer_Description

http://es.wikipedia.org/wiki/PostScript

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

http://www.cups.org/

http://www.linuxprinting.org/

http://en.wikipedia.org/wiki/Foomatic

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

http://es.wikipedia.org/wiki/Internet_Printing_Protocol

• 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

Documents

Manual Nfs Cups Dhcp