NetBIOS sobre una VPN: el nombre, el datagrama y la sesión son servicios separados
El eslogan sobre los enrutadores es demasiado amplio. Compruebe cuál de los tres servicios usa su aplicación y si resuelve nombres por difusión o mediante un servidor.
«NetBIOS no cruza enrutadores» se repite como si eso zanjara el diseño. No lo hace. Una consulta de nombre por difusión suele quedarse dentro de su propio dominio de difusión, pero los servicios NetBIOS también pueden usar tráfico IP dirigido que se enruta perfectamente bien. La pregunta útil no es si NetBIOS cruza enrutadores; es cuál de sus tres servicios usa su aplicación.
Una interfaz de software, no un único protocolo de cable
La RFC 1001 describe NetBIOS como una interfaz contra la que programan las aplicaciones, con varios transportes debajo. Su modelo TCP/UDP separa el servicio de nombres, la distribución de datagramas y el servicio de sesión, y admite explícitamente el funcionamiento con difusión IP o sin ella.
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
Esa tabla es la razón por la que el eslogan falla. Un servicio de sesión entre dos hosts con nombre es una conversación IP; un datagrama de difusión no lo es. Un diseño de VPN puede satisfacer lo primero y no lo segundo, y una prueba que demuestra lo primero no dice nada sobre lo segundo.
Los tipos de nodo deciden qué pide el cliente
Los modelos de nodo de difusión, punto a punto y mixto de la RFC 1001 describen cómo un host resuelve nombres: preguntando a la red local, preguntando directamente a un servidor de nombres o probando uno y luego el otro. El modelo afecta qué tráfico debe permitirse, no si la aplicación funciona en absoluto.
Una disposición gestionada con servidor de nombres da a los clientes una ruta punto a punto, pero solo a los clientes configurados para usarla. Poner un servidor en algún lugar de la red no hace que una aplicación lo consulte, y un cliente que se deja en modo de difusión seguirá preguntando al segmento local y agotará el tiempo de espera. La dirección del servidor tiene que llegar a la configuración del cliente, por el camino de gestión que ese cliente respete.
Así que anote tres observaciones para la aplicación en cuestión: cómo convierte el nombre del servidor en una dirección, si el descubrimiento o la mensajería usa difusión o un extremo dirigido, y qué dirección y transporte usa la sesión real. Son hechos independientes y cada uno tiene su propia solución. Un solo éxito de resolución de nombres es evidencia solo sobre el primero.
NetBIOS sobre TCP/IP no es NetBEUI
Los dos se confunden porque a ambos se les llama obsoletos. NetBIOS sobre TCP/IP lleva sus servicios dentro de paquetes IP, que un túnel enrutado ya transporta. NetBEUI es un protocolo de capa 2 que no se puede enrutar, y un túnel IP no transporta tramas Ethernet arbitrarias solo porque transporte IP.
Añadir una ruta IP no puede convertir una trama que no es IP en una aplicación IP. Si una aplicación depende de verdad del comportamiento de la capa 2, las opciones son un servicio de capa 2 explícitamente delimitado o sustituir la aplicación; ningún cambio de enrutamiento sustituye a ninguna de las dos.
Elija el cambio más pequeño que satisfaga la tarea
Un recurso compartido SMB actual al que se llega por un nombre DNS aprobado y una ruta UNC explícita no necesita una extensión de Ethernet. La tarea del servicio de archivos y la experiencia de exploración son requisitos distintos, y solo el segundo depende de la lista de vecinos. Llegar al recurso por su nombre resuelve la tarea sin estirar el dominio de difusión a través de un túnel.
La exploración es la parte que suele fallar, y falla en silencio. Una máquina puede abrir un recurso por ruta mientras la lista de equipos cercanos sigue vacía, porque la lista se llena con el descubrimiento por difusión y la ruta usa DNS. Decidir que necesita la lista es un requisito distinto de decidir que necesita el archivo. Anote cuál de los dos pidió realmente el usuario antes de diseñar nada.
Cuando una aplicación heredada requiere de verdad difusión o tramas que no son IP, evalúe un servicio de capa 2 delimitado con un propietario con nombre, o sustituya la aplicación. Un puente amplía el dominio de fallo compartido y la frontera de políticas, y eso es una decisión de arquitectura, no una casilla con la etiqueta NetBIOS. Documente las operaciones concretas que el túnel debe transportar, y un administrador podrá evaluar la petición en lugar de adivinar sobre «toda la red de Windows».