LAN (Local Area Network)

Redes. Archivos de configuración. Clientes. Sistemas de Archivos en red. Código NFS (Network File System). Sincronización. Administración de sistema. Instalación. Directorios

  • Enviado por: El remitente no desea revelar su nombre
  • Idioma: castellano
  • País: España España
  • 22 páginas
publicidad
publicidad

C O N T E N I D O S :

  • Introducción

Características del NFS

Descripción de los archivos de configuración.

  • Método

Configuración de un servidor NFS.

Configuración de los clientes

  • Resultados

  • Conclusiones

  • Recomendaciones

  • Referencias

  • Bibliografía

  • Glosario

  • Índice

I N T R O D U C C I Ó N

El Sistema de Archivos en Red ó Network File System(NFS) fue desarrollado para permitir a ordenadores compartir recursos remotamente como si fuera localmente.

Se desarrolló con el fin de permitir montar particiones remotamente entre máquinas situadas en una misma red. Puede entenderse como algo parecido a lo que es un servidor de ficheros en MsWindows. Para compartir particiones con otras máquinas dentro de una red, el servidor simplemente “comparte” un directorio, y el cliente lo “monta” de un modo similar a como sucede al montar un CDrom o una partición de un disco duro.

Pero esto es peligroso, por que gente no deseada tiene acceso al disco duro del servidor de la red y manipular indebidamente los archivos. Para evitar esto, se ha de tomar ciertas precauciones, por ejemplo, restringir el rango de Ips autorizadas al acceso.

Algunas de las características que el NFS posee son:

  • Permite compartir archivos en una red. De este modo, numerosos clientes pueden acceder a un nodo central encargado de almacenar y mantener los archivos. Dichos clientes montan como un directorio propio los directorios del nodo central (servidor) en el momento de iniciar.

  • Se puede tener un nodo encargado de mantener una copia de una determinada aplicación, de modo tal que no toque almacenarlo en cada una de las máquinas.


- Mantener versiones actualizadas de los archivos al tener una sola copia en un directorio compartido del servidor y no diferentes copias distribuidas en cada cliente que lo utiliza.


- Es muy importante tener en cuenta que este servicio es un hueco de seguridad que puede ser utilizado por los crackers para introducirse en el sistema y causar daños.

  • Los datos accedidos por todo tipo de usuarios pueden mantenerse en un nodo central, con clientes que montan los directorios en el momento de iniciar. Por ejemplo, puede mantener todas las cuentas de usuario en una máquina, y hacer que las demás monten dichas cuentas en su directorio /home por NFS.

-Los datos que consumen grandes cantidades de espacio de disco pueden mantenerse en un nodo. Por ejemplo, mantener una sola copia de un archivo de gran tamaño en lugar de copiarlo en cada nodo.

-Los datos de administración pueden también mantenerse en un solo nodo. Ya no será necesario usar rcp para instalar el mismo fichero en 20 máquinas distintas.

El mayor problema con el código NFS de es que el núcleo 1.0 no puede manejar bloques de memoria de más de 4Kb, por lo que el código de red no puede manejar datagramas de un tamaño mayor que 3500 octetos una vez eliminadas las cabeceras. Esto significa que las transferencias con servidores NFS que utilicen datagramas grandes por defecto (por ejemplo, los 8Kb de SunOS) necesitan ser reducidas artificialmente. Esto produce pérdidas de rendimiento en ciertas circunstancias. Esta limitación desapareció en los núcleos posteriores al 1.1, reescribiéndose el código del cliente para aprovechar la nueva situación.

M É T O D O

Descripción de los Archivos de Configuración

Hay cinco archivos de configuración principales los que tendrá que corregir para establecer un servidor NFS: /etc/exports,/etc/hosts.allow, y/etc/hosts.deny. Estrictamente sólo tiene que corregir /etc/exports para conseguir trabajar con NFS, pero sería un sistema sumamente inseguro.

/etc/exports

Este archivo contiene una lista de entradas; cada entrada indica un volumen que es compartido y como esto es compartido. Compruebe las páginas de hombre (exportaciones de hombre) para una descripción completa de todas las opciones de sistema para el archivo, aunque la descripción aquí vaya a probablemente a satisfacer las necesidades de la mayoría de la gente.

Una entrada en/etc/exports típicamente se parecerá a esto:

