6.4. Familiarizándose con una red SMB

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.

6.4.1. Comprendiendo NetBIOS

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]:

Figura 6.8. Protocolos sobre los que corre SMB[16]

Protocolos sobre los que corre SMBSi quiere obtener el código fuente de esta figura realizada con pulse aquí .

6.4.2. Obteniendo un nombre

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.

Figura 6.9. Registro de nombres Broadcast versus NBNS[17]

Registro de nombres Broadcast versus NBNSSi quiere obtener el código fuente de esta figura realizada con pulse aquí .

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.

Figura 6.10. Resolución de nombres Broadcast versus NBNS[18]

Resolución de nombres Broadcast versus NBNSSi quiere obtener el código fuente de esta figura realizada con pulse aquí .

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.

6.4.3. Tipos de nodos

¿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

RolValor
b-nodeHace uso de registro y resolución broadcast únicamente
p-nodeHace 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.

6.4.4. ¿Qué hay en un nombre?

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

6.4.4.1. Nombres de recursos y tipos

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

Figura 6.11. Estructura de nombres NetBIOS[19]

Estructura de nombres NetBIOSSi quiere obtener el código fuente de esta figura realizada con pulse aquí.

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 RecursoValor en hexadecimal del byte
Standard Workstation Service00
Messenger Service03
RAS Server Service06
Domain Master Browser Service (associated with primary domain controller)1B
Master Browser name1D
NetDDE Service1F
Fileserver (including printer server)20
RAS Client Service21
Network Monitor AgentBE
Network Monitor UtilityBF

6.4.4.2. Nombres de grupos y tipos

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 RecursoValor en hexadecimal del byte
Standard Workstation group00
Logon server1C
Master Browser name1D
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.

6.4.5. Scope ID

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.

6.4.6. Datagramas y sesiones

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

PrimitivaDescripción
Send DatagramEnvía un paquete datagrama a un ordenador o grupo de ordenadores
Send Broadcast DatagramDifunde (broadcast) datagramas a cualquier ordenador, esperando por un Receive Broadcast datagram (datagrama de acuse de recibo)
Receive DatagramRecibe un datagrama desde un ordenador
Receive Broadcast DatagramEspera 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

PrimitivaDescripción
CallInicia una sesión con un ordenador que está escuchando bajo un nombre determinado
ListenEspera por una llamada desde un emisor conocido o cualquier emisor
Hang-upFinaliza una conversación
SendEnvía datos al otro ordenador
ReceiveRecibe datos del otro ordenador
Session StatusObtiene 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.



[14] También se puede ver la abreviación NetBT, utilizada comúnmente en la literatura de Microsoft.

[15] El gráfico ha sido obtenido de la entrada bibliográfica Sharpe01.

[16] Si quiere obtener el código fuente de esta figura realizada con Dia pulse aquí .

[17] Si quiere obtener el código fuente de esta figura realizada con Dia pulse aquí .

[18] Si quiere obtener el código fuente de esta figura realizada con Dia pulse aquí .

[19] Si quiere obtener el código fuente de esta figura realizada con Dia pulse aquí.