NetBIOS через TCP/IP

Метки:  , , , , , , , , , , , ,

NetBIOS (Network Basic Input/Output System, Сетевая Базовая Система Ввода/Вывода) - это интерфейс для работы в локальных сетях, разработанный фирмой Sytek для компании IBM в 1983 году. Как гласит RFC1001: "NetBIOS defines a software interface, not a protocol. There is no "official" NetBIOS service standard". И всё же NetBIOS, по моему скромному мнению, и интерфейс и протокол, поэтому, с вашего позволения, назовем его стандартом (не смотря на то, что официально он так и не был полностью стандартизован). Довольно часто NetBIOS называют сетевым протоколом, но это не совсем корректно, поскольку NetBIOS реализован в Windows в виде отдельного функционала в разных частях ОС - в виде интерфейса в библиотеках пользовательского режима и режима ядра, и в виде модуля в стеке сетевого протокола. Интерфейс NetBIOS представляет из себя стандартный набор для разработки приложений (API), протокол NetBIOS функционирует на транспортном/сеансовом уровне стека и используется для передачи данных, управления сеансом и прочих нужд.

Для чего же в своё время потребовался NetBIOS? Для осуществления возможности взаимодействия станций в небольших сетях. Что включает в себя возможность взаимодействия по сети? Это назначение станции сетевого имени, по которому она будет доступна в сети, это возможность найти станцию в сети по её имени, возможность соединиться с ресурсами станции и начать с обмениваться с ними данными. Это и возможность получить список сетевых станций, которые подключены к сегменту сети и многое многое другое, что определяется термином "сетевое взаимодействие".

Особенностью NetBIOS является возможность работы поверх различных протоколов, таких как IPX, NetBEUI и TCP/IP. В своё время реализация протокола NetBIOS в Windows была существенно переработана и ориентирована на использование протокола TCP/IP (как наиболее перспективного), получив новое название “NetBIOS over TCP/IP” (NetBIOS через TCP/IP). NetBIOS через TCP/IP имеет псевдоним NetBT (NBT). NetBIOS через TCP/IP представляет собой промежуточный уровень между NetBIOS и TCP/IP и создан для того, чтобы приложения на базе NetBIOS могли работать в сетях TCP/IP, то есть предназначен для отображения имен NetBIOS в IP-адреса и, наоборот. Как мы уже упоминали, NetBIOS разрабатывался на заре становления сетевых технологий, и с того времени часто модифицировался, однако параллельно с ним создавались и другие стандарты сетевого взаимодействия, которые существенно опережали NetBIOS по функционалу. На данный момент NetBIOS считается устаревшим стандартом и не рекомендуется к использованию, заместо него Microsoft предлагает использовать windows sockets, mailslots, named pipes.

NetBIOS через TCPIP не поддерживает IPv6. Для целей взаимодействия в локальном сегменте сети без участия опорных серверов (DNS/WINS) с использованием IPv4/IPv6 разработан протокол LLMNR.

Однако, не смотря на устаревание NetBIOS, поддержка его сохранена и по сей день, код NetBIOS через TCP/IP всё еще присутствует в составе последних версий Windows. Причиной такой огромной популярности стандарта является тот факт, что до определенного времени NetBIOS оставался основным интерфейсом программирования сетевых приложений, и с использованием функционала NetBIOS было написано огромное количество разнообразного программного обеспечения.
NetBT является неотъемлемой частью сетевого стека TCP/IP ОС Windows и инсталлируется вместе с протоколом TCP/IP. Части функционала NetBT встречаются в коде библиотек, переменных окружения (%COMPUTERNAME%, %USERDOMAIN%), коде некоторых современных антивирусных продуктов, почтовых серверов, баз данных. NetBIOS до сих пор используется в алгоритме добавления рабочей станции в домен, в процедурах работы с сетевым окружением, подключения сетевых дисков. Об исключительном значении протокола NetBIOS через TCP/IP говорит уже и тот факт, что штатными средствами самой ОС протокол NetBIOS может быть только отключен, но никак не удален. Удаление же его возможно только вместе с удалением всего протокола TCP/IP.

