NetBIOS през VPN: името, датаграмата и сесията са отделни услуги

«NetBIOS не минава през рутери» се повтаря така, сякаш това решава проекта. Не го решава. Търсенето на име чрез широко излъчване обикновено остава в собствения си домейн на излъчване, но услугите на NetBIOS могат да ползват и насочен IP трафик, който се маршрутизира напълно нормално. Полезният въпрос не е дали NetBIOS минава през рутери; а коя от трите му услуги ползва приложението ви.

Софтуерен интерфейс, а не един протокол по кабела

RFC 1001 описва NetBIOS като интерфейс, срещу който приложенията се програмират, с няколко транспорта отдолу. Моделът му TCP/UDP разделя услугата за имена, разпространението на датаграми и сесийната услуга и изрично поддържа работа със или без IP широко излъчване.

Тази таблица е причината лозунгът да се проваля. Сесийната услуга между два именувани хоста е IP разговор; датаграмата по широко излъчване не е. Един проект на VPN може да осигури първото и да не осигури второто, а тест, който доказва първото, не казва нищо за второто.

Типовете възли решават какво иска клиентът

Моделите на възлите в RFC 1001 — широко излъчване, точка до точка и смесен — описват как хостът решава имена: като пита локалната мрежа, като пита сървър за имена директно или като опита едното, а после другото. Моделът влияе на това какъв трафик трябва да се разреши, а не на това дали приложението работи изобщо.

Управлявана схема със сървър за имена дава на клиентите път точка до точка, но само на клиентите, конфигурирани да го ползват. Поставянето на сървър някъде в мрежата не кара приложението да се допитва до него, а клиент, оставен в режим на широко излъчване, ще продължи да пита локалния сегмент и да изчаква до изтичане на времето. Адресът на сървъра трябва да стигне до конфигурацията на клиента — по пътя за управление, който този клиент уважава.

Затова запишете три наблюдения за въпросното приложение: как превръща името на сървъра в адрес, дали откриването или съобщенията ползват широко излъчване или насочена крайна точка и какъв адрес и транспорт ползва самата сесия. Това са независими факти и всеки има свое решение. Едно успешно решаване на име е доказателство само за първото.

NetBIOS през TCP/IP не е NetBEUI

Двете се бъркат, защото и двете се наричат остарели. NetBIOS през TCP/IP носи услугите си в IP пакети, които маршрутизиран тунел и без това пренася. NetBEUI е немаршрутизируем протокол от ниво 2 и IP тунел не пренася произволни Ethernet кадри само защото пренася IP.

Добавянето на IP маршрут не може да превърне не-IP кадър в IP приложение. Ако приложението наистина зависи от поведение на ниво 2, вариантите са изрично ограничена услуга на ниво 2 или подмяна на приложението; няма промяна в маршрутизацията, която да замести едното от двете.

Изберете най-малката промяна, която изпълнява задачата

Съществуващ SMB дял, до който се стига с одобрено DNS име и явен UNC път, не се нуждае от разширение на Ethernet. Задачата за файлова услуга и изживяването при разглеждане са различни изисквания и само второто зависи от списъка на съседите. Достигането до дела по име решава задачата, без да разпъва домейна на излъчване през тунел.

Разглеждането е частта, която обикновено се чупи, и се чупи тихо. Машина може да отвори дял по път, докато списъкът с близки компютри остава празен, защото списъкът се пълни от откриване чрез широко излъчване, а пътят ползва DNS. Решението, че ви трябва списъкът, е различно изискване от решението, че ви трябва файлът. Запишете кое точно е поискал потребителят, преди да проектирате каквото и да е.

Когато остаряло приложение наистина изисква широко излъчване или не-IP кадри, преценете ограничена услуга на ниво 2 с посочен собственик или сменете приложението. Мостът разширява общия домейн на отказ и границата на политиките, а това е архитектурно решение, не отметка с надпис NetBIOS. Документирайте конкретните операции, които тунелът трябва да носи, и администраторът ще може да оцени заявката, вместо да гадае за «цялата мрежа на Windows».