Автор – Maxim Berlin.
Оригинал статьи – WINS на практике от 31.01.2000.
Все права на статью принадлежат автору, публикуется по личному разрешению автора с несущественными форматирующими изменениями.
При перепечатке обязательно указание прямой активной ссылки на оригинал статьи.

Net BIOS, WINS и Browsing lists

Терминология:

Net BIOS – Network Basic Input Output System

1.1 Net BIOS – это session-level интерфейс². Используется программами для общения over Net BIOS совместимых транспортных протоколов. Транспортные протоколы – это Net BEUI, TCP/IP, IPX/SPX. Cеть Windows не живет без Net BIOS. Никогда. Ни при каких условиях. Даже под угрозой расстрела. Неважно, что там у вас написано в свойствах сетевого окружения – если есть это самое окружение, значит есть и Net BIOS. Он отвечает за логические имена компьютеров на сети и передачу данных между двумя компьютерами, установившими между собой сессию.
Net BIOS over TCP/IP называется Net BT.

1.2 Net BIOS names
Net BIOS name закрепляется за ресурсом – не за компьютером! – только за ресурсом, имеет размер в 16 байт. Первые 15 – собственно имя, 16-й – тип ресурса, (00-FF hex), типы стандартизованы.
Имена делятся на:
Unique (U)- к этому имени может быть привязан только один адрес.
Group (G) – к этому имени не привязан адрес; На запрос WINS клиента об адресе всегда возвращается limited broadcast address.
Multihomed (M) – не описан в rfc 1001/1002; к этому имени может быть привязано до 25 адресов; TTL общий для всех..
Internet Group (Special Group) (I) – к этому имени может быть привязано до 25 адресов; для каждого адреса хранится свой TTL.
Domain Name (D) – про него сказано коротко: "New in Windows NT 4.0."

1.3. Name Resolution
Name Resolution в Net BIOS от рождения основано на broadcasts, что сильно осложняет жизнь уже в средних размеров сети – любой свитч³ broadcast'ы через себя не пропускает, и правильно делает⁴. Ранние версии Net BIOS умели пользваться для распознавания имен только

К версии NT 3.5 MS одумался и ввел улучшения. Сейчас Net BIOS умеет пользоваться

• Net BIOS name cache – посмотреть в своем собственном кэше – нет ли там искомого имени; в кэше имена обычно остаются на 10 мин.
• Net BIOS name server – WINS, о котором речь пойдет дальше
• IP subnet broadcasts – громко крикнуть на всю (под)сеть: "А подать сюда Ляпкина-Тяпкина!"
• Static LMHOSTS file, для WINS клиента:

  102.54.94.97      rhino        #PRE #DOM:networking         #net group's DC 102.54.94.102     "RTS        \0x1c"  #special app server
  102.54.94.123     popular    #PRE    #source server
  102.54.94.117     localsrv    #PRE   #needed for the include
  #BEGIN_ALTERNATE
  #INCLUDE \\localsrv\public\lmhosts
  #INCLUDE \\rhino\public\lmhosts
  #END_ALTERNATE 

  
  Директивы (#PRE, #DOM, etc) описаны внутри lmhosts.sam.
  
• Static HOSTS file
• DNS servers

1.4. Что бы хоть как-то управлять этим разнотравьем, вводится понятие Node Type для порядка регистрации и распознавания имен⁵:

Node Type раздаются DHCP сервером либо (surprise, surprise!) выставляются в registry. По умолчанию (при сконфигурированном WINS server'e ) Windows встает в H-node.

WINS

2.1. WINS – Windows Internet Naming Service.
WINS server = Net BIOS Name Server (NBNS), но в MS по традиции (чтоб жизнь медом не казалась) используются оба термина. Для тех, кто знаком с DNS, достаточно сказать что WINS – это такой DNS от Microsoft – для Net BIOS. WINS отвечает за регистрацию Netbios-овских имен и преобразование их в IP адреса. WINS хранит базу данных вот такого вида:

Поля A и S – Active и Static, Version ID – уникальный номер, который используется MS WINS'ом при репликации – для поиска новых записей (репликация – процедура слияния баз нескольких WINS серверов).

WINS – в своей работе использует UDP -137 и 138 порт (и broadcast'ы – если поймает).
На сегодняшний день я знаю два WINS сервера – один из них поставляется с NT server, второй включен в пакет SAMBA. Какой из них использовать – дело вкуса; если хочется [псевдо]спокойной жизни, надо использовать сервер от MS. Упадет NT с WINS сервером – последствия для своего случая прикидывайте сами.

Если доверять продукции MS не хочется, то придется использовать samba, несмотря на ее недостатки. К недостаткам относятся два пункта:

• Нет возможности реплицировать между собой два WINS сервера;
• Честное следование rfc. SAMBA пишется наивными людьми, которые верят, что MS следует своим спецификациям. Понятно же, что там где-то что-то будет сделано хоть чуть-чуть, но не так. Если уж писать WINS сервер под MS, то с отладчиком, дизассемблером и tcpdump'ом в руках. Чтобы аккуратно повторять все ошибки MS (см. Readme к service pack'ам на предмет слова WINS).

2.2. Как работает WINS сервер
Основная задача WINS server'а – уметь отвечать на вопрос – а какой адрес у сервиса "name".
Функции Name Registration, Refresh, and Release: Сервис грузится, шлет на WINS сервер пакет Registration. В ответ получает подтверждение ( различные ошибки и конфликты опускаю ) и время, в течение которого его регистрация действительна – TTL Time To Live. Согласно описанию от MS через TTL/2 NT⁷ (остальные клиенты могут делать refresh с другой частотой, но до истечения TTL) должна прислать Refresh – мол вот она я, жива. И снова получить TTL. И так до окончания работы, когда сервис должен послать пакет Release. Если TTL истек, а сервис Refresh не прислал, WINS server о нем забывает. MS WINS server умеет реплицировать свою базу с другими MS WINS серверами.

Browsing lists

Итак, с помощью WINS сервера можно получить адрес ресурса по имени "name". Но как увидеть список всех компьютеров в сети/домене/рабочей_группе? WINS на такие вопросы не отвечает – не обучен. Занимаются этим всяческие browser'ы. В каждой подсети есть Master Browser (domain\0x1d), backup browser, potential browser и preferred master browser, их в последнее время называют segment browsers ( изобретенными в MS терминами можно, наверное, библиотеку заполнить ).

Компьютеры, таким образом, разделяются на:

• Non-browser компьютеры
• Potential browsers – может стать backup browser'ом, если понадобится.
• Backup Browser – оперирует Browse lists'ами серверов и доменов, каковые lists получает от Master Browser.
• Master Browser – Получает анонсы от компьютеров и доменов, посылает Browse list Backup Browsers'ам, высылает по запросы клиента Browse list, продвигает Potential в Backup Browser по мере необходимости и общается с Domain Master Browser.
• Preferred Master Browser – то же самое, что и Backup, но выигравший выборы за счет установки в registry флажка IsDomainMasterBrowser ⁸ в True.
• Domain Master Browser – Согласно MS'овской документации функции domain master browser'a всегда выполняет primary domain controller⁹, и лучше бы этому не препятствовать, хотя samba и умеет (domain master = yes).

Неважно, что у вас в подсети/домене/рабочей_группе одна машина – она будет и master, и backup, и potential. На каждые 32 компьютера добавляется еще один backup browser. Master browser'ы занимаются тем, что обрабатывают broadcast'ы, которые раз в time=12 минут выдает каждый компьютер и складывают результаты в browsing lists глубоко внутри себя.

Если компьютер в течении time*3 признаков жизни не подает, master browser удаляет его из browsing list. Итого тайм-аут между выключением компютера и пропаданием его из neighborhood составляет 36 мин. – внутри одного сегмента. Если компьютер выключен "gracefully", browser (имеется в виду сервис computer browser) пошлет master browser'у соответствующее сообщение и будет вычищен из списков сразу.

В дополнение все master browser'ы периодически¹⁰ анонсируют себя принадлежащими к группе __MSBROWSE__¹¹ в локальной подсетке – без использования WINS, broadcast'ом. В анонсе присутствуют имя домена и имя domain master browser'a. Master Browser'ы, получающие такие анонсы, хранят их в internal browse lists¹² вместе с именем компьютера, пославшего анонс.

Backup browser кэширует browsing lists у себя и инициирует перевыборы, если не может найти master browser.

Domain master browser составляет список имен master browser'ов на основании полученных от них Master Announcement frames, которые ему присылают сначала после победы на выборах, а затем каждые 12 (у самбы – 15) минут. На основании этого списка domain master browser раз в 15 минут опрашивает всех master browsers на предмет local browsing lists, соединяет полученное в domain browse list и раздает (по запросу, который раз в 12 минут) master browser'ам. Сами считайте, через сколько минут выключенный компьютер пропадет из browsing lists в остальных сегментах.

Свежезагрузившийся клиент шлет broadcast¹³ на имя domain\0x1d. Master browser возвращает соответствующий список browser'ов, из коего списка клиент выбирает три сервера и, случайным образом из этих троих выбрав одного, шлет запрос. Результат появляется в network neighborhood'e. При обращении к компьютеру, нарисованному в Network Neighborhood идет запрос к WINS серверу о его адресе.

В NT за browser'енье отвечает сервис Computer Browser.

Кусок документации от samba – объяснение на пальцах того, как синхронизируются Browsing lists в подсетях, взято из файла browsing.txt; переводить мне его лень.

Итого, в сегментированной сети с Windows-клиентами без WINS'а Browsing lists не работают. А поскольку слова "сеть работает" проверяются наличием соседских компьютеров в Network Neighborhood, то ...

Multihomed browsers

(Vladimir Pastukhov) Хотелось бы добавить пару слов о multihomed master browsers – у которых более одной сетевой карты.
Собственно, MS их категорически не рекомендует. Дело в том, что NT'шный browser отдает не полный browse list, а только ту его часть, которая относится к подсети откуда пришел запрос (возможно, в действительности значение имеет то, на какой адрес он пришел – негде сейчас проверить). MS объясняет, что, мол, browser знать ничего не знает о роутинге между подсетями, и поэтому отдавать чужую подсеть ему не с руки.
Кое-как это лечится при помощи Q158487 – оставляем компьютер browser'ом только в одном из сегментов. Если бедной кляче к тому же посчастливилось быть PDC, то придется прописать в WINS (или в lmhosts на potential browsers) static mapping типа multihomed для имени domain\0x1b с адресом интерфейса из этого сегмента – это чтобы master browser'ы всегда обращались по правильному адресу.
Самба всегда отдает объединенный browse list, поэтому делать ее master browser'ом бывает очень чисто и сухо.

Комментарий

Материалы для внеклассного чтения от MS: winswp, tcpipimp2.
Предложения, пожелания, bugfixes (к тексту, не к MS) шлите мне – mak at unesco.mitht.rssi.ru.
Maxim Berlin, 31.01.2000.

Выношу благодарности за помощь в работе над этим материалом:
Александру Калагову (ТЦ РТС),
Игорю Нестерову (ТЦ РТС),
Владимиру Чухареву,
Vladimir Pastukhov,
Sergei V. Dubrov.

Возникшие вопросы:
Дмитрий Шеремет: Как задать адрес, на котором WINS сервер будет принимать пакеты?

Владимир Чухарев: Кто будет исполнять функции Domain master browser'а, если на сети нет Primary/Backup domain controller'а?

¹ За счет пункта a) Net BEUI остается самым быстрым и маленьким сетевым протоколом

² Net BIOS изначально находился в ROMе сетевых карт для писюковой сетки от IBM.

³ Меня поправляет Sergei V. Dubrov:

1. Не путай роутер и свитч. Далеко не всякий свитч режет броадкасты.
2. Обычным свитчом я называю железяку, работающую только на уровне MAC-адресов, т.е., также, как и старые добрые бриджи. Классические, первые свитчи – это просто многопортовые буферированные бриджи, они пересылают пакеты из-в сегмента в сегмент только на основании MAC-адреса фрейма (Ethernet, FDDI, и пр.). Они ничего не знают про .255 бродкаст (IP-level) – для них это такой же пакет, как и остальные. Если чуть вдаться в подробности, даже классический свитч, работающий на втором уровне, но имеющий достаточно мозгов внутри, может в принципе иметь возможность строить фильтры по различным полям принимаемых-передаваемых фреймов, т.е., его можно научить, например, зная структуру IP-пакета, упакованного в Ethernet-фрейм, откидывать бродкасты сетевого уровня. Из примеров таких железок – LanPlex2500 (сейчас – CorePlex2500) от 3Com. Новые, современные и достаточно навороченные свитчи уже обычно могут работать с третьим уровнем – сетевым (те же VLAN-ы), вот на них уже действительно можно без приседаний в виде писания фильтров на птичьем языке машины а-ля Тьюринг работать с пакетами на уровне IP или IPX, например, в т.ч. устраивая no passaran для IP-бродкастов ;-). Хотя, с другой стороны, и сейчас выпускается масса дешевых свитчей фирмами типа D-Link, SMC и т.п., которые про сетевой уровень (и про VLAN-ы) ничего знать не знают.
   Про канальный, сетевой и прочие уровни можно прочитать здесь: Протокол, интерфейс, стек протоколов. Модель ISO/OSI.