До определенного времени считалось актуальным высказывание “Cеть Windows не живет без NetBIOS!”, но начиная с версии Windows 2000, стало возможным избавиться от использования соединений на основе NetBIOS через TCP/IP и перейти исключительно на соединения по протоколу SMB (Server Message Block). Подобные соединения еще называются TCP/IP Direct Hosting (или DirectSMB). В соединениях на основе SMB отсутствует начальная стадия установки сессии TCP под названием “NetBIOS session setup” и используется единственный порт TCP/445.
SMB - это простой протокол удаленной работы с ресурсами (дисками, устройствами) компьютера. Удивительно, но SMB долгое время довольно тесно взаимодействовал с NetBIOS в части именования и разрешения имен, а так же требовал наличия установленной сессии NetBIOS для взаимодействия между узлами (работал поверх NetBIOS). Теперь же SMB представляет собой самостоятельный протокол и получил дальнейшее развитие в виде стандарта под названием CIFS, полностью независимого от NetBIOS.

Далее не будет лишним посмотреть, какие же сетевые порты используются сервисами NetBIOS:

Номер порта Назначение

137/TCP,UDP

NETBIOS-NS (NetBIOS Name Service). Сервис обеспечивает: широковещательный запрос, запрос о регистрации имени, запрос для WINS или DNS, проверку имени на существование, сопоставление NetBIOS-имени и IP-адреса.

138/TCP,UDP

NETBIOS-DGM (NetBIOS Datagram Services). Этот сервис обеспечивает: персональный запрос к одной станции, широковещательный запрос ко всем станциям, запрос к станциям с одним групповым именем.

139/TCP, UDP

NETBIOS-SSN (NetBIOS Sessions Services). Сервис используется для управления сессиями, установления сессии точка-точка (хост-хост).

Подобная структура отражает требование RFC 1001, 1002, регламентирующее наличие трех базовых сервисов, которые реализуют эмуляцию NetBIOS в системе Windows.
В системе Windows NetBIOS через TCPIP реализован с помощью драйвера уровня ядра netbt.sys, который поддерживает специализированный интерфейс TDI (общий интерфейс для взаимодействия с драйверами, который позволяет сервисам взаимодействовать с транспортными протоколами). Все сервисы, которые работают с NetBT (рабочая станция, сервер, браузер, сетевой вход в систему) используют TDI напрямую. Пользовательские приложения используют стандартный API (функции, вызовы), поддерживаемый библиотекой netapi32.dll, которая, в свою очередь, является простой "заглушкой" и перенаправляет вызовы к функциям netbios.dll. Функции библиотеки netbios.dll передают запросы к драйверу уровня ядра под названием NetBIOS-эмулятор (%SystemRoot%\System32\Drivers\netbios.sys), который транслирует команды NetBIOS, переданные приложением, в команды TDI-интерфейса.

Использование NetBIOS через TCP/IP