Directorio maquina1 (opción11, opción 12) máquina2 (opción 21,opción 22)

Directorio

El directorio que quiere compartir. Esto puede ser un volumen entero aunque no tenga que ser. Si comparte un directorio, entonces todos los directorios bajo ello dentro del mismo sistema de fichas serán compartidos también.

Máquina1 y máquina2

Las máquinas de cliente que tendrán el acceso al directorio. Las máquinas pueden ser puestas en una lista por su dirección de DNS o su dirección de IP (por ejemplo, “nombre de la máquina” o 192.168.1.2). La utilización IP direcciones es más confiable y más segura.

Opción**

El listado de opción para cada máquina describirá lo que el acceso que la máquina tendrá. Opciones importantes son:

  • Ro: el directorio compartido sólo puede ser leído; la máquina de cliente no podrá modificarlo.

  • Rw: la máquina de cliente podrá leer y escribir el acceso al directorio.

  • Root­_squash: Se trata de una opción de seguridad que deniega acceso a ficheros del superusuario a las peticiones con uid 0 o 65534.

  • No_root_squash: Evita la restricción anterior. Es una opción por defecto

  • Map_identity: Indica al servidor que asuma que el cliente utilice el mismo mapa de uids y gids que el servidor. Es una opción por defecto.

  • No_subtree_check: Si sólo la parte de un volumen es exportada, una rutina la comprobación de no_subtree_check de un archivo que es solicitado por cliente está en la parte propia del volumen. Si el volumen entero es exportado, inhabilitando esta comprobación acelerará transferencias.

  • Sincronización: Consiste en decirle a una máquina cliente que un archivo escrito está finalizado, entonces NFS termina de escribir al sistema de archivos. Este comportamiento puede causar la corrupción de datos si el servidor reanuda, y la opción de sincronización previene esto.

  • Insecure Permitir acceso no autentificado desde ese nodo.

  • nohide Si la máquina cliente tiene un sistema montado en un directorio, y exporta este directorio, el cliente que lo monte deberá montar también el directorio `hijo' que el servidor tiene montado, para poderlo ver. Esto sucede porque el directorio montado previamente por el servidor esta `oculto'.

/etc/hosts.allow y /etc/hosts.deny

Estos dos archivos especifican el que los ordenadores sobre la red pueden usar servicios contra la máquina. Cada línea del archivo contiene una entrada sola poniendo en una lista un servicio y un juego de máquinas. Cuando el servidor consigue una petición de una máquina, esto hace lo siguiente:

  • Esto primero comprueba hosts.allow para ver si la máquina empareja una descripción puesta en una lista en allí. Si esto hace, entonces permiten a la máquina el acceso.

  • Si la máquina no empareja una entrada en hosts.allow, el servidor entonces comprueba hosts.deny para ver si el cliente empareja un listado en allí. Si esto hace entonces la máquina es privada de acceso.

  • Si el cliente no empareja ningunos listados en el uno o el otro archivo, entonces permiten a ello el acceso.

Los ficheros /etc/hosts.allow y /etc/hosts.deny controlan normalmente el acceso a la ejecución de los demonios lanzados desde inetd (internet superserver daemon) tales como FTP, TELNET, etc... aunque también pueden controlar el acceso a los demonios ofrecidos por el servidor de NFS.

El primer demonio para restringir el acceso a es el portmapper. Este demonio esencialmente solamente dice el solicitar a clientes como encontrar todos los servicios NFS en el sistema. La restricción del acceso al portmapper es la mejor defensa contra algún intento de introducirse en su sistema por NFS porque clientes completamente no autorizados no sabrán donde encontrar a los demonios NFS. Sin embargo, hay dos cosas de tener cuidado con. Primero, restringiendo portmapper no es bastante si el intruso ya sabe por cualquier razón como encontrar a aquellos demonios. Y el segundo, si controla NIS, restringiendo portmapper también restringirá peticiones a NIS. Esto por lo general debería ser inofensivo ya que por lo general quiere restringir NFS Y NIS de un modo similar.

En general esto es una buena idea con NFS (como con la mayor parte de servicios de Internet) para negar el acceso a direcciones IP a las que no quiere que permitir el acceso.

El primero intervienen haciendo esto debe agregar la entrada siguiente a/etc/hosts.deny:

Portmap:ALL

