NetBIOS sobre uma VPN: nome, datagrama e sessão são serviços separados
O slogan sobre routers é demasiado amplo. Verifique qual dos três serviços a sua aplicação usa e se resolve nomes por difusão ou através de um servidor.
«O NetBIOS não atravessa routers» repete-se como se isso resolvesse o projeto. Não resolve. Uma pesquisa de nome por difusão costuma ficar dentro do seu próprio domínio de difusão, mas os serviços NetBIOS também podem usar tráfego IP dirigido que é encaminhado perfeitamente bem. A pergunta útil não é se o NetBIOS atravessa routers; é qual dos seus três serviços a sua aplicação usa.
Uma interface de software, não um único protocolo de cabo
A RFC 1001 descreve o NetBIOS como uma interface contra a qual as aplicações programam, com vários transportes por baixo. O seu modelo TCP/UDP separa o serviço de nomes, a distribuição de datagramas e o serviço de sessão, e suporta explicitamente o funcionamento com ou sem difusão IP.
| 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 |
É essa tabela que faz o slogan falhar. Um serviço de sessão entre dois anfitriões nomeados é uma conversa IP; um datagrama de difusão não é. Um projeto de VPN pode satisfazer o primeiro e não o segundo, e um teste que prova o primeiro não diz nada sobre o segundo.
Os tipos de nó decidem o que o cliente pede
Os modelos de nó de difusão, ponto a ponto e misto da RFC 1001 descrevem como um anfitrião resolve nomes: perguntando à rede local, perguntando diretamente a um servidor de nomes ou experimentando um e depois o outro. O modelo afeta que tráfego deve ser permitido, não se a aplicação funciona de todo.
Uma disposição gerida com servidor de nomes dá aos clientes um caminho ponto a ponto, mas apenas aos clientes configurados para o usar. Colocar um servidor em qualquer ponto da rede não faz com que uma aplicação o consulte, e um cliente deixado em modo de difusão continuará a perguntar ao segmento local e acabará em tempo esgotado. O endereço do servidor tem de chegar à configuração do cliente, pelo caminho de gestão que esse cliente respeitar.
Por isso, registe três observações para a aplicação em causa: como converte o nome do servidor num endereço, se a descoberta ou as mensagens usam difusão ou um ponto final dirigido, e que endereço e transporte a sessão real usa. São factos independentes, e cada um tem a sua própria correção. Um único sucesso de resolução de nome é evidência apenas sobre o primeiro.
NetBIOS sobre TCP/IP não é NetBEUI
Os dois são confundidos porque ambos são chamados antigos. O NetBIOS sobre TCP/IP transporta os seus serviços dentro de pacotes IP, que um túnel encaminhado já transporta. O NetBEUI é um protocolo de camada 2 não encaminhável, e um túnel IP não transporta tramas Ethernet arbitrárias só porque transporta IP.
Acrescentar uma rota IP não pode converter uma trama não-IP numa aplicação IP. Se uma aplicação depende mesmo do comportamento da camada 2, as opções são um serviço de camada 2 explicitamente delimitado ou substituir a aplicação; nenhuma alteração de encaminhamento substitui qualquer das duas.
Escolha a menor alteração que satisfaz a tarefa
Uma partilha SMB existente alcançada por um nome DNS aprovado e um caminho UNC explícito não precisa de uma extensão Ethernet. A tarefa do serviço de ficheiros e a experiência de navegação são requisitos diferentes, e só a segunda depende da lista de vizinhos. Alcançar a partilha pelo nome resolve a tarefa sem esticar o domínio de difusão através de um túnel.
A navegação é a parte que normalmente falha, e falha em silêncio. Uma máquina pode abrir uma partilha por caminho enquanto a lista de computadores próximos fica vazia, porque a lista é preenchida pela descoberta por difusão e o caminho usa DNS. Decidir que precisa da lista é um requisito diferente de decidir que precisa do ficheiro. Anote qual dos dois o utilizador pediu realmente antes de projetar seja o que for.
Quando uma aplicação antiga exige mesmo difusão ou tramas não-IP, avalie um serviço de camada 2 delimitado com um proprietário nomeado, ou substitua a aplicação. Uma ponte alarga o domínio de falha partilhado e a fronteira de política, e isso é uma decisão de arquitetura, não uma caixa com a etiqueta NetBIOS. Documente as operações concretas que o túnel tem de transportar, e um administrador poderá avaliar o pedido em vez de adivinhar sobre «toda a rede Windows».