Usando Samba - Familiarizandonos 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:
  • Datagramas.
  • 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.

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.

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

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

Figure: Estructura de un Nombre NetBIOS.

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.

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.

Nombres de Grupos y Tipos

SMB también usa el concepto de grupos. Anteriormente mencionamos que las máquinas de nuestro ejemplo pertenecían a un grupo de trabajo, el cual es una partición de másquinas en la misma red. Por ejemplo, una empresa podría tener fácilmente un grupo de trabajo ADMINISTRACION y otro VENTAS, cada uno con diferentes servidores e impresoras. En el mundo Windows, un grupo de trabajo y un grupo SMB son la misma cosa.

Continuando con nuestro ejemplo de NBTSTAT, el servidor Samba hydra es también un miembro del grupo de trabajo SIMPLE (el atributo GROUP hex 00), y estará disponible para ser elegido como visualizador maestro (atributo GROUP 1E). Mira la salida de NBTSTAT:

NetBIOS Remote Machine Name Table, continued
 Name                   Type               Status
 ------------------------------------------------------------------
 SIMPLE                 <00> GROUP         Registered
 SIMPLE                 <1E> GROUP         Registered
 .._ _MSBROWSE_ _.      <01> GROUP         Registered
 

Los posibles atributos de grupo que puede tener una máquina se ilustran en la Tabla 3. Para más información, Windows NT in a Nutshell de Eric Pearce, publicado por O'Reilly.

La entrada final, _ _ MSBROWSE _ _ , se usa para anunciar un grupo a otros visualizadores maestros. Los caracteres no impresos en el nombre se muestran como guiones bajos en una salida de NBTSTAT. No te preocupes si no comprendes todos los recursos o tipos de grupos. Algunos de ellos no los necesitarás con Samba, y sobre los otros verás más el resto del capítulo. Lo importante aquí es recordar la lógica del mecanismo de nombres.

Datagramas y Sesiones

Llegados a este punto, hagamos una introducción sobre otra responsabilidad de NBT: proporcionar servicios de conexión entre dos máquinas NetBIOS. Existen actualmente dos servicios ofrecidos por NetBIOS sobre TCP/IP: el servicio de sesiones y el servicio de datagramas. El comprender cómo funcionan estos dos servicios no es esencial para usar Samba, pero te va a dar una idea sobre cómo trabaja NBT y cómo arreglar problemas cuando Samba no funcione.

El servicio de datagramas ofrece una conexión no estable entre una máquina y otra. Los paquetes de datos son simplemente enviados o difundidos (broadcasting) de una máquina a otra, sin considerar el orden en que estos llegan al destino, o si han llegado todos. El uso de datagramas no incrementa tanto el trafico de la red como el uso de sesiones, aunque pueden echar abajo una red si se usan indebidamente (¿Te acuerdas de la difusión de la resolución de nombres de antes?) Los datagramas, por tanto, son empleados para enviar rápidamente sencillos bloques de datos a una o más máquinas. El servicio de datagramas comunica usando las primitivas simples mostradas en la Tabla 4.

El servicio de sesiones es más complejo. Las sesiones son un método de comunicación que, en teoría, ofrece la capacidad de detectar conexiones problemáticas o inoperativas entre dos aplicaciones NetBIOS. Esto lleva a pensar en una sesión NBT en términos de una llamada telefónica. Una conexión full-duplex es abierta entre una máquina que llama y una máquina que es llamada, y la conexión debe permanecer abierta durante la duración de la conversación. Cada parte implicada conoce a la otra máquina, y pueden comunicar con las primitivas que se muestran en la Tabla 5.

Las sesiones son el troncal de la compartición de recursos en una red NBT. Son normalmente usadas para establecer conexiones estables desde máquinas clientes a unidades de disco o impresoras compartidas en un servidor. El cliente "llama" e inicia la conversación, enviando información del tipo qué ficheros desea abrir, qué datos quiere intercambiar, etc. Estas llamadas pueden durar mucho tiempo -horas, incluso días- y todo esto ocurre dentro del contexto de una única conexión. Si se produce un errorerror, el software de sesión (TCP) retransmitirá hasta que los datos sean recibidos correctamente, a diferencia del "envía-y-reza" del servicio de datagramas (UDP).

En realidad, mientras que las sesiones se supone están para manejar comunicaciones problemáticas, normalmente no lo hacen. Como probablemente habrás descubierto al usar redes Windows, es un serio problema el usar sesiones NBT. Si la conexión es interrumpida por la razón que sea, la información de sesión que está abierta entre dos computadoras puede fácilmente volverse inválida. Si esto ocurre, la única forma de restablecer la sesión para las dos mismas máquinas es llamar de nuevo y comenzar desde ceero.

Si deseas más ínformación sobre cada uno de estos servicios, te recomendamos mires el RFC 1001. Sin embargo, hay dos cosas importantes a recordar aquí:

• Las sesiones siempre ocurren entre dos máquinas NetBIOS -ni más ni menos-. Si un servicio de sesión es interrumpido, se supone que el cliente ha almacenado la suficiente información de estado como para restablecer la comunicación. Sin embargo, en la práctica, es raro el caso.
• Los datagramas pueden ser difundidos a múltiples máquinas, pero son inestables. Dicho de otro modo, no hay forma para el emisor de saber si los datagramas que ha enviado han llegado correctamente a los destinatarios.