NetBIOS per VPN: el nom, el datagrama i la sessió són serveis separats
L’eslògan sobre els encaminadors és massa ampli. Comproveu quin dels tres serveis fa servir la vostra aplicació i si resol els noms per difusió o per un servidor.
«NetBIOS no travessa els encaminadors» es repeteix com si això hagués resolt el disseny. No ho ha fet. Una consulta de nom per difusió sol quedar-se dins del seu domini de difusió, però els serveis NetBIOS també poden fer servir trànsit IP dirigit que s’encamina perfectament bé. La pregunta útil no és si NetBIOS travessa els encaminadors; és quin dels seus tres serveis fa servir la vostra aplicació.
Una interfície de programari, no un sol protocol de cable
L’RFC 1001 descriu NetBIOS com una interfície contra la qual les aplicacions programen, amb diversos transports a sota. El seu model TCP/UDP separa el servei de noms, la distribució de datagrames i el servei de sessió, i admet explícitament el funcionament amb difusió IP o sense.
| 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 |
Aquesta taula és la raó per la qual l’eslògan falla. Un servei de sessió entre dos amfitrions nomenats és una conversa IP; un datagrama de difusió no ho és. Un disseny de VPN pot satisfer el primer i no el segon, i una prova que demostra el primer no diu res sobre el segon.
Els tipus de node decideixen què demana el client
Els models de node de l’RFC 1001 —difusió, punt a punt i mixt— descriuen com un amfitrió resol noms: preguntant a la xarxa local, preguntant directament a un servidor de noms o provant-ne un i després l’altre. El model afecta quin trànsit cal permetre, no si l’aplicació funciona o no.
Una disposició gestionada amb servidor de noms dóna als clients un camí punt a punt, però només als clients configurats per fer-lo servir. Posar un servidor en algun lloc de la xarxa no fa que una aplicació el consulti, i un client que es deixa en mode de difusió continuarà preguntant al segment local i esgotarà el temps d’espera. L’adreça del servidor ha d’arribar a la configuració del client, pel camí de gestió que aquell client respecti.
Per tant, anoteu tres observacions per a l’aplicació en qüestió: com converteix el nom del servidor en una adreça, si el descobriment o la missatgeria fa servir difusió o un extrem dirigit, i quina adreça i quin transport fa servir la sessió real. Són fets independents i cadascun té la seva solució. Un sol èxit de resolució de nom només és evidència del primer.
NetBIOS sobre TCP/IP no és NetBEUI
Els dos es confonen perquè tots dos es qualifiquen d’antics. NetBIOS sobre TCP/IP porta els seus serveis dins de paquets IP, que un túnel encaminat ja transporta. NetBEUI és un protocol de capa 2 que no es pot encaminar, i un túnel IP no transporta trames Ethernet arbitràries només perquè transporta IP.
Afegir una ruta IP no pot convertir una trama que no és IP en una aplicació IP. Si una aplicació depèn de debò del comportament de la capa 2, les opcions són un servei de capa 2 explícitament delimitat o substituir l’aplicació; no hi ha cap canvi d’encaminament que substitueixi cap de les dues.
Trieu el canvi més petit que satisfaci la tasca
Un recurs compartit SMB actual al qual s’arriba per un nom DNS aprovat i un camí UNC explícit no necessita cap extensió Ethernet. La tasca del servei de fitxers i l’experiència de navegació són requisits diferents, i només el segon depèn de la llista de veïns. Arribar al recurs pel nom resol la tasca sense estirar el domini de difusió a través d’un túnel.
La navegació és la part que sol fallar, i falla en silenci. Una màquina pot obrir un recurs per camí mentre la llista d’ordinadors propers queda buida, perquè la llista s’omple amb el descobriment per difusió i el camí fa servir DNS. Decidir que necessiteu la llista és un requisit diferent de decidir que necessiteu el fitxer. Anoteu quin dels dos ha demanat realment l’usuari abans de dissenyar res.
Quan una aplicació antiga requereix de debò difusió o trames que no són IP, avalueu un servei de capa 2 delimitat amb un propietari nomenat, o substituïu l’aplicació. Un pont amplia el domini de fallada compartit i la frontera de política, cosa que és una decisió d’arquitectura i no una casella amb l’etiqueta NetBIOS. Documenteu les operacions concretes que el túnel ha de transportar, i un administrador podrà avaluar la petició en lloc d’endevinar «tota la xarxa de Windows».