Familiarizándonos con una Red SMB/CIFS.
Ahora que ya tienes una breve visión de Samba, tomémonos algún tiempo para familiarizarnos con el entorno que ha adoptado Samba: una red SMB/CIFS. Trabajar con redes SMB es significativamente diferente a trabajar con redes Unix TCP/IP, debido a que hay bastantes conceptos nuevos que aprender y mucha información a cubrir. Primero, discutiremos los conceptos básicos existentes tras una red SMB, seguido de algunas implementaciones de Microsoft a SMB, y finalmente te mostraremos dónde puede encajar un servidor Samba y dónde no.
Comprendiendo NetBIOS.
Para comenzar, volvamos al pasado. En 1984, IBM diseñó un simple “application programming interface” (API) para conectar en red sus computadoras, llamado Network Basic Input/Output System (NetBIOS). El API NetBIOS proporcionaba un diseño rudimentario para que una aplicación se conectara y compartiese datos con otras computadoras.
Es útil pensar en el API NetBIOS como en extensiones de red para llamadas de la API BIOS estándar. Con BIOS, cada llamada de bajo nivel está confinada al hardware de la máquina local y no necesita ayuda para viajar a su destino. NetBIOS, sin embargo, originalmente tenía que intercambiar instrucciones con computadoras de redes IBM PC o Token Ring. Exigió por consiguiente un protocolo de transporte de bajo nivel para llevar las peticiones de una computadora a la siguiente.
A finales de 1985, IBM lanzó dicho protocolo, el cual unión con el API NetBIOS para convertirse en NetBIOS Extended User Interface (NetBEUI). NetBEUI fue diseñado para redes de área local (LANs), y permitía a cada máquina usar un nombre (de hasta 15 caracteres) que no estuviera siendo usado en la red. Entendemos por pequeña LAN, a una red de menos de 255 nodos -¡Esto se consideraba un restricción práctica en 1985!-.
El protocolo NetBEUI se volvió muy popular en las aplicaciones de red, incluyendo a las que corrían bajo Windows para Grupos. Más tarde, emergieron también implementaciones de NetBIOS sobre protocolos IPX de Novell, los cuales competían con NetBEUI. Sin embargo, los protocolos de red escogidos por la comunidad de Internet eran TCP/IP y UDP/IP, y las implementaciones de las APIs NetBIOS sobre dichos protocolos pronto se convirtió en una necesidad.
Ten en cuenta que TCP/IP usa números para representar direcciones de computadoras, tales como 192.168.220.100, mientras que NetBIOS usa sólo nombres. Este fue el mayor problema a solucionar a la hora de hacer relacionarse a los dos protocolos. En 1987, El Internet Engineering Task Force (IETF) publicó una serie de documentos de estandarización, titulados RFC 1001 y 1002, que perfilaban cómo NetBIOS podría trabajar sobre una red TCP/UDP. Este juego de documentos todavía gobiernan a cada una de las implementaciones que existen hoy en día, incluyendo aquellas proporcionadas por Microsoft para sus sitemas operativos, así como a la suite Samba.
Desde entonces, la norma que estos documentos gobiernan se ha conocido como NetBIOS sobre TCP/IP, o NBT para abreviar. El estándar NBT (RFC 1001/1002) actualmente establece un trio de servicios sobre una red:
* Un Servicio de Nombres
* Dos Servicios de Comunicación:
o Datagramas.
o Sesiones.
El servicio de nombres resuelve el problema nombre-a-dirección comentado antes; pemite a cada computadora declarar un nombre específico en la red que pueda ser convertido a una dirección IP de máquina, como hacen hoy en día los DNS en Internet. Los servicios de datagramas y sesiones son ambos protocolos secundarios de comunicación, usados para transmitir datos desde y hacia máquinas NetBIOS a través de la red.
1.3.2 Obteniendo un Nombre
Para un ser humano, tener un nombre es sencillo. Sin embargo, para una máquina sobre una red NetBIOS, esto puede ser algo más complicado. Veamos algunos de esos problemas.
En el mundo NetBIOS, cuando cada máquina se vuelve activa, quiere reclamar un nombre para sí; esto se denomina registro de nombre. Sin embargo, dos máquinas en el mismo grupo de trabajo podrían solicitar el mismo nombre; esto causaría problemas de confusión para cualquier máquina que quiera comunicar con una de esas dos. Hay dos aproximaciones diferentes para asegurarnos de que esto no ocurra:
* Usar un Servidor de Nombres NetBIOS (NBNS) para controlar el registro de nombres NetBIOS de las máquinas.
* Permitir a cada máquina de la red defender su nombre en el caso de que otra máquina intente usarlo.
La Figura 8 ilustra un registro de nombre (negado), con y sin Servidor de Nombres NetBIOS.
Figure: Registro de Nombre NBNS contra no-NBNS.
En adición, debe haber una forma de resolver un nombre NetBIOS hacia una dirección IP específica como ya mencionamos antes; esto es conocido como resolución de nombre. Hay dos formas diferentes también aquí con NBT:
* Haber reportado cada máquina su dirección IP cuando “escucha” una petición broadcast para su nombre NetBIOS.
* Usar el NBNS para resolver nombres NetBIOS a direcciones IP.
La Figura 9 ilustra los dos tipos de resolución de nombre.
Figure: Resolución de nombre con-NBNS versus sin-NBNS.
Como te puedes imaginar, tener un NBNS en tu red te puede ayudar enormemente. Para ver exáctamente por qué, veamos el método sin-NBNS.
Aquí, cuando una máquina cliente arranca, manda un mensaje broadcast declarando que desearía registrar un nombre NetBIOS específico para ella. Si nadie objeta nada ante el uso de ese nombre tras múltiples intentos de registro, obtiene el nombre. En la otra parte, si otra máquina en la red está actualmente usando ese nombre, enviará un mensaje de respuesta al cliente solicitante indicando que ese nombre ya está siendo usado. Esto es conocido como defender el nombre de host. Este tipo de sistema es útil cuando un cliente ha caído inesperadamente de la red -otro puede tomar su nombre-, pero se incurre en un importante aumento del tráfico de la red para algo tan simple como el registro de nombre.
Con un NBNS, ocurre lo mismo, pero con la diferencia de que la comunicación se está confinada a la máquina solicitante y al servidor de nombres NBNS. No ocurre broadcasting cuando la máquina desea registrar el nombre; el mensaje de registro es simplemente enviado desde el cliente hacia el servidor NBNS, y este NBNS responde si el nombre está o no libre. Esto es conocido como comunicación punto-a-punto, y es beneficioso en redes con más de una subred. Esto se debe a que los routers suelen estar preconfigurados para bloquear paquetes entrantes que son mensajes de difusión (broadcast) para todas las máquinas de la red.
Los mismos principios se aplican a la resolución de nombres. Sin un NBNS, la resolución de nombres NetBIOS podría realizarse mediante un mecanismo broadcast. Todos los paquetes se enviarían a cada una de las computadoras de la red, con la esperanza de que alguna máquina que se vea afectada por la petición responda directamente a la máquina solicitante. En éste punto, queda claro que usar un servidor de nombres NBNS y una comunicación punto-a-punto para este propósito carga mucho menos la red que usar boradcasts para cada una de las peticiones de resolución de nombres que se produzcan.
Tipos de Nodos.
¿Y cómo le digo a los clientes qué estrategia deben seguir para realizar el registro de nombre y la resolución? Cada máquina en una red NBT aprende una de las siguientes designaciones, dependiendo de cómo se maneje el registro y la resolución de nombre: b-node, p-node, m-node y h-node. Las conductas de cada tipo de nodo se resumen en la Tabla 1.
Table: Tipos de Nodos NetBIOS
Papel
Valor
b-node
Usa registro broadcast y sólo resolución.
p-node
Usa registro punto-a-punto y sólo resolución.
m-node
Usa broadcast para registro. Si tiene éxito, notifica al servidor NBNS el resultado. Usa broadcast para resolución; usa servidor NBNS si el broadcast no tiene éxito.
h-node (hybrid)
Usa servidor NBNS para registro y resolución; usa broadcast si el servidor NBNS no responde o no está operativo.
En el caso de los clientes Windows, los encontrarás listados normalmente como h-nodes o hybrid nodes. Incidentalmente,los h-nodes fueron inventados más tarde por Microsoft, como un tipo de nodo más tolerante a fallos de rutas, y no aparece en el RFC 1001/1002.
Puedes averiguar el tipo de nodo para cada máquina Windows tecleando el comando ipconfig /all y buscando la línea que pone Node Type.
C:>ipconfig /all
Windows 98 IP Configuration
…
Node Type . . . . . . . . . . : Hybrid
…
¿Qué hay en un Nombre?
Los usos de creación de nombres NetBIOS son diferentes a los de los nombres tipo DNS a los que a lo mejor estarás más acostumbrado. Primero, los nombres NetBIOS existen en un espacio único. En otras palabras, no existen cualificadores del tipo ora.com o samba.org para definir secciones dentro de los nombres; sólo hay un nombre único para representar a cada computadora. Segundo, los nombres NetBIOS sólo pueden contener hasta 15 caracteres, no pueden comenzar con asterisco (*), y pueden consistir sólo en caracteres alfanuméricos estandard (a-z, A-Z, 0-9) y los siguientes:
! @ # $ % ^ & ( ) – ‘ { } . ~
Aunque puedes usar el punto (.) en un nombre NetBIOS, no te lo recomendamos, debido a que esos nombres puede que no funcionen en las futuras versiones de NetBIOS sobre TCP/IP.
No es una coincidencia que todos los nombres válidos DNS también sean válidos en NetBIOS. De hecho, el nombre DNS para un servidor Samba es frecuentemente reusado como su nombre NetBIOS. Por ejmplo, si tienes una máquina phoenix.ora.com , su nombre NetBIOS podría ser PHOENIX (seguido por 8 espacios en blanco).
1.3.4.1 Nombres de Recursos y Tipos
Con NetBIOS, una máquina no sólo advierte de su presencia, sino que también le dice a las otras máquinas qué tipo de servicios ofrece. Por ejemplo, phoenix puede indicar que no es sólo una estación de trabajo, sino que también es un servidor de ficheros y puede recibir mensajes WinPopup. Esto se hace añadiendo un byte (el 16) al final del nombre de máquina (recurso), llamado tipo de recurso, y registrando el nombre más de una vez. Mira la Figura 10
El tipo de recurso de 1 byte indica el único servicio que la máquina ofrece. En este libro, frecuentemente verás el tipo de recurso marcado entre símbolos de mayor/menor (<>) tras el nombre NetBIOS, como a continuación:
PHOENIX<00>
Puedes saber qué nombres están registrados para una máquina NBTdeterminada usando el comando de Windows NBTSTAT. Debido a que estos servicios son únicos (no puede haber más de uno registrado), los verás listados como tipo UNICO (UNIQUE) en la salida. Por ejemplo, la siguiente salida describe al servidor hydra:
D:>NBTSTAT -a hydra
NetBIOS Remote Machine Name Table
Name Type Status
——————————————————–
HYDRA <00> UNIQUE Registered
HYDRA <03> UNIQUE Registered
HYDRA <20> UNIQUE Registered
…
Esto indica que el servidor ha registrado el nombre NetBIOS hydra como nombre de máquina (estación de trabajo), un recipiente para mensajes WinPopup y un servidor de ficheros. Algunos de los posibles atributos que un nombre puede tener se listan en la Tabla 2.
Table: Tipos de Recursos Unicos NetBIOS.
Nombre Recurso
Hexidecimal Byte Value
Standard Workstation Service
00
Messenger Service (WinPopup)
03
RAS Server Service
06
Domain Master Browser Service (associated with primary domain controller)
1B
Master Browser name
1D
NetDDE Service
1F
Fileserver (including printer server)
20
RAS Client Service
21
Network Monitor Agent
BE
Network Monitor Utility
BF
Advierte que debido a que los nombres DNS no tiene tipos de recursos, los diseñadores intencionadamente pusieron un valor hexadecimal 20 (un espacio en blanco) por defecto para el tipo de servidor de ficheros.
Fuente original del artìculo.
elmundodeubuntu