Собственно, как же работает NetBIOS? Я попытаюсь дать, пока что, собственное объяснение принципов работы стандарта. Все мы понимаем, что для того, чтобы станции могли взаимодействовать по сети, они должны подчиняться определенным правилам, выполнять предписанные действия на различных этапах работы. Этими этапами являются: заявление о себе (регистрация), попытка взаимодействия (обнаружение имен, установление сеанса, управление сеансом), отключение себя (освобождение имени). Поэтому, все узлы, использующие NetBIOS через TCP/IP, применяют регистрацию, обнаружение и освобождение имен, а так же многие другие методы, предоставляемые стандартом. Давайте рассмотрим их детальнее:

  • Регистрация имен. Начиная работу, узел NetBIOS пытается заявить о себе в сети, другими словами - сказать "Я есть узел такой то, с таким то именем". Регистрация имени NetBIOS происходит при помощи широковещательного или направленного только к серверу имен NetBIOS (WINS-сервер) запроса. Если какой-либо узел пробует зарегистрировать уже существующее в сети имя NetBIOS, то либо узел с данным именем, либо сервер имен NetBIOS (WINS-сервер) посылает отказ в регистрации имени, и узел, инициировавший регистрацию, получает в качестве ответа сообщение об ошибке.
  • Обнаружение имен. Когда узел уже зарегистрировался, работает в сети, но вдруг хочет связаться с другим узлом, он должен узнать IP-адрес этого узла. Для этого, узел-инициатор посылает запрос на определение имени, содержащий искомое NetBIOS имя. Для запроса используется широковещательный пакет или адресный запрос серверу имен NetBIOS (WINS). Узел, которому принадлежит искомое имя, или WINS-сервер отправляют обратно положительный/отрицательный ответ об определении имени. В результате инициатор получает информацию об IP-адресе целевого узла.
  • Освобождение имен. Освобождение имени происходит, если станция, приложение или служба NetBIOS прекращает работу. К примеру, если станция отключается некорректно, то она перестает отвечать на запросы, и другие станции через некоторое время прекращают попытки связаться с ней. Если в сети используется сервер имен NetBIOS, то перед корректным выключением станция посылает ему запрос на удаление информации о всех ресурсах, которые она поддерживала. В таком случае говорят, что имя NetBIOS освобождено, и доступно для использования другими узлами.
  • Запуск/завершение сеанса. Вероятно, мы пытались обнаружить сетевое имя не просто так, а с какой-то целью. А что если мы хотим обменяться данными: получить/передать файлы? Для этого нам необходимо установить сеанс связи с целевой станцией.
  • Надежная передача данных сеанса. После установления надежного сеанса связи с использованием транспортного протокола TCP, мы начинаем обмен данными. Например, передачу файлов.
  • Ненадежная передача данных сеанса. После запроса на разрешение имени, мы начинаем передачу информации с помощью транспортного протокола UDP. Например, поиск имени.
  • Возможность мониторинга и диагностики. Позволяет запрашивать статус удаленных и локальных ресурсов.
Разрешение имен в NetBIOS изначально было основано на широковещательных запросах (станция заявляет о себе каждые 60 секунд). Собственно, с самого начала NetBIOS и разрабатывался таким образом, чтобы использовать только широковещательные сообщения для локализации устройств в сети. Это и послужило одной из причин сокращения популярности стандарта, поскольку широковещательные запросы существенно увеличивают объем трафика в сети и являются немаршрутизируемыми. Только значительно позже, для устранения проблем широковещательного шторма и отсутствия маршрутизации запросов, решено было создать выделенный узел, который бы принимал запросы и давал ответы об именах в сети - WINS-сервер.

Для того, чтобы лучше понять логику работы NetBIOS через TCP/IP, давайте немного отступим от основной линии рассуждений, и рассмотрим по-отдельности некоторые сущности стандарта.

Имя NetBIOS

Одной из основных целей разработки NetBIOS являлось создание простого интерфейса, который давал бы возможность пользователям назначать станциям символьные имена вида MyComputer. Очевидно, что без подобных имен нам сложно обойтись, поскольку именно легкие имена позволяют человеку "узнать" (однозначно идентифицировать) ресурс, к которому он хочет обратиться по сети. Программам то всё-равно, вместо имен они могут использовать любые идентификаторы, однако человеку удобнее работать именно с фонетическими, понятными и легко запоминающимися именами. В качестве имени NetBIOS используется простое одноранговое (“плоское”) имя, без какой-либо иерархической структуры (в противоположность DNS). Подобная простота и отсутствие иерархии имени имеют и оборотную сторону - имена должны быть уникальными.

Имя NetBIOS имеет длину 16 байт.

Первые 15 - собственно имя, 16й - тип ресурса или суффикс (значение в диапазоне 00-FF, шестнадцатеричное представление). NetBIOS имя и имя компьютера (hostname) совпадают по первым 15 символам. Хранится это имя в ключе реестра с именем hostname, который размещен в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

NetBIOS имя закрепляется не за станцией, как многие привыкли думать, а за ресурсом и только за ним.

