Ahora que ya posee una breve visión sobre Samba, tómese algún tiempo para familiarizarse con el entorno que ha adoptado Samba: una red SBM. Trabajar con redes SBM es significativamente diferente a trabajar con protocolos comunes de TCP/IP, como FTP o SSH, debido a que hay bastantes conceptos nuevos que aprender y mucha información a cubrir. Primero, se discutirán los conceptos básicos existentes tras una red SBM, seguido de algunas implementaciones de Microsoft sobre SBM, para finalmente mostrar donde puede encajar un servidor Samba y dónde no.
Para comenzar, echemos la vista atrás. En 1984, IBM diseñó una API (Application Programming Interface) simple para conectar en red sus ordenadores, llamada Network Basic Input/Output System (NetBIOS). La API NetBIOS proporcionaba un diseño rudimentario para que una aplicación se conectase y compartiese datos con otros ordenadores.
Es útil pensar en la API NetBIOS como una extensión de red para las llamadas de la API BIOS estándar. La BIOS contiene código de bajo nivel para realizar operaciones en el sistema de archivos de un ordenador local. Originalmente, NetBIOS tenía que intercambiar instrucciones con los ordenadores a través de redes IBM PC o Token Ring. Esto exigió un protocolo de transporte de bajo nivel para transportar las peticiones de un ordenador al siguiente.
A finales de 1985, IBM liberó dicho protocolo, combinándolo con la API NetBIOS para convertirse en NetBIOS Extended User Interface (NetBEUI). NetBEUI fue diseñado para pequeñas redes de área local (LANs), permitiendo a cada ordenador usar un nombre (de hasta 15 caracteres) que no estuviese siendo utilizado en la red. Se entiende por una “LAN pequeña”, una red de menos de 255 nodos -¡Esto se consideraba un número generoso en 1985!-.
El protocolo NetBEUI se volvió muy popular en las aplicaciones de red, incluyendo aquellas que corrían bajo Windows for Workgroups. Más tarde, aparecieron implementaciones de NetBIOS sobre los protocolos IPX de Novell, los cuales competían con NetBEUI. Sin embargo, los protocolos de red escogidos por la floreciente comunidad de Internet fueron TCP/IP y UDP/IP, así como las implementaciones de las APIs NetBIOS sobre dichos protocolos, que pronto se convirtieron en una necesidad.
Recuerde que TCP/IP hace uso de números para representar las direcciones de los ordenadores (192.168.220.100, por ejemplo), mientras que NetBIOS usa sólo nombres. Este fue el mayor problema encontrado a la hora de juntar los dos protocolos. En 1987, el grupo IETF (Internet Engineering Task Force) 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 conjunto de documentos todavía lidera las implementaciones que existen hoy en día, incluyendo aquellas proporcionadas por Microsoft para sus sistemas operativos Windows, así como a la suite Samba.
Desde entonces, el estándar que estos documentos lideran se ha convertido en NetBIOS sobre TCP/IP, o NBT[14] 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 del paso de un nombre a una dirección anteriormente comentado; permite a cada ordenador proclamar un nombre específico en la red que puede se puede convertir en una dirección IP legible, como hacen hoy en día los DNS en Internet. Los servicios de datagramas y sesiones son protocolos secundarios de comunicación, usados para transmitir datos desde y hacia máquinas NetBIOS a través de la red.
Como se ha visto hasta este momento, SMB puede correr sobre múltiples protocolos. El siguiente diagrama muestra este hecho[15]:
En el mundo NetBIOS, cuando cada ordenador se activa, quiere reclamar un nombre para sí; esto se denomina registro de nombre. Sin embargo, dos máquinas en el mismo grupo de trabajo no podrían solicitar el mismo nombre; ya que esto confundiría a una máquina que quisiese comunicarse con cualquiera de esas dos. Existen dos métodos diferentes para asegurarse de que esto no ocurrirá:
Hacer uso de NBNS para controlar el registro de nombres NetBIOS por parte de las máquinas
Permitir la defensa de su nombre a cada máquina de la red, en el caso de que otra máquina intente usarlo
La Figura 6.9, “Registro de nombres Broadcast versus NBNS” ilustra un registro de nombre (fallido), con y sin NBNS.
Como se mencionó anteriormente, debería existir alguna forma de resolver nombres NetBIOS a la dirección IP correspondiente; a esto se le conoce como resolución de nombres. Existen dos estrategias diferentes con NBT aquí también:
Que cada ordenador comunique su dirección IP cuando “escuche” una petición broadcast para su nombre NetBIOS
Usar el NBNS para ayudar a resolver los nombres NetBIOS a direcciones IP
La Figura 6.10, “Resolución de nombres Broadcast versus NBNS” ilustra los dos tipos de resolución de nombres.
Como se podría esperar, tener un NBNS en su red puede ayudar enormemente. Para ver exactamente por qué, eche un vistazo al método broadcast.
Aquí, cuando un cliente arranca, envía un mensaje broadcast manifestando su deseo de registrar un nombre NetBIOS específico para el. Si nadie pone objeción al uso del nombre, el obtiene el nombre. Por otro lado, si otra máquina en la subred local 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 del host. Este tipo de sistema es útil cuando un cliente se 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 un nombre.
Con un NBNS, ocurre lo mismo, pero con la diferencia de que la comunicación está confinada a la máquina solicitante y al servidor de nombres NBNS. No se produce un broadcast cuando una máquina desea registrar su nombre; el mensaje de registro es simplemente enviado desde el cliente hacia el servidor NBNS, y el servidor NBNS responde si el nombre está o no libre. A esto se le denomina 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 los paquetes broadcast entrantes.
Los mismos principios se aplican a la resolución de nombres. Sin un servidor NBNS, la resolución de nombres NetBIOS se podría realizar mediante broadcast. Todos los paquetes se enviarían a cada ordenador de la red, con la esperanza de que el ordenador afectado por la petición responda directamente a la máquina solicitante. El uso de un servidor NBNS y la comunicación punto-a-punto para este propósito carga mucho menos la red que inundar la red con peticiones broadcast para cada petición de resolución de nombres que se produzca.
Se puede discutir que los paquetes broadcast no causan problemas significativos en las redes modernas y de gran ancho de banda compuestas por máquinas con CPUs muy rápidas, si sólo un grupo reducido de ordenadores están presentes en la red, o la demanda de ancho de banda es pequeña. Hay muchos casos en los que la anterior suposición es cierta; sin embargo, se aconseja no confiar en el broadcast tanto como se pueda. Esta es una regla a seguir en redes grandes y saturadas, y si se sigue este consejo a la hora de configurar redes pequeñas, estas podrán crecer sin problemas en el futuro.
¿Cómo informo a los clientes sobre la estrategia a seguir para realizar el registro y la resolución de nombres? Cada máquina en una red NBT gana una de las siguientes designaciones, dependiendo de cómo se maneje el registro y la resolución de nombres: b-node, p-node, m-node y h-node. El comportamiento de cada tipo de nodo se resumen en la Tabla 6.1, “Tipos de nodo NetBIOS”.
Tabla 6.1. Tipos de nodo NetBIOS
| Rol | Valor |
|---|---|
| b-node | Hace uso de registro y resolución broadcast únicamente |
| p-node | Hace uso de registro y resolución punto-a-punto únicamente |
| m-node (mixto) | Hace uso de broadcast para el registro. Si lo consigue, notifica al servidor NBNS el resultado. Hace uso de broadcast para la resolución; utiliza NBNS si el broadcast no ha tenido éxito |
| h-node (híbrido) | Hace uso del servidor NBNS para el registro y la resolución; utiliza broadcast si el servidor NBNS no responde o no está operativo |
Los clientes Windows suelen encontrarse como h-nodes o nodos híbridos. Los tres primeros tipos de nodos aparecen el los RFCs 1001/1002, y los h-nodes fueron inventados más tarde por Microsoft, como un método más tolerable a fallos.
Puede encontrar el tipo de nodo de un ordenador Windows 95/98/Me ejecutando el comando winipcfg y pulsando sobre el botón de Más información. En Windows NT/2000/XP, puede hacer uso del comando ipconfig /all en el prompt de una ventana de comandos. En cualquier caso, busque la línea que diga Node Type.
Los nombres utilizados en NetBIOS son ligeramente diferentes de los nombres empleados en los DNS, con los que estará familiarizado. En primer lugar, los nombres NetBIOS existen en un espacio de nombres único. En otras palabras, no existen niveles jerárquicos como en samba.org (dos niveles) o en ftp.samba.org (tres niveles). Los nombres NetBIOS están formados por una única cadena como toltec o maya, cada uno de ellos pertenecientes a un grupo de trabajo o un dominio. En segundo lugar, los nombres NetBIOS sólo pueden contener 15 caracteres y están compuestos únicamente por los caracteres alfanuméricos estándar (a-z, A-Z, 0-9) y los siguientes:
! @ # $ % ^ & ( ) - ' { } . ~ |
Aunque se puede hacer uso del punto (.) en un nombre NetBIOS, no es recomendable, debido a que esos nombres puede que no funcionen en futuras versiones de NBT.
No es una coincidencia que todos los nombres DNS válidos también sean válidos en NetBIOS. De hecho, el nombre DNS para un servidor Samba es frecuentemente usado como su nombre NetBIOS. Por ejemplo, si tiene un sistema con el siguiente nombre: toltec.ora.com, su nombre NetBIOS podría ser TOLTEC (seguido de 9 espacios en blanco).
Con NetBIOS, un ordenador no sólo anuncia su presencia, sino que también comunica a las otras máquinas que tipo de servicios ofrece. Por ejemplo, toltec puede indicar que no es únicamente una estación de trabajo, sino que también es un servidor de ficheros y puede recibir mensajes Windows Messenger. Esto se consigue añadiendo el byte décimosexto al final del nombre de la máquina (recurso), denominado tipo de recurso, y registrando el nombre más de una vez, una vez por cada servicio que ofrece. Observe la Figura 6.11, “Estructura de nombres NetBIOS”.
El tipo de recurso de 1 byte indica el único servicio que el ordenador ofrece. La notación empleada a partir de este momento para mostrar el tipo de servicio ofrecido por un determinado ordenador estará enmarcada entre los símbolos de mayor y menor que (<>) después del nombre NetBIOS, como se muestra en el Ejemplo 6.4, “Notación empleada para mostrar el tipo de servicio NetBIOS ofrecido por un ordenador”:
Ejemplo 6.4. Notación empleada para mostrar el tipo de servicio NetBIOS ofrecido por un ordenador
TOLTEC<00> |
Puede saber qué nombres están registrados para una máquina NBT determinada usando el comando de Windows nbtstat. Debido a que estos servicios son únicos (no puede haber más de uno registrado), aparecerán listados como tipo ÚNICO (UNIQUE) en la salida. Por ejemplo, el Ejemplo 6.5, “Ejecución del comando nbtstat” describe al servidor toltec:
Ejemplo 6.5. Ejecución del comando nbtstat
D:\> nbtstat -a toltec
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
TOLTEC <00> UNIQUE Registered
TOLTEC <03> UNIQUE Registered
TOLTEC <20> UNIQUE Registered
... |
Esto indica que el servidor ha registrado el nombre NetBIOS toltec como nombre de máquina, como un receptor de mensajes desde el servicio Messenger de Windows y como un servidor de archivos. Algunos de los posibles atributos que un nombre puede tener se listan en la Tabla 6.2, “Tipos de recursos únicos NetBIOS”.
Tabla 6.2. Tipos de recursos únicos NetBIOS
| Nombre del Recurso | Valor en hexadecimal del byte |
|---|---|
| Standard Workstation Service | 00 |
| Messenger Service | 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 |
SMB también usa el concepto de grupos, con los cuales los ordenadores se pueden registras ellos mismos. Anteriormente se mencionó que los ordenadores del ejemplo pertenecían a un grupo de trabajo, el cual es una partición de ordenadores en la misma red. Por ejemplo, una empresa podría tener fácilmente un grupo de trabajo ADMINISTRACIÓN 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 el ejemplo sobre nbtstat, el servidor Samba toltec es también un miembro del grupo de trabajo METRAN (el atributo GROUP hex 00), y participará en la elección del buscador (browser) maestro (atributo GROUP 1E). Observe el Ejemplo 6.6, “Muestra de los grupos a los que pertenece un servidor con nbtstat”>:
Ejemplo 6.6. Muestra de los grupos a los que pertenece un servidor con nbtstat
NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- METRAN <00> GROUP Registered METRAN <1E> GROUP Registered ..__MSBROWSE__.<01> GROUP Registered |
Los posibles atributos de grupo que puede tener una máquina se ilustran en la Tabla 6.3, “Tipos de Recursos de Grupo NetBIOS”. Existe más información disponible en el libro “Windows NT in a Nutshell” de Eric Pearce, publicado por O'Reilly.
Tabla 6.3. Tipos de Recursos de Grupo NetBIOS
| Nombre del Recurso | Valor en hexadecimal del byte |
|---|---|
| Standard Workstation group | 00 |
| Logon server | 1C |
| Master Browser name | 1D |
| Normal Group name (used in browser elections) | 1E |
| Internet Group name (administrative) | 20 |
| <01><02>_ _MSBROWSE_ _<02> | 01 |
La entrada final, _ _ MSBROWSE _ _, es utilizada para anunciar un grupo a otros buscadores maestros. Los caracteres no imprimibles en el nombre se muestran como guiones bajos en una salida de nbtstat. No se preocupe si no comprende todos los recursos o tipos de grupos. Algunos de ellos no los necesitará con Samba, y sobre los otros se verá más en el resto del capítulo. Lo importante aquí es recordar la lógica del mecanismo de nombres.
En los años oscuros del funcionamiento en red de SMB, antes de la introducción de los grupos NetBIOS, se debía utilizar una estrategia muy primitiva para aislar grupos de ordenadores del resto de la red. Cada paquete SMB contenía un campo denominado scope ID, la idea era que los sistemas de la red se pudiesen configurar de forma que sólo aceptasen los paquetes con el scope ID que coincidiese con su configuración. Esta característica fue apenas utilizada y desgraciadamente aun pervive en las implementaciones modernas. Algunas de las utilidades incluidas en la distribución de Samba permite establecer el scope ID. El establecimiento del scope ID en una red es sinónimo de problemas, sólo se ha mencionado para evitar confusiones cuando aparezca el término más adelante.
En este punto, se hará un paréntesis para abordar la responsabilidad de NBT: proporcionar servicios de conexión entre dos máquinas NetBIOS. NBT ofrece dos servicios: el servicio de sesión y el servicio de datagramas. Comprender cómo funcionan estos servicios no es vital para usar Samba, pero le dará una idea sobre cómo trabaja NBT y cómo arreglar problemas cuando Samba no funcione.
El servicio de datagramas no proporciona una conexión estable entre ordenadores. Los paquetes de datos se envían o difunden (broadcast) de una máquina a otra, sin tener en cuenta el orden en que estos llegan al destino, o incluso si han llegado todos. El uso de datagramas requiere menos procesamiento que las sesiones, aunque la confiabilidad de la conexión puede sufrir. Los datagramas, por tanto, son empleados para enviar rápidamente bloques no vitales de datos a una o más máquinas. El servicio de datagramas se comunica usando las primitivas que se muestran en la Tabla 6.4, “Primitivas de datagrama”.
Tabla 6.4. Primitivas de datagrama
| Primitiva | Descripción |
|---|---|
| Send Datagram | Envía un paquete datagrama a un ordenador o grupo de ordenadores |
| Send Broadcast Datagram | Difunde (broadcast) datagramas a cualquier ordenador, esperando por un Receive Broadcast datagram (datagrama de acuse de recibo) |
| Receive Datagram | Recibe un datagrama desde un ordenador |
| Receive Broadcast Datagram | Espera por un datagrama de difusión (broadcast) |
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, analogía que obviamente influyó en el diseño del estándar CIFS.
Una vez que se establece la conexión, permanece abierta durante toda la conversación, cada lado conoce quien es el ordenador emisor y receptor, y cada uno se puede comunicar haciendo uso de las primitivas mostradas en la Tabla 6.5, “Primitivas de sesión”.
Tabla 6.5. Primitivas de sesión
| Primitiva | Descripción |
|---|---|
| Call | Inicia una sesión con un ordenador que está escuchando bajo un nombre determinado |
| Listen | Espera por una llamada desde un emisor conocido o cualquier emisor |
| Hang-up | Finaliza una conversación |
| Send | Envía datos al otro ordenador |
| Receive | Recibe datos del otro ordenador |
| Session Status | Obtiene información de las sesiones solicitadas |
Las sesiones son el backbone de la compartición de recursos en una red NBT. Se utilizan normalmente para establecer conexiones estables desde los clientes a unidades de disco o impresoras compartidas en un servidor. El cliente “llama” al servidor y comienza a negociar la información, como los archivos que desea abrir, los datos que desea 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 error, el software de sesión (TCP) retransmitirá los datos hasta que se reciban correctamente, a diferencia del método “envía-y-reza” del servicio de datagramas (UDP).
En realidad, mientras que las sesiones se supone que están para manejar comunicaciones problemáticas, algunas veces no lo hacen. Si la conexión es interrumpida, la información de sesión que está abierta entre dos ordenadores puede volverse inválida. Si esto ocurre, la única forma de restablecer la sesión entre los dos ordenadores es llamar de nuevo y comenzar desde cero.
Si desea más información sobre estos servicios, eche un vistazo al RFC 1001. Sin embargo, hay dos cosas importantes a recordar aquí:
Las sesiones siempre ocurren entre dos máquinas NetBIOS. Si una sesión se interrumpe, se supone que el cliente ha almacenado suficiente información de estado para restablecerla. Sin embargo, en la práctica, normalmente esto no ocurre.
Los datagramas pueden ser difundidos (broadcast) hacia múltiples ordenadores, pero no son confiables. En otras palabras, no hay manera de que el emisor sepa si los datagramas que ha enviado han llegado correctamente a sus destinos.