NetBIOS printr-o VPN: numele, datagrama și sesiunea sunt servicii separate
Sloganul despre routere este prea larg. Verificați care dintre cele trei servicii le folosește aplicația dumneavoastră și dacă rezolvă numele prin difuzie sau printr-un server.
«NetBIOS nu traversează routerele» se repetă ca și cum asta ar fi rezolvat proiectarea. Nu a rezolvat. Căutarea unui nume prin difuzie rămâne de obicei în propriul domeniu de difuzie, dar serviciile NetBIOS pot folosi și trafic IP direcționat care se rutează foarte bine. Întrebarea utilă nu este dacă NetBIOS traversează routerele; este care dintre cele trei servicii ale sale este folosit de aplicația dumneavoastră.
O interfață software, nu un singur protocol de cablu
RFC 1001 descrie NetBIOS ca o interfață față de care programează aplicațiile, cu mai multe transporturi dedesubt. Modelul său TCP/UDP separă serviciul de nume, distribuirea datagramelor și serviciul de sesiune, și susține explicit funcționarea cu sau fără difuzie 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 |
Acest tabel este motivul pentru care sloganul eșuează. Un serviciu de sesiune între două gazde numite este o conversație IP; o datagramă de difuzie nu este. Un singur proiect de VPN poate îndeplini primul și nu al doilea, iar un test care dovedește primul nu spune nimic despre al doilea.
Tipurile de nod decid ce cere clientul
Modelele de nod difuzie, punct-la-punct și mixt din RFC 1001 descriu cum rezolvă o gazdă numele: întrebând rețeaua locală, întrebând direct un server de nume sau încercând unul și apoi pe celălalt. Modelul influențează ce trafic trebuie permis, nu dacă aplicația funcționează deloc.
O configurare administrată cu server de nume le dă clienților o cale punct-la-punct, dar numai clienților configurați să o folosească. Plasarea unui server undeva în rețea nu face o aplicație să îl consulte, iar un client lăsat în modul difuzie va continua să întrebe segmentul local și va ajunge la expirarea timpului. Adresa serverului trebuie să ajungă în configurația clientului, prin orice cale de administrare pe care acel client o respectă.
Așadar notați trei observații pentru aplicația în cauză: cum transformă numele serverului într-o adresă, dacă descoperirea sau mesageria folosesc difuzia ori un punct final direcționat, și ce adresă și transport folosește sesiunea reală. Sunt fapte independente, iar fiecare are propria soluție. Un singur succes de rezolvare a numelui este dovadă doar despre primul.
NetBIOS prin TCP/IP nu este NetBEUI
Cele două sunt confundate pentru că ambele sunt numite vechi. NetBIOS prin TCP/IP își poartă serviciile în pachete IP, pe care un tunel rutat le transportă deja. NetBEUI este un protocol de nivel 2 care nu poate fi rutat, iar un tunel IP nu transportă cadre Ethernet arbitrare doar pentru că transportă IP.
Adăugarea unei rute IP nu poate transforma un cadru non-IP într-o aplicație IP. Dacă o aplicație depinde într-adevăr de comportamentul nivelului 2, opțiunile sunt un serviciu de nivel 2 delimitat explicit sau înlocuirea aplicației; nicio schimbare de rutare nu înlocuiește niciuna dintre ele.
Alegeți cea mai mică schimbare care satisface sarcina
O partajare SMB existentă, accesată printr-un nume DNS aprobat și o cale UNC explicită, nu are nevoie de o extensie Ethernet. Sarcina serviciului de fișiere și experiența de răsfoire sunt cerințe diferite, iar doar a doua depinde de lista vecinilor. A ajunge la partajare după nume rezolvă sarcina fără a întinde domeniul de difuzie printr-un tunel.
Răsfoirea este partea care de obicei eșuează, și eșuează în tăcere. O mașină poate deschide o partajare pe cale în timp ce lista calculatoarelor din apropiere rămâne goală, pentru că lista este populată de descoperirea prin difuzie, iar calea folosește DNS. A decide că aveți nevoie de listă este o cerință diferită de a decide că aveți nevoie de fișier. Notați pe care dintre ele a cerut-o efectiv utilizatorul înainte de a proiecta ceva.
Când o aplicație veche chiar cere difuzie sau cadre non-IP, evaluați un serviciu de nivel 2 delimitat, cu un proprietar numit, sau înlocuiți aplicația. Un pod lărgește domeniul comun de eșec și granița de politică, iar aceasta este o decizie de arhitectură, nu o casetă cu eticheta NetBIOS. Documentați operațiile concrete pe care tunelul trebuie să le transporte, iar un administrator va putea evalua cererea în loc să ghicească despre «întreaga rețea Windows».