NetBIOS sobre unha VPN: o nome, o datagrama e a sesión son servizos separados
O eslogan sobre os encamiñadores é demasiado amplo. Comprobe cal dos tres servizos usa a súa aplicación e se resolve nomes por difusión ou mediante un servidor.
«NetBIOS non cruza encamiñadores» repítese coma se iso resolvese o deseño. Non o fai. Unha consulta de nome por difusión adoita quedarse dentro do seu propio dominio de difusión, pero os servizos NetBIOS tamén poden usar tráfico IP dirixido que se encamiña perfectamente ben. A pregunta útil non é se NetBIOS cruza encamiñadores; é cal dos seus tres servizos usa a súa aplicación.
Unha interface de software, non un único protocolo de cable
A RFC 1001 describe NetBIOS como unha interface contra a que programan as aplicacións, con varios transportes debaixo. O seu modelo TCP/UDP separa o servizo de nomes, a distribución de datagramas e o servizo de sesión, e admite explicitamente o funcionamento con difusión IP ou sen ela.
| 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 táboa é a razón pola que o eslogan falla. Un servizo de sesión entre dous hosts nomeados é unha conversa IP; un datagrama de difusión non o é. Un deseño de VPN pode satisfacer o primeiro e non o segundo, e unha proba que demostra o primeiro non di nada sobre o segundo.
Os tipos de nodo deciden que pide o cliente
Os modelos de nodo de difusión, punto a punto e mixto da RFC 1001 describen como un host resolve nomes: preguntando á rede local, preguntando directamente a un servidor de nomes ou probando un e logo o outro. O modelo afecta que tráfico se debe permitir, non se a aplicación funciona ou non.
Unha disposición xestionada con servidor de nomes dá aos clientes un camiño punto a punto, pero só aos clientes configurados para usalo. Poñer un servidor nalgún lugar da rede non fai que unha aplicación o consulte, e un cliente que se deixa en modo difusión seguirá preguntando ao segmento local e esgotará o tempo de espera. O enderezo do servidor ten que chegar á configuración do cliente, polo camiño de xestión que ese cliente respecte.
Así que anote tres observacións para a aplicación en cuestión: como converte o nome do servidor nun enderezo, se o descubrimento ou a mensaxería usa difusión ou un extremo dirixido, e que enderezo e transporte usa a sesión real. Son feitos independentes e cada un ten a súa propia solución. Un só éxito de resolución de nomes é evidencia só sobre o primeiro.
NetBIOS sobre TCP/IP non é NetBEUI
Os dous confúndense porque a ambos se lles chama antigos. NetBIOS sobre TCP/IP leva os seus servizos dentro de paquetes IP, que un túnel encamiñado xa transporta. NetBEUI é un protocolo de capa 2 que non se pode encamiñar, e un túnel IP non transporta tramas Ethernet arbitrarias só porque transporte IP.
Engadir unha ruta IP non pode converter unha trama que non é IP nunha aplicación IP. Se unha aplicación depende de verdade do comportamento da capa 2, as opcións son un servizo de capa 2 explicitamente delimitado ou substituír a aplicación; ningún cambio de encamiñamento substitúe ningunha das dúas.
Escolla o cambio máis pequeno que satisfaga a tarefa
Un recurso compartido SMB actual ao que se chega por un nome DNS aprobado e unha ruta UNC explícita non necesita unha extensión de Ethernet. A tarefa do servizo de ficheiros e a experiencia de navegación son requisitos distintos, e só o segundo depende da lista de veciños. Chegar ao recurso polo nome resolve a tarefa sen estirar o dominio de difusión a través dun túnel.
A navegación é a parte que adoita fallar, e falla en silencio. Unha máquina pode abrir un recurso por ruta mentres a lista de equipos próximos segue baleira, porque a lista énchese co descubrimento por difusión e a ruta usa DNS. Decidir que necesita a lista é un requisito distinto de decidir que necesita o ficheiro. Anote cal dos dous pediu realmente o usuario antes de deseñar nada.
Cando unha aplicación antiga require de verdade difusión ou tramas que non son IP, avalíe un servizo de capa 2 delimitado cun propietario nomeado, ou substitúa a aplicación. Unha ponte amplía o dominio de fallo compartido e a fronteira de políticas, e iso é unha decisión de arquitectura, non unha casilla coa etiqueta NetBIOS. Documente as operacións concretas que o túnel debe transportar, e un administrador poderá avaliar a petición en lugar de adiviñar «toda a rede de Windows».