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».