NetBIOS over ein VPN: namn, datagram og økt er skilde tenester

«NetBIOS kryssar ikkje ruterar» blir gjenteke som om det avgjorde designet. Det gjer det ikkje. Eit namneoppslag via kringkasting held seg vanlegvis innanfor sitt eige kringkastingsdomene, men NetBIOS-tenester kan òg bruke retta IP-trafikk som blir ruta heilt fint. Det nyttige spørsmålet er ikkje om NetBIOS kryssar ruterar; det er kva av dei tre tenestene programmet ditt brukar.

Eit programvaregrensesnitt, ikkje éin leidningsprotokoll

RFC 1001 skildrar NetBIOS som eit grensesnitt som program programmerer mot, med fleire transportlag under. TCP/UDP-modellen skil namnetenesta, datagramfordelinga og øktttenesta, og han støttar uttrykkeleg drift med eller utan IP-kringkasting.

Det er denne tabellen som gjer at slagordet fell. Ei økttteneste mellom to namngjevne vertar er ein IP-samtale; eit kringkastingsdatagram er det ikkje. Eitt VPN-design kan oppfylle det fyrste og ikkje det andre, og ein test som provar det fyrste, seier ingenting om det andre.

Nodetypar avgjer kva klienten spør om

Kringkastings-, punkt-til-punkt- og blanda nodemodellar i RFC 1001 skildrar korleis ein vert løyser namn: ved å spørje det lokale nettet, ved å spørje ein namnetenar direkte, eller ved å prøve den eine og så den andre. Modellen påverkar kva trafikk som må tillatast, ikkje om programmet verkar i det heile.

Ei styrt namnetenarordning gjev klientane ein punkt-til-punkt-veg, men berre til klientar som er konfigurerte til å bruke han. Å setje ein tenar ein stad på nettet får ikkje eit program til å spørje han, og ein klient som blir ståande i kringkastingsmodus, vil halde fram med å spørje det lokale segmentet og gå til tidsavbrot. Adressa til tenaren må nå konfigurasjonen til klienten, gjennom den styringsvegen klienten respekterer.

Noter difor tre observasjonar for det aktuelle programmet: korleis det gjer tenarnamnet om til ei adresse, om oppdaging eller meldingar brukar kringkasting eller eit retta endepunkt, og kva adresse og transport den faktiske økta brukar. Dette er uavhengige fakta, og kvar har si eiga løysing. Éi vellukka namneløysing er berre prov for det fyrste.

NetBIOS over TCP/IP er ikkje NetBEUI

Dei to blir forveksla fordi begge blir kalla gamle. NetBIOS over TCP/IP ber tenestene sine inne i IP-pakkar, som ein ruta tunnel allereie transporterer. NetBEUI er ein ikkje-rutbar protokoll på lag 2, og ein IP-tunnel ber ikkje vilkårlege Ethernet-rammer berre fordi han ber IP.

Å leggje til ei IP-rute kan ikkje gjere ei ikkje-IP-ramme om til eit IP-program. Viss eit program verkeleg er avhengig av åtferd på lag 2, er vala ein uttrykkeleg avgrensa teneste på lag 2 eller å byte ut programmet; inga ruteendring erstattar nokon av dei.

Vel den minste endringa som oppfyller oppgåva

Ei eksisterande SMB-deling som ein når via eit godkjent DNS-namn og ein eksplisitt UNC-veg, treng inga Ethernet-utviding. Filoppgåva og nettlesaropplevinga er ulike krav, og berre det andre er avhengig av nabolista. Å nå delinga ved namn løyser oppgåva utan å strekkje kringkastingsdomenet gjennom ein tunnel.

Det er nettlesinga som vanlegvis fell, og ho fell stille. Ein maskin kan opne ei deling via veg medan lista over nærliggande datamaskinar blir ståande tom, fordi lista blir fylt av kringkastingsoppdaging og vegen brukar DNS. Å avgjere at du treng lista, er eit anna krav enn å avgjere at du treng fila. Skriv ned kva av dei brukaren faktisk bad om, før du designar noko.

Når eit gammalt program verkeleg krev kringkasting eller ikkje-IP-rammer, vurder ein avgrensa teneste på lag 2 med ein namngjeven eigar, eller byt ut programmet. Ei bru utvidar det felles feildomenet og policygrensa, og det er ei arkitekturavgjerd, ikkje ein avkrysningsboks merkt NetBIOS. Dokumenter dei konkrete operasjonane tunnelen må bere, så kan ein administrator vurdere førespurnaden i staden for å gjette på «heile Windows-nettverket».