Ресурсы динамически регистрируются сначала в операционной системе, а затем и в сети, которой принадлежит станция. Регистрация происходит в тот момент, когда в операционной системе стартует сервис или приложение, использующее NetBIOS, либо авторизуется пользователь.
Со временем структура сетей усложнялась, помимо станций появились такие понятия как "рабочая группа" и "домен". Пришло осознание того, что ресурсы бывают разными, и имя может быть не только у станции. Поэтому исходя из этих соображений, было введено понятие "тип ресурса", который служит для логического разделения ресурсов по назначению, поскольку одно и то же имя может быть зачастую и у нескольких ресурсов одновременно. Типы ресурсов стандартизованы по классам и имеют следующие значения:

  • Уникальное (Unique, U) - к этому имени может быть привязан только один адрес IP;
  • Групповое (Group, G) - к этому имени не привязан единственный адрес, имя может содержать множественные IP-адреса; На запрос WINS-клиента об адресе всегда возвращается limited broadcast address 255.255.255.255;
  • Группа Интернет (Internet Group, Special Group, I) - к этому имени может быть привязано до 25 адресов; для каждого адреса хранится свой TTL. Используется для управления именами домена в WinNT;
  • Доменное имя (Domain Name, D) - к этому имени может быть привязано множество адресов;

Поскольку NetBIOS не использует номера портов, как это делает TCP/IP, адресное пространство имен должно быть способно поддерживать множество имен для каждой системы. К примеру, если на одной станции реализованы файловый сервер, служба Exchange и сервер удаленного доступа, то каждый из этих сервисов должен иметь отличное от других имя, однозначно определяющее сам сервис. Для этой цели авторы NetBIOS придумали понятие суффикса. Как было сказано выше, он занимает последний, 16й байт в имени и идентифицирует сервис.

Полный перечень типов общих ресурсов NetBIOS

У имен NetBIOS имеется следующий нюанс - все имена длиной менее 15 символов дополняются пробелами (код символа 20 в шестнадцатеричном представлении), а в некоторых случаях символами BE либо BF. Поскольку к работе над NetBIOS подключались многие разработчики, то и типов общих ресурсов существует великое множество, однако в таблице я привожу только те типы, которые используются Microsoft.

Уникальное имя (Unique name) Суффикс Описание
COMPUTERNAME <00> Регистрируется сервисом "Рабочая станция" (Workstation). Это NetBIOS-имя станции. Передается в качестве имени источника в запросе на установку NBT-сессии. Позволяет хосту подключаться к сетевым ресурсам.
COMPUTERNAME <01> Регистрируется сервисом Messenger. Не во всех версиях Windows. Передается в качестве имени источника в запросе на установку NBT-сессии сервисом Messenger.
COMPUTERNAME <03> Регистрируется сервисом Messenger. Это имя используется при обмене сообщениями (WinPopup) между хостами. Для этого используется SMB протокол.
USERNAME <03> Регистрируется сервисом Messenger. Используется так же, как и описанное выше правило для COMPUTERNAME<03>, однако адресатом, вероятно, является пользователь.
COMPUTERNAME <06> Регистрируется сервисом RAS Server.
COMPUTERNAME <1F> Регистрируется сервисом NetDDE
COMPUTERNAME <20> Регистрируется сервисом "Сервер" (Server). Позволяет хосту получать запросы на соединения от других узлов с целью подключения к ресурсам станции. Используется SMB протокол.
COMPUTERNAME <21> Регистрируется сервисом RAS Client.
COMPUTERNAME <22> Регистрируется сервисом Exchange Interchange.
COMPUTERNAME <23> Регистрируется сервисом Exchange Store.
COMPUTERNAME <24> Регистрируется сервисом Exchange Directory.
COMPUTERNAME <2B> Регистрируется сервисом Lotus Notes Server.
COMPUTERNAME <30> Регистрируется сервисом Modem Sharing Server.
COMPUTERNAME <31> Регистрируется сервисом Modem Sharing Client.
COMPUTERNAME <42> Регистрируется McAfee Antivirus.
COMPUTERNAME <43> Регистрируется сервисом SMS Client Remote Control.
COMPUTERNAME <44> Регистрируется сервисом SMS Admin Remote Control Tool.
COMPUTERNAME <45> Регистрируется сервисом SMS Client Remote Chat.
COMPUTERNAME <46> Регистрируется сервисом SMS Client Remote Transfer.
COMPUTERNAME <4C> Регистрируется сервисом DEC Pathworks TCPIP Service.
COMPUTERNAME <52> Регистрируется сервисом DEC Pathworks TCPIP Service.
COMPUTERNAME <6A> Регистрируется сервисом Microsoft Exchange IMC.
COMPUTERNAME <87> Регистрируется сервисом Microsoft Exchange MTA.
COMPUTERNAME <BE> Агент Network Monitor. Microsoft's Network Monitor (NetMon).
COMPUTERNAME <BF> Приложение Network Monitor Client. GUI для Network Monitor (NetMon).
DOMAINNAME/WORKGROUPNAME <1B> Регистрирует станцию как Domain Master Browser. Регистрация суффикса 1B отличает PDC от остальных контроллеров домена.
DOMAINNAME <1D> Регистрирует станцию как Master Browser (зачастую именуется как Local Master Browser). Имя уникально для локального сегмента сети.
Групповое имя (Group name) Суффикс Описание
DOMAINNAME/WORKGROUPNAME <00> Регистрирует станцию как члена рабочей группы или домена.
DOMAINNAME <1C> Регистрирует станцию как контроллер домена. Каждый контроллер домена регистрирует это групповое имя.
DOMAINNAME/WORKGROUPNAME <1E> Регистрируется как групповое имя. Используется при выборах Master Browser.
Forte_$ND800ZA <20> DCA IrmaLan Gateway Server Service
IRISMULTICAST <2F> Lotus Notes.
IRISNAMESERVER <33> Lotus Notes.
[01h][02h]__MSBROWSE__[02h] <01> Master Browser (Local Master Browser). Групповое имя, регистрируемое всеми Master Browser в сети. Используется для поиска других LMB с целью обмена списками просмотра.

