NetBIOS super VPN: nomo, datagramo kaj sesio estas apartaj servoj
La slogano pri enkursigiloj estas tro vasta. Kontrolu, kiun el la tri servoj via aplikaĵo uzas, kaj ĉu ĝi solvas nomojn per dissendo aŭ per servilo.
«NetBIOS ne transiras enkursigilojn» ripetiĝas kvazaŭ tio decidus la dezajnon. Ĝi ne decidas. Dissenda nomserĉo kutime restas ene de sia propra dissenda domajno, sed NetBIOS-servoj povas uzi ankaŭ direktitan IP-trafikon, kiu enkursiĝas tute bone. La utila demando ne estas, ĉu NetBIOS transiras enkursigilojn; ĝi estas, kiun el siaj tri servoj via aplikaĵo uzas.
Programa interfaco, ne unu drata protokolo
RFC 1001 priskribas NetBIOS kiel interfacon, kontraŭ kiu aplikoj programiĝas, kun pluraj transportoj sube. Ĝia TCP/UDP-modelo apartigas nomservon, datagraman disdonadon kaj sesian servon, kaj ĝi eksplicite subtenas funkciadon kun aŭ sen IP-dissendo.
| 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 |
Tiu tabelo klarigas, kial la slogano malsukcesas. Sesia servo inter du nomitaj gastigantoj estas IP-interparolo; dissenda datagramo ne estas. Unu VPN-dezajno povas kontentigi la unuan kaj ne la duan, kaj testo, kiu pruvas la unuan, diras nenion pri la dua.
Nodtipoj decidas, kion la kliento petas
La dissendaj, punkt-al-punkta kaj miksitaj nodmodeloj de RFC 1001 priskribas, kiel gastiganto solvas nomojn: per demando al la loka reto, per rekta demando al noma servilo, aŭ per provo de unu kaj poste la alia. La modelo influas, kiun trafikon oni devas permesi, ne ĉu la aplikaĵo entute funkcias.
Administrata nomaservila aranĝo donas al klientoj punkt-al-punktan vojon, sed nur al klientoj agorditaj por uzi ĝin. Meti servilon ie en la reto ne igas aplikaĵon konsulti ĝin, kaj kliento lasita en dissenda reĝimo daŭre demandos la lokan segmenton kaj finiĝos per tempolimo. La adreso de la servilo devas atingi la agordon de la kliento, per kiu ajn administra vojo tiu kliento respektas.
Do notu tri observojn por la koncerna aplikaĵo: kiel ĝi transformas la servilan nomon en adreson, ĉu malkovro aŭ mesaĝado uzas dissendon aŭ direktitan finpunkton, kaj kiun adreson kaj transporton la fakta sesio uzas. Tiuj estas sendependaj faktoj, kaj ĉiu havas sian propran riparon. Unu sukcesa nomsolvo estas pruvo nur pri la unua.
NetBIOS super TCP/IP ne estas NetBEUI
La du konfuziĝas, ĉar ambaŭ nomiĝas malmodernaj. NetBIOS super TCP/IP portas siajn servojn ene de IP-paketoj, kiujn enkursigita tunelo jam transportas. NetBEUI estas neenkursigebla protokolo de tavolo 2, kaj IP-tunelo ne transportas arbitrajn Ethernet-kadrojn nur ĉar ĝi transportas IP.
Aldoni IP-vojon ne povas konverti ne-IP-kadron en IP-aplikaĵon. Se aplikaĵo vere dependas de konduto de tavolo 2, la ebloj estas eksplicite limigita servo de tavolo 2 aŭ anstataŭigo de la aplikaĵo; neniu enkursiga ŝanĝo anstataŭas iun ajn el ili.
Elektu la plej malgrandan ŝanĝon, kiu plenumas la taskon
Ekzistanta SMB-kunhavaĵo atingata per aprobita DNS-nomo kaj eksplicita UNC-vojo ne bezonas Ethernet-etendon. La dosier-serva tasko kaj la retuma sperto estas malsamaj postuloj, kaj nur la dua dependas de la najbara listo. Atingi la kunhavaĵon per nomo solvas la taskon sen streĉi la dissendan domajnon tra tunelo.
Retumado estas la parto, kiu kutime malsukcesas, kaj ĝi malsukcesas silente. Maŝino povas malfermi kunhavaĵon per vojo dum la listo de proksimaj komputiloj restas malplena, ĉar la listo pleniĝas per dissenda malkovro kaj la vojo uzas DNS. Decidi, ke vi bezonas la liston, estas alia postulo ol decidi, ke vi bezonas la dosieron. Notu, kiun el la du la uzanto efektive petis, antaŭ ol vi dezajni ion ajn.
Kiam malmoderna aplikaĵo vere postulas dissendon aŭ ne-IP-kadrojn, pripensu limigitan servon de tavolo 2 kun nomita posedanto, aŭ anstataŭigu la aplikaĵon. Ponto vastigas la komunan fiaskodomajnon kaj la limon de politiko, kaj tio estas arkitektura decido, ne markobutono nomita NetBIOS. Dokumentu la konkretajn operaciojn, kiujn la tunelo devas transporti, kaj administranto povos taksi la peton anstataŭ diveni pri «la tuta Windows-retaro».