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