Тип ресурса можно посмотреть командой nbtstat -a <имя_компьютера>:

Основное назначение этой команды - показать информацию из локальной таблицы NetBIOS имен для всех интерфейсов, установленных на станции. Имеет алиас - nbtstat -n.

Методы разрешения имени NetBIOS

Очевидно, что тут мы будем говорить о том, какими средствами NetBIOS удается найти соответствие имени и IP-адреса ресурса? Какие же методы определения имен доступны интерфейсу NetBIOS? Сразу обращу ваше внимание на то, что не все из перечисленных методов относятся непосредственно к стандарту NetBIOS. Я считаю, что к NetBIOS относятся только лишь: LMHOSTS, WINS, кеш имен NetBIOS, широковещательный запрос в подсети. Такие же понятия как HOSTS и DNS относятся уже к TCP/IP Direct Hosting. Но поскольку понятия "NetBIOS имя станции" и "имя хоста" довольно тесно взаимосвязаны в современных ОС Windows, то resolver (модуль, разрешающий имена), использует все доступные методы для нахождения соответствия, умело комбинируя разнородные методы определения имен.

  • NetBIOS name cache (локальный кеш NetBIOS) - специальная структура в памяти процесса для записи результатов разрешения имен. Время жизни записей - 10 минут. Приложение смотрит в локальном кэше, нет ли там искомого имени. И правда, зачем нам тратить время на другие методы, если может статься, что мы недавно уже обращались к станции, и имя её содержится в локальном кеше. Локальный кеш NetBIOS можно посмотреть командой "nbtstat -r". Некоторые параметры, которые влияют на функционал NetBIOS name cache можно найти в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters.
  • NetBIOS name server (WINS, NBNS). Если сказать иначе, WINS это DNS от Microsoft для NetBIOS. Станции с определенными типами узлов обращаются к WINS-серверу за разрешением имени.
  • IP subnet broadcast - широковещательное сообщение в IP-подсети. Станции с определенными типами узлов формируют широковещательный запрос для разрешения имени.
  • Локальный LMHOSTS файл. Аналог HOSTS для NetBIOS. Файл, в котором, в специальном формате, хранится таблица соответствия имен NetBIOS IP-адресам. Размещается в директории %SystemRoot%\System32\Drivers\Etc.
  • Локальный HOSTS файл. Файл, в котором, в специальном формате, хранится таблица соответствия имен хостов (TCP/IP hostname) IP-адресам. Располагается в директории %SystemRoot%\System32\Drivers\etc. Этот метод непосредственно не относится к NetBIOS через TCP/IP, а относится уже к TCP/IP Direct Hosting. Если NetBIOS имя найти не удалось, то имя считается как TCP/IP hostname и разрешается уже методами HOSTS+DNS.
  • DNS-сервер. Запрос к DNS-серверу. DNS-сервер возвращает запись о соответствии имени хоста IP-адресу.