Usted puede ser un poco más precavido controlando el acceso a demonios individuales. Esto es una buena precaución ya que un intruso será capaz de colarse por un agujero del portmap. Agregue entradas para cada uno de los demonios NFS para tener controlados a estos demonios:

Lockd:ALL

mountd:ALL

rquotad:ALL

statd:ALL

Agregando estas entradas el NFS es menos vulnerable (ya que éstas serán muy útiles) y a lo mejor le ahorrará algún problema cuando actualice la versión.

Algunos administradores de sistema deciden poner la entrada ALL:ALL en el archivo/etc/hosts.deny, que se niega cualquier servicio que usa estos archivos para negar el acceso a todas las conexiones a no ser que explícitamente permitan a ello. Mientras que esto es el comportamiento más seguro, también puede tener problemas cuando instala nuevos servicios, por que se puede olvidar que lo había escrito, y no puede entender por que no funcionan.

Después tenemos que agregar una entrada a hosts.allow para dar cualquier acceso a conexiones que queramos que tengan acceso.

Si solo dejamos dichas líneas en hosts.deny entonces nadie tendrá el acceso a NFS.

Las entradas en hosts.allow siguen el formato:

Servicio: Ip del cliente y/o host [red/netmask]

Aquí, la conexión es la dirección de IP de un cliente; Esto puede estar disponible en algunas versiones para usar el nombre de DNS de la conexión.

Si tiene la intención de utilizar NFS sobre un número grande de máquinas en una red local, /etc/hosts.allow también tiene entradas de formato network/netmask en cuenta en la misma manera que en /etc/exports.

Y también se puede declarar permisos para los distintos demonios en /etc/hosts.allow.

Suponga que solo queremos permitir el acceso a cliente1.pacomolla.edu y cliente2.pacomolla.edu, y suponer esto las direcciones de IP de estas máquinas son 192.168.1.3 y 192.168.1.4, respectivamente. Nosotros podríamos agregar la entrada siguiente a/etc/hosts.allow:

Lockd: 192.168.1.3, 192.168.1.4

rquotad: 192.168.1.3, 192.168.1.4

mountd: 192.168.1.3, 192.168.1.4

statd: 192.168.1.3, 192.168.1.4

/etc/services

