Capas del Servidor NFS

Está compuesto de tres capas para facilitar su uso genérico a través de múltiples plataformas. Estas capas son:

La capa RPC (llamada a procedimiento remoto)

Pasa la data entre los nodos, está diseñada para permitir el desarrollo de aplicaciones generales cliente/servidor.

Componentes de la estructura RPC

Uno o varios programas que se ejecutan en un servidor implementan un servicio de RPC, cada programa puede ejecutar varios procedimientos. Ya que existen diferentes procedimientos en NFS para leer, escribir, cambiar el nombre y borrar. Cada programa tiene un identificador numérico asignado. Y finalmente cada procedimiento de un programa tiene un identificador numérico asignado.

Acceso de una aplicación cliente a un proceso remoto

Una petición de un cliente RPC identifica al programa y al procedimiento a ejecutar. Si se desea leer un programa, la petición RPC solicitará el programa 100003 (NFS) y el procedimiento 6 (read). Cabe destacar que con el tiempo los programas cambian, los procedimientos se mejoran y se añaden otros nuevos por lo que la llamada RPC debe identificar también la versión del programa, ya que es usual encontrar varias versiones de un programa de RPC ejecutándose en un nodo servidor.

Sistema de transporte en RPC 

En TCP/IP el RPC se ejecuta tanto sobre TCP como sobre UDP, pero puede estar implementado sobre otros sistemas de transporte. Si se basa en TCP, las peticiones y las respuestas se entregan de forma fiable. En cambio si el servicio se basa en UDP, el cliente y el servidor deben proporcionar sus propias estrategias de temporización, retransmisión y detección de duplicados. Las peticiones de RPC también pueden ser de multienvio o de difusión.

Programas que implementan RPCNFS 

es el programa con RPC más conocido, sin embargo hay otros como rusers que averigua quien está conectado, bien a los nodos de una lista seleccionada, o a todos los nodos de la red local. Un rusers cliente difunde su llamada de RPC por la LAN. Las respuestas contienen el nombre del host y los usuarios conectados a ese nodo.

Gestor de puertos RPC 

utiliza un método para descubrir de forma dinámica el puerto por el que se puede acceder a un servicio determinado. En cada nodo servidor existe un programa llamado gestor de puertos (portmapper o el rpcbind) que mantiene una lista de programas locales de RPC activos, el número de versión de los programas, el protocolo o protocolo de transporte, puertos en los que se ejecutan los programas.
El programa portmapper, arranca al inicializarse el computador servidor de RPC. Cuando un programa de RPC arranca, toma un puerto sin usar del sistema operativo y le dice al portmapper que está preparado para el trabajo, es decir, registra en el portmapper su puerto, número de programa y versión. El portmapper escucha en el puerto público 111. Cuando un cliente quiere acceder a un servicio de RPC, envía un mensaje de RPC al portmapper por el puerto 111, el mensaje contiene el número de programa, versión y protocolo de transporte (UDP o TCP) del servicio. El portmapper reenvía la petición al servicio y reenvía de nuevo la respuesta al cliente, indicando el puerto actual para el servicio para que las llamadas futuras se puedan enviar directamente.
El portmapper permite que algunos servicios de RPC sean de difusión. En este caso el cliente difunde una petición de RPC en un enlace. Por ejemplo el rusers que pide a todas las máquinas de una LAN que informen de los usuarios conectados. El rusers puede ejecutarse en un puerto diferente en cada nodo.

Autenticación de RPC

Hay servicios que no requieren ninguna protección de seguridad, sin embargo existen casos donde si es necesario incluir información de autenticación tanto en las peticiones como en las respuestas. La información de autenticación aparece en dos campos:
- El campo credenciales, contiene la información de identificación.

- El campo comprobador (verifier), contiene información adicional y valida la identidad.

No existe un estándar único para autenticación. Cada diseñador debe decidir las necesidades de sus programas. A cada método de autenticación se le llama sabor (flavor). Los campos de credencial y de comprobador comienzan con un número de sabor, se pueden registrar valores nuevos de sabores de autenticación de la misma forma que se registran los programas nuevos.

Autenticación nula

Tanto la credencial y el comprobador del mensaje de llamada como el comprobador de la respuesta tienen un 0 como número de sabor, lo que quiere decir que no se incluye más información.

Autenticación del sistema

Proporciona información según el modelo de información del usuario. Las credenciales del sistema incluyen:
Stamp (sello), ID arbitrario generado por la computadora que llama.
Machinename, nombre de la máquina que llama.
Uid, número de ID de usuario efectivo del que llama.
Gid, número de ID de grupo efectivo del que llama.
Gids, lista con los grupos a los que pertenece el que llama.
El comprobador del que llama es nulo. El comprobador que devuelve el servidor puede ser nulo o puede tener un sabor “corto”, es decir, que devuelve una cadena de octetos específica del sistema. En algunas implementaciones, el que llama utiliza esta cadena de octetos como credencial en los mensajes siguientes, en vez de la información de usuario y grupo. Cabe destacar que este método no ofrece ningún tipo de seguridad.

Autenticación DES (estándar de cifrado de datos)

Es un algoritmo de cifrado simétrico. Se basa en una mezcla de claves asimétricas públicas y privadas y un cifrado DES simétrico: se asocia un nombre de usuario a una clave pública, el servidor cifra la clave de la sesión DES con la clave pública y se la envía al proceso cliente del usuario, se usa la clave se sesión DES para cifrar la información de autenticación del cliente y del servidor.

Autenticación de Kerberos
Se basa en el uso de un servidor de seguridad de Kerberos en el que se almacenan los usuarios y las claves de servidores, basadas en contraseñas. Kerberos autentica un servicio de RPC utilizando las claves secretas de cliente y servidor registradas en el servidor de seguridad de Kerberos para distribuir una clave de sesión DES al cliente y al servidor. También puede autenticar un servicio utilizando la clave de sesión DES para cifrar la información de autenticación del cliente y el servidor.

La capa XDR (representación externa de datos) 

La cual provee independencia de la data, incluye un lenguaje de definición de tipos de datos y un método de codificación de los mismos con un formato normalizado para su transmisión.

Lenguaje de descripción de datos XDR
Las definiciones de XDR son similares a los tipos de datos de los lenguajes de programación y son muy sencillas de entender. Algunos tipos de datos básicos de XDR son: enteros con signo y sin signo, enteros enumerados, cadenas ASCII, booleanos y números coma flotante. A partir de los tipos de datos básicos se construyen otros más complicados como arrays, estructuras y uniones. Un ejemplo del tipo entero enumerado es el tipo mensaje (msg-type), que indica si un mensaje es una llamada o una respuesta.
Enum msg_type {
CALL = 0,
REPLY = 1
};

Codificación de XDR
Los mensajes de llamada y respuesta de una versión determinada de programa y de procedimiento tienen un formato fijo. Se conoce el tipo de datos que habrá en un campo por su posición en el mensaje. El tamaño de cada campo debe ser un múltiplo de 4 bytes. Tiene como ventaja que los datos se codifican con muy pocos.