Тип узла NetBIOS (NodeType)

Поскольку методы регистрации имен в сети у NetBIOS тоже не стояли на месте, и если изначально все сводилось, как мы уже упоминали, к широковещательным запросам, то со временем начали появляться и другие способы зарегистрировать имя (например, с использованием WINS-сервера). В связи с необходимостью разделять логику работы станций, было введено понятие NodeType (NBT-узел) для описания разницы в способах регистрации и распознавания имен. Проще говоря, разные типы узлов имеют свои обособленные алгоритмы разрешения имен в IP-адреса:

  • B-node (тип 0x01, широковещательный). Для преобразования имен станций в IP-адреса используется только широковещательные сообщения. Минус этого типа заключается в том, что широковещательные запросы, обычно, режутся маршрутизаторами, поэтому имена могут быть разрешены только в пределах одного сетевого сегмента.
  • P-node (тип 0x02, одноранговый). Для разрешения имен используются WINS-сервер (сервер имен NetBIOS). Сессии клиента длятся на три этапа: регистрация имени, обновление имени и освобождение имени. Если WINS не работает, то ни регистрации, ни разрешения не происходит.
  • M-node (тип 0x04, смешанный, гибрид B- и P-узлов). Сначала действует как B-node, то есть для разрешения имен используются широковещательные сообщения. Если не получает ответа на широковещательный запрос, то переключается в P-node и использует WINS-сервер.
  • H-node (тип 0x08, гибридный, гибрид B- и P-узлов). Сначала пытается стать P-node и действовать через WINS-сервер. Если WINS-сервер не доступен, переключается в B-node и пытается функционировать через широковещательные запросы. Переключается обратно в P-node, как только находит WINS-сервер.
Microsoft использует свою собственные, модифицированные версии типов, так называемые Microsoft-Enhanced B-node, P-node, M-node, H-node. Модификация подразумевает, помимо стандартных алгоритмов, описанных выше, использование файла LMHOSTS, функции API Winsock - gethostbyname(), которая использует в своей логике обращение к HOSTS/DNS.

Пополняя многообразие сетевых разработок, с 1990 года начал активно внедряться протокол DHCP, и пришлось оптимизировать NetBIOS под работу с ним. Так, если в сети используется DHCP для автоматического назначения IP-адресов, то можно установить метод разрешения имен для DHCP-клиентов. Другими словами, можно назначить тип узла (nodetype), через установку опцию DHCP-сервера 046 WINS/NBT. Либо, в случае отсутствия DHCP-сервера, можно локально задать тип узла в реестре через ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters\NodeType.
По умолчанию, при отсутствии WINS-сервера в сети, Windows выставляет тип узла в значение "модифицированный B-node", а при наличии WINS-сервера тип узла выставляется в гибридный, H-node.
Увидеть тип узла можно посредством команды ipconfig /all, в параметре “тип узла”:

Порядок разрешения имен NetBIOS

Это нетривиальный процесс, который во времени претерпевал большое количество изменений, связанных с введением и преобразованием протоколов, ответственных за сетевое взаимодействие. В данный момент сам процесс разрешения имен NetBIOS вызывает большое количество споров. Связано это с тем, что в сети имеется огромное количество различных источников информации, в которых приводятся довольно расплывчатые формулировки, которые зачастую неактуальны или вовсе ошибочны. Я попробую выразить свою точку зрения на вопрос разрешения имен NetBIOS в частности, и шире - на алгоритм разрешения имен в ОС Windows в общем. Надо понимать, что в Windows существуют два параллельных направления разрешения имен - через функции API Windows Sockets и через функции API NetBIOS. Код ОС , то есть приложения, сервисы, драйвера и прочее, могут использовать тот или иной API. Соответственно, сюда относятся и механизмы разрешения имен самой ОС, которые используются при обращении пользователя к сетевым ресурсам стандартными средствами, например, при использовании проводника или средства подключения сетевых дисков. Таким образом, именно от того, какой метод использует тот или иной компонент ОС и зависит, в конечном итоге, алгоритм разрешения имени.