También se debe comprobar en este archivo que el protocolo NFS está activado (si no tiene una # al principio de la línea), normalmente está en el puerto 2049.

I N S T A L A C I Ó N

La instalación en las distintas distribuciones es muy variable, pero todas se basan en lo mismo. Nosotros nos vamos a centrar en la instalación para Mandrake 8.1.

Configurando el servidor NFS.

Se requiere tener instalados nfs-utils, nfs-utils-clients y portmap. Preguntaremos al sistema si estos están instalados con la siguiente línea de comando:

rpm -q nfs-utils portmap nfs-utils-clients

Lo cual debe salir algo similar como lo siguiente:

portmap-4.0-17mdk

nfs-utils-0.3.1-7mdk

nfs-utils-clients-0.3.1-7mdk

(Según versiones).

En caso de que falte alguno de estos paquetes, inserte el CD de instalación en la unidad correspondiente, abra una terminal o consola y ejecute lo siguiente:

mount /mnt/cdrom/

rpm -Uvh /mnt/cdrom/Mandrake/RPMS/paquete_faltante

Procederemos a determinar que directorio se va a compartir. Puede crear también uno nuevo:

mkdir /home/nfs/

Una vez hecho esto, necesitaremos establecer que directorios en el sistema serán compartidos con el resto de las máquinas de la red, o bien a que máquinas, de acuerdo al DNS o /etc/hosts se permitirá el accesos.

/etc/exports

Suponga tenemos dos máquinas de cliente, cliente1 y cliente2, que tienen IP y son 192.168.1.1 y 192.168.1.2, respectivamente. Deseamos compartir nuestro software y directorios locales con estas máquinas. Un sistema típico para/etc/exports podría parecerse a esto:

/home/nfs 192.168.1.1 (ro) 192.168.1.2 (ro)

Aquí compartimos /home/nfs sólo para leer a cliente1 y cliente2, porque esto probablemente contiene nuestro software y no pueden haber ventajas para el acceso de cliente1 y cliente2 para escribirlos. (LA SEPARACIÓN DE ESPACIOS ENTRE RUTAS E IPs SE HACE CON UN TABULADOR).

Se puede especificar una dirección IP o bien nombre de alguna máquina, o bien un patrón común con comodín para definir que máquinas pueden acceder. De tal modo podemos utilizar el siguiente ejemplo:

/home/nfs *.pacomolla.edu(ro)

En el ejemplo anterior se esta definiendo que se compartirá /home/nfs a todas las máquinas cuyo nombre, de acuerdo al DNS o /etc/hosts, tiene como patrón común pacomolla.edu, en modo de solo lectura. Se utiliza el asterisco (*) como comodín, seguido de un punto y el nombre del dominio. Esto permitirá que cliente1.pacomolla.edu, cliente2.pacomolla.edu, cliente3.pacomolla.edu, etc., podrán acceder al volumen /home/nfs/ en modo solo lectura. Si queremos que el accesos a este directorio sea en modo de lectura y escritura, cambiamos (ro) por (rw):

/home/nfs *.pacomolla.edu(rw)

Si tiene una instalación grande, se puede encontrar que tiene un grupo de ordenadores todos sobre la misma red local que requieren el acceso a su servidor. Hay unos modos de simplificar referencias a los números grandes de máquinas. Primero, puede dar el acceso a una gama de máquinas inmediatamente por especificando una red y un netmask. Por ejemplo, si quiso permitir el acceso a todas las máquinas con direcciones de IP entre 192.168.1.0 y 192.168.1.255 entonces podría tener las entradas:

/home/nfs 192.168.1.0/255.255.255.0 (ro)

Lo siguiente será configurar un nivel de seguridad para portmap. Esto se consigue editando los ficheros /etc/hosts.allow y /etc/hosts.deny. Debemos especificar que direcciones IP o rango de direcciones IP pueden acceder a los servicios de portmap y quienes no pueden hacerlo, como he explicado antes.

/etc/hosts.allow

Podemos entonces determinar en /etc/hosts.allow como rango de direcciones IP permitidas los siguiente:

portmap:192.168.1.0/255.255.255.0

Esto corresponde a la dirección IP de la red completa y la máscara de la sub-red. Adicionalmente podemos especificar direcciones IP individuales sin necesidad de establecer una máscara. Esto es de utilidad cuando se desea compartir volúmenes con otras máquinas en otras redes a través de Internet. Ejemplo:

portmap:192.168.20.25

portmap:192.168.30.2

portmap:216.200.152.96

portmap:148.240.28.171

etc/hosts.deny

Una vez determinado que direcciones IP pueden acceder a portmap, solo resta determinar quienes no pueden hacerlo. Evidentemente nos referimos al resto del mundo, y esto se hace agregando la siguiente línea:

portmap:ALL (ó ALL:ALL)

Es importante destacar que la línea anterior es INDISPENSABLE y NECESARIA si quiere tener un nivel de seguridad decente. De manera predeterminada las versiones más recientes de nfs-utils no permitirán iniciar el servicio si esta línea no se encuentra presente en /etc/hosts.deny.

Una vez configurado portmap, debe reiniciarse el servicio de portmap y el servicio de nfs:

/sbin/service portmap restart

/sbin/service nfs restart ---(se carga el demonio rpc.mountd)

Así como unos demonios adicionales:

En /sbin:

./rpc.statd y ./rpc.lockd

en /usr/sbin:

./exportfs y ./rpc.nfsd <-(también se carga con: service nfs restart).

Para comprobar que nuestro servidor de NFS esta funcionando correctamente, basta con hacer un listado de los procesos (ps -aux ó ps -e) y ver si realmente se han lanzado bien los demonios.

/etc/hosts

Si tiene un DNS, de alta las direcciones IP asociadas a un nombre o bien edite /etc/hosts y agregue las direcciones IP asociadas con un nombre. Esto nos servirá como listas de control de accesos. Ejemplo del fichero /etc/hosts:

127.0.0.1 localhost.localdomain localhost

192.168.1.2 servidor.pacomolla.edu servidor

192.168.1.3 cliente1. pacomolla.edu cliente1

192.168.1.4 cliente2. pacomolla.edu cliente2

192.168.1.5 cliente3. pacomolla.edu cliente3

192.168.1.6 cliente4. pacomolla.edu cliente4

......................... ......................................... ................

Configurando las máquinas clientes.

Para probar la configuración, es necesario que las máquinas clientes se encuentren definidas en el DNS o en el fichero /etc/hosts del servidor. Si no hay un DNS configurado en la red, deberán definirse los nombres y direcciones IP correspondientes en el fichero /etc/hosts de todas las máquinas que integran la red local. A continuación creamos, como root, desde cualquier otra máquina de la red local un punto de montaje:

mkdir /mnt/servidornfs

Para comenzar a usar una máquina como cliente de NFS solamente deberemos tener funcionando el portmapper, el statd y el lockd, por lo que podemos arrancarlos igual que hemos hecho antes en la parte del servidor:

/sbin/service portmap restart En caso de que no esté se procede a instalar como en el servidor.

También se debe instalar el nfs-utils-clients y nfs-utils para poder arrancar estos demonios:

/sbin/./rpc.lockd

/sbin/./rpc.statd

Para comprobar que los demonios lanzados están funcionando, basta con hacer un listado de los procesos (ps -aux ó ps -e).

Y para proceder a montar el volumen remoto, utilizaremos la siguiente línea de comando:

mount -t nfs servidor.pacomolla.edu:/home/nfs /mnt/servidornfs

Si por alguna razón en el DNS de la red local, o el fichero /etc/hosts de la máquina cliente, decidió no asociar el nombre de la máquina que fingirá como servidor NFS a su correspondiente dirección IP, puede especificar ésta en lugar del nombre. Ejemplo:

mount -t nfs 192.168.1.2:/home/nfs /mnt/servidornfs

Podremos acceder entonces a dicho volumen remoto con solo cambiar al directorio local definido como punto de montaje, del mismo modo que se haría con un disquete o una unidad de CDROM:

cd /mnt/servidornfs

R E S U L T A D O S

El NFS es una buena manera de trabajar en directorios y archivos remotos como si fueran locales

Con solo tener instalado en las máquinas implicadas el software necesario y conectadas mediante una red, es posible el intercambio de información del servidor al cliente del estado del sistema de archivos del primero, incluso dando los pertinentes permisos a los clientes es posible escribir, ejecutar programas en el servidor. Es indispensable tener corriendo los demonios correspondientes para cada aplicación.

C O N C L U S I O N E S

Bien, como ya se dijo al principio este servidor se llama Sistema de Archivos en Red o Network File System(NFS), su funcionamiento es similar a SAMBA pero solo es posible en máquinas que trabajen con unix/linux y no tiene un sistema de contraseñas para cada usuario como tiene SAMBA, por lo que el NFS es tachado de poco seguro y fácilmente crakeable. Estos son los motivos de que las empresas se decantan por SAMBA, además de tener compatibilidad con Microsoft Windows, dejando de lado a NFS. Éste solo se usa en redes en las que no es preciso un nivel alto de seguridad como por ejemplo mini-redes locales.

R E C O M E N D A C I O N E S

Los privilegios de montaje de NFS se conceden expresamente a un host, no un usuario. Si concede un acceso de host a una parte particular de su disco duro con NFS, los usuarios de aquella máquina tendrán el acceso a sus datos compartidos.

Configurando el archivo/etc/exports, hay que ser sumamente cuidadoso cuando compartimos directorios con (rw) a un cliente. Los usuarios de sistemas remotos que montan su exportación serán capaces de modificar datos en el sistema de archivos exportado.

Precauciones sobre directorios padres e hijos.

Primero, si un directorio es exportado, sus directorios padre e hijos no pueden ser exportados si ellos están en el mismo sistema de archivos. Sin embargo, exportando ambos no deberían ser necesarios porque el listado del directorio padre en el archivo/etc/exports causará todos los directorios subyacentes dentro de aquel sistema de archivos para ser exportado.

Si queremos poder montar este volumen NFS con una simple línea de comando

Por ejemplo: mount /mnt/servidornfs; O bien haciendo doble click en un icono sobre el escritorio, será necesario agregar la correspondiente línea en /etc/fstab.

Ejemplo:

servidor.pacomolla.edu: /home/nfs /mnt/servidornfs nfs user,exec,dev,nosuid,rw,noauto 0 0

<dispositivo> <punto de anclaje> <sistema de archivos> <opciones> <dump> <fsckorder>

Las opciones disponibles para el montaje automático son:

-Rw: Montar el sistema de archivos de lectura y escritura.

-Suid: Permitir el uso de identificadores de los bits SUID y SGID.

-Dev: Interpretar dispositivos especiales de caracteres o bloques en el sistema de archivos.

-Exec: Permite la ejecución de binarios.

-Auto: puede montarse con la opción -a.

-Nouser: prohibe a un usuario ordinario ( que no sea el root) montar el sistema de archivos.

-Async: toda la E/S al sistema de archivos deberá hacerse asíncronamente.

Todas estas opciones anteriores se agrupan todas en una, con solo poner “default”.

Otras opciones del mount son:

Ro: montar el sistema de archivos en modo de solo lectura.

Nosuid: Opuesto a suid.

Nodev Opuesto a dev.

Noexec: Opuesto al exec.

Sync: toda la E/S al sistema de archivos se producirá de inmediato y el programa que las produjo esperará a que terminen. Este modo de trabajo más lento que usando async.

El “dump” se utiliza para saber que sistemas de archivos necesitan ser volcados. Si el campo está a 0, se asume que el sistema de archivo s no necesita ser volcado. De esta manera el root puede estar informado de cuando se necesita hacer copias de seguridad.

El “fsckorder” es un chequeador del estado de la partición, para cuando el sistema arranque, el directorio raíz deberá llevar un 1 y otros sistemas de archivos el 2; Y si este campo es igual a 0 el sistema asumirá que no hace falta que sean chequeados por ejemplo: disquetes y CD-ROM.

O también podemos hacer que el servicio de nfs esté habilitado la siguiente vez que se encienda el equipo, debemos ejecutar lo siguiente:

/sbin/chkconfig --level 345 nfs on

El comando anterior hace que se habilite nfs en los niveles de corrida 3, 4 y 5.

O también se puede usar la orden : ntsysv (ver glosario).

R E F E R E N C I A S

http://www.loeda.net/linux/

http://bulmalug.net/

http://www.europe.redhat.com/documentation/

http://tldp.org/HOWTO/HOWTO-INDEX/howtos.html

http://www.mandrake.com/

http://mercury.chem.pitt.edu/~tiho/LinuxFocus/Castellano/November2000/article164.shtml

Manual de linux Esware2.0.

B I B I L I O G R A F Í A

http://linuxcol.uniandes.edu.co

http://assl.ath.cx/docs/nfs.html

G L O S A R I O

  • NFS

Acrónimo de “Network File System” o Sistema de Archivos en Red. Utilizado para compartir recursos remotos como si fueran locales

  • Demonio
    Se le denomina así a los programas que corren sin estar ligados a una terminal, o sea en background.

  • Dirección IP
    Es la dirección de cada una de las máquinas de una red.

  • Directorio
    Son carpetas virtuales para la acumulación de archivos en una estructura de un sistema operativo. Los directorios pueden ser recursivos es decir directorios dentro de directorios.

  • Portmap. Su misión es la de asociar un número de puerto a cada servicio RPC dado. Para establecer una transmisión RPC este proceso debe estar activo. Cuando un servidor RPC es iniciado, portmap dirá el número de puerto que se debe escuchar, y que número de programa RPC está preparado para servir. Cuando un cliente desea hacer una llamada de RPC a un número de programa dado, este primero se pondrá en contacto con portmap sobre la máquina de servidor para determinar el número de puerto donde paquetes RPC deberían ser enviados. Portmap debe ser iniciado antes de que cualquier servidor RPC sea invocado. Normalmente portmap se convoca y se disocia como cualquier otro demonio.

  • ntsysv : Es una herramienta gráfica que tiene la misma funcionalidad que chkconfig , la diferencia es que esta herramienta despliega un menú con los servicios que quieras que se ejecuten al arrancar el sistema.

  • /usr/sbin : Binarios para el funcionamiento del sistema, deberán estar aquí todos los programas que puedan ser usados por los usuarios, EXCEPTO aquellos programas que sean del root que deberán estar ubicados en /sbin.

  • rpm : Gestor de paquetes muy utilizado en linux por su facilidad en instalar, desinstalar y consultar.

Í N D I C E

Página

  • Introducción 2

  • Método 4

  • Resultados 16

  • Conclusiones 16

  • Recomendaciones 17

  • Referencias 19

  • Bibliografía 19

  • Glosario 20

  • Índice 22

21

4