⁴ Документация от MS всегда ставит проблему злобных роутеров на первое место. Роутеры, мол, не пропускают броадкасты. Вторым пунктом упоминают, что броадкаст должен быть обработан каждой машиной, имевшей счастье его словить, за что его роутеры и не пускают...

⁵ Я видел упоминание о "Microsoft-enhanced – Local LMHOSTS file or WINS proxies plus Windows Sockets gethostbyname() calls (using standard DNS and/or local HOSTS files) in addition to standard node types.", но живьем ее никогда не видел.

⁶ Владимир Чухарев:

⁷ NT далеко не всегда использует TTL/2.

⁸ Vladimir Pastukhov:

⁹ В его registry есть некий(не уточняется) ключ, который помогает ему выиграть на выборах титул Domain Master Browser'а. "This allows browsing to be effective when a domain spans multiple subnets." Не спрашивайте, чем оно будет эффективнее – не скажу. Не знаю.

¹⁰ Написано – "periodically". Подозреваю, что либо раз в 12, либо раз в 15 минут.

¹¹ WINS server на запрос о таком имени всегда возвращает broadcast адрес соответствующей сети

¹² Понятия не имею, что это такое. Нашел только одно упоминание:": In addition, master browser servers receive these domain announcements to this name and maintain them in their internal browse list along with the announcer's computer name."

¹³ "A client will broadcast to this name to get a list of browser servers from the Master Browser." Возможно, имелся в виду multicast...

¹⁴ Или запретив в registry. Чревато. Установка Option pack для NT server с выключенным computer browser оканчивается (не начавшись) сообщением "Cannot detect OS type".

Редактирование этой страницы отключено. Обменяться мнениями приглашаю на форуме. Учтите дату написания, статья хоть и старая, но актуальности не потеряла поскольку в механизме Net BIOS ничего принципиально нового с тех пор не изобретено.
Abram4 /25.10.2008 19:51/