Начиная с Windows 2000, Microsoft существенно изменила порядок разрешения имен. Это было мотивировано разделением SMB и NetBIOS на две независимые ветви кода.

Если приложение использует функции API Winsock

В этом случае, процесс, инициировавший разрешение имени, использует такие функции API Windows Sockets как: getaddressbyname, gethostbyname, getnameinfo, getaddrinfo, и последовательность разрешения имени, в этом случае, такова:

  1. Сравнивает искомое имя с собственным. Не я ли это?;
  2. Проверяется наличие записи об узле в в локальном кеше DNS-резолвера. На этом же этапе проверяются записи, присутствующие в файле hosts (%SystemRoot%\System32\Drivers\etc), поскольку они, с определенным интервалом, импортируются в кеш DNS-резолвера;
  3. Делается запрос к DNS на наличие записи о хосте в зоне;
  4. Проверяется локальный кеш имен NetBIOS (NetBIOS name cache);
  5. Опрашивается WINS-сервер;
  6. Делается широковещательный запрос;
  7. Проверяется наличие записи в файле LMHOSTS. Размещается в %SystemRoot%\System32\Drivers\etc;

Как мы видим, даже при использовании функций API Winsock, в некоторых случаях, в алгоритме разрешения имени вызываются функции API NetBIOS. То есть, все вышеописанные функции API в своей логике содержат ветвления, которые могут инициировать передачу управления функциям API NetBIOS. Реализовано это с целью сохранить совместимость приложений. Однако, если исходное имя, которое должно быть разрешено:

  • Представляет из себя FQDN (Full Qualified Domain Name, полностью уточненное доменное имя), то есть запись вида host.domain.ru.
  • Имеет длину более 15 символов.
  • Имеет знак "." в своём составе.

..то попытки разрешить имя с помощью функций API NetBIOS вообще не производится. В таком случае, вышеописанные функции в своем алгоритме по условию не вызывают функций разрешения имен API NetBIOS.
Если же имя короче 16 символов (имеет длину не более 15 символов), то в случае неудачной попытки разрешения имени с помощью HOSTS+DNS, функции API Winsock передают его в API NetBIOS (где оно дополняется пробелами) для разрешения уже логикой NetBIOS.

Если приложение использует функции API NetBIOS

В этом случае, логика разрешения имен кардинально меняется. Сначала вызывается единственная функция API NetBIOS которая так и называется "NetBIOS", параметром которой является указатель на структуру NCB, в которой задается команда NCBFINDNAME. В случае неудачи производится попытка разрешения с помощью API Winsock.

Последовательность разрешения имен через API NetBIOS в IP-адреса зависит, как мы уже говорили выше, от типа узла.

Например, для Модифицированного H-узла (Enchanced H-node) она следующая:

  1. Локальный кеш имен NetBIOS;
  2. WINS-сервер;
  3. Широковещательный запрос;
  4. Файл LMHOSTS;
  5. Локальный кеш DNS. Файл hosts (записи из него включаются в локальный кеш DNS);
  6. DNS-сервер;

То есть, как мы видим из последовательности, используется сначала логика разрешения имен NetBIOS, а потом уже, если имеется необходимость, вызываются функции API Winsock.

Исходя из всего вышеописанного, довольно сложно составить какой-то обобщенный алгоритм разрешения имен, однако я все же постараюсь это сделать. Для наглядной демонстрации описанной логики я приведу схему, описывающую собственное понимание происходящего. Стоит, однако, отметить, что в зависимости от API, которое используется для разрешения имени, части данной схемы могут меняться местами.

Порядок разрешения имен NetBIOS

На этой оптимистической ноте я и хотел бы завершить теоретическую часть обзора NetBIOS через TCP/IP. Очевидно, что на данный момент NetBIOS морально устарел и содержит впечатляющее количество недоработок. К примеру, одним из существенных недостатков безопасности NetBIOS является предоставление информации о сетевых сервисах (ресурсах) любому узлу в сети в ответ на типовой запрос, то есть отсутствуют какие бы то ни было критерии разграничения доступа. Вероятно, архитектура NetBIOS уже настолько неоптимальна, что в какой-то момент разработчики MS отказались от её доработки с целью поддержки современных сетевых стандартов. Microsoft, судя по всему, всячески пытается избавиться от протокола, и подтверждением тому служит и тот факт, что был написан аналог - LLMNR. В следующих статьям мы познакомимся с такими часто встречающимися на практике примерами, как подключение к ресурсам посредством NetBIOS, построение объектов сетевого окружения через NetBIOS.

  • Поделиться:

9 комментариев:

  1. Дмитрий

    Спасибо за ваш блог, подобного мало в рунете приятно читать такие полые статьи! Жму руку автору!

  2. Алексей

    Отличная статья по NetBIOS на русском языке!
    Правда Вы, в алгоритме разрешения имен, делите на две разных строчки локальный кэш DNS и файл HOSTS. Т.е. читатель понимает это так - сначала система лезет в кэш, а если там ничего нет, то лезет в файл hosts на жестком диске, ну и далее по алгоритму.
    Так вот, во многих источниках (не знаю, можно ли давать тут пруфы) сообщается, что содержимое файла hosts помещается в локальный dns-кэш при старте компьютера, и находится там все время.
    Следовательно, посмотрев искомое имя в локальном кэше DNS, и не обнаружив его там, система не лезет в файл hosts (так как знает, что его содержимое и так находится в кэше, который уже был просмотрен на первом шаге), а переходит к запросу DNS ну и далее по списку.

    • einaare

      Спасибо! :) Проверю как будет время, ценное замечание!

    • einaare

      Да, все действительно оказалось в точности так, как Вы и описали. Подправил статью. Спасибо!!

  3. anton

    Спасибо.....

  4. Денис

    Спасибо, отличная статья. Наткнулся на неё в поисках ответа на свой вопрос, где советовали разобраться с типом узла.
    Озвучу вопрос, если поможете - с меня пиво ) (на телефон ессно хех)
    Есть 3 локальных сети. Есть удалённый ресурс 192.168.2.44. Я со 192.168.24.89 должен добраться до 192.168.2.44 - пинг не проходит. На всех остальных компьютерах подключается. Tracert 192.168.2.44 с любого ПК, на котором работает, показывает промежуточный узел 10.253.166.1. Со 192.168.24.89 этот узел пингуется и трассировка до него идёт.
    В firewall.cpl - отключил брандмаэур. Антивирь выключал. В hosts добавил 192.168.2.44. Результат по ipconfig /all на "не рабочей" машине и на "рабочей" одинаковые. NetBIOS over TCP/IP включено. IPV6 отключал (на "рабочих" машинах он включён). nslookup разрешает имена в 192.168.24.* с "рабочей" машины на "не рабочую" и наоборот.

    Вопрос - какого хора со 192.168.24.89 не пингуется 192.168.2.44 и соответственно не подключается к ресурсам.

    • einaare

      Здравствуйте!! А что за узел 10.253.166.1? он Вам принадлежит? и что из себя представляют остальные сети, из которых "все работает"? Необходимо больше информации, что к чему подключено, как эти 3 сети между собой соединены. Я так понял, сети следующие: 192.168.2.0/24 -- 10.253.166.0/24 -- 192.168.24.0/24 ? с нескольких станций из сети 192.168.24.0 узел 192.168.2.44 доступен (маршрутизируется), а с 192.168.24.89 нет? Ну, скорее всего тут проблема не в типе узла и не в netbios, а в маршрутизации. Выложите ipconfig /all с рабочей и нерабочей станций и выложите route print с обеих.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *