NetBIOS oor ’n VPN: naam, datagram en sessie is afsonderlik

“NetBIOS steek nie routers oor nie” word herhaal asof dit die ontwerp beslis het. Dit doen nie. ’n Uitsending-naamsoektog bly gewoonlik binne sy uitsendingsdomein, maar NetBIOS-dienste kan ook gerigte IP-verkeer gebruik wat heeltemal goed gerouteer word. Die nuttige vraag is nie of NetBIOS routers oorsteek nie; dit is watter van sy drie dienste jou toepassing gebruik.

’n Sagteware-koppelvlak, nie een draadprotokol nie

RFC 1001 beskryf NetBIOS as ’n koppelvlak waarteen toepassings programmeer, met verskeie vervoerlaagte daaronder. Sy TCP/UDP-model skei naamdiens, datagramverspreiding en sessiediens, en dit ondersteun uitdruklik werking met of sonder IP-uitsending.

Daardie tabel is die rede waarom die slagspreuk misluk. ’n Sessiediens tussen twee benoemde gashere is ’n IP-gesprek; ’n uitsendingsdatagram is nie. Een VPN-ontwerp kan die eerste bevredig en nie die tweede nie, en ’n toets wat die eerste bewys, sê niks oor die tweede nie.

Nodtipes bepaal waarvoor die kliënt vra

RFC 1001 se uitsending-, punt-tot-punt- en gemengde nodusmodelle beskryf hoe ’n gasheer name oplos: deur die plaaslike netwerk te vra, deur ’n naamdiener direk te vra, of deur een te probeer en dan die ander. Die model beïnvloed watter verkeer toegelaat moet word, nie of die toepassing hoegenaamd werk nie.

’n Bestuurde naamdiener-reëling gee kliënte ’n punt-tot-punt-pad, maar net vir kliënte wat gekonfigureer is om dit te gebruik. Om ’n bediener ergens op die netwerk te plaas, maak nie dat ’n toepassing dit raadpleeg nie, en ’n kliënt wat in uitsendingsmodus gelaat word, sal aanhou om die plaaslike segment te vra en uit te vaar. Die bediener se adres moet die kliënt se konfigurasie bereik, deur watter bestuurspad daardie kliënt ook al eerbiedig.

Teken dus drie waarnemings aan vir die betrokke toepassing: hoe dit die bedienernaam in ’n adres omskakel, of ontdekking of boodskappe uitsending of ’n gerigte eindpunt gebruik, en watter adres en vervoer die werklike sessie gebruik. Dit is onafhanklike feite, en elkeen het sy eie regstelling. ’n Enkele suksesvolle naamoplossing is net bewyse oor die eerste.

NetBIOS oor TCP/IP is nie NetBEUI nie

Die twee word verwar omdat albei oud heet. NetBIOS oor TCP/IP dra sy dienste binne IP-pakkies, wat ’n gerouteerde tonnel reeds vervoer. NetBEUI is ’n nie-routeerbare laag-2-protokol, en ’n IP-tonnel dra nie willekeurige Ethernet-rame net omdat dit IP dra nie.

Om ’n IP-roete by te voeg, kan nie ’n nie-IP-raam in ’n IP-toepassing omskep nie. As ’n toepassing werklik van laag-2-gedrag afhanklik is, is die opsies ’n uitdruklik begrensde laag-2-diens of die vervanging van die toepassing; daar is geen roeteverandering wat vir een van die twee in die plek tree nie.

Kies die kleinste verandering wat die taak bevredig

’n Bestaande SMB-aandeel wat deur ’n goedgekeurde DNS-naam en ’n eksplisiete UNC-pad bereik word, het nie ’n Ethernet-uitbreiding nodig nie. Die lêerdiens-taak en die blaai-ervaring is verskillende vereistes, en net die tweede hang van die buurlys af. Om die aandeel by die naam te bereik, los die taak op sonder om die uitsendingsdomein oor ’n tonnel te rek.

Blaai is die deel wat gewoonlik misluk, en dit misluk stil. ’n Masjien kan ’n aandeel per pad oopmaak terwyl die nabye-rekenaarlys leeg bly, want die lys word deur uitsendingsontdekking gevul en die pad gebruik DNS. Om te besluit dat jy die lys nodig het, is ’n ander vereiste as om te besluit dat jy die lêer nodig het. Skryf neer vir watter een die gebruiker werklik gevra het voordat jy enigiets ontwerp.

Wanneer ’n ou toepassing werklik uitsending of nie-IP-rame vereis, oorweeg ’n begrensde laag-2-diens met ’n benoemde eienaar, of vervang die toepassing. ’n Brug vergroot die gedeelde foutdomein en die beleidsgrens, wat ’n argitektoniese besluit is eerder as ’n merkie met die naam NetBIOS. Dokumenteer die spesifieke bewerkings wat die tonnel moet dra, en ’n administrateur kan die versoek evalueer in plaas daarvan om te raai na “alle Windows-netwerking”.