Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Отображение имен NetBIOS в сетях TCP/IP

Эрик Холл

Операционные системы Microsoft Windows 95 и Windows NT предоставляют пользователям набор простых и удобных средств для совместного доступа к ресурсам друг друга. При этом нет необходимости использовать выделенный файл-сервер, централизованную систему безопасности и другие сложные сетевые технологии.

Указанные системы — два представителя большого семейства, которое включает также Microsoft Windows for Workgroups, Microsoft LAN Manager for OS/2, IBM LAN Server, PathWorks для ОС VMS корпорации Digital Equipment, SAMBA и LAN Manager для ОС UNIX (от компаний Hewlett-Packard, NCR, Santa Cruz Operation и др.). Фирма Novell также предлагает ПО, позволяющее серверам NetWare взаимодействовать с рабочими группами на базе LAN Manager.

Стержневыми технологиями, которые связывают эти системы вместе, являются протокол SMB (Server Message Blocks) и протокол NetBIOS-over-TCP/IP (NBT). Протокол SMB, выполняющий рутинные операции по разделению файлов и принтеров, "невидим" конечным пользователям, так как межсистемными коммуникациями управляют сетевые драйверы. Однако NBT невозможно "спрятать" — в основном потому, что этот протокол хорошо работает только в локальных широковещательных сетях. Если не предпринять соответствующих предварительных мер, доступ к удаленным сетям и системам и работа с ними при использовании NBT могут быть значительно затруднены. Рассмотрим различные варианты реализации службы NBT в ЛВС.

ПоЧему NetBIOS плохо работает в больших сетях

Несколько лет назад фирма IBM разработала NetBIOS (сетевую базовую систему ввода/вывода) для того, чтобы на этой основе создать сетевой протокол, работающий в небольших сетях ПК. В то время 30 узлов были пределом для сегмента Ethernet, тогда как технология Token Ring компании IBM допускала наличие 255 узлов. Цель разработки NetBIOS — создание небольшого и быстрого протокола, который давал бы возможность пользователям назначать устройствам имена типа "MyComputer". Такие имена запоминаются легче, чем сложные числовые схемы, подобные системе адресов IP.

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

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

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

Однако поскольку узлы NetBIOS посылают много широковещательных сообщений, то большие сети, в которых используются мосты, работают неудовлетворительно. На рис. 1 представлена небольшая по размеру ЛВС, состоящая из двух сегментов и использующая только широковещательные сообщения.

Для того чтобы приложения на базе NetBIOS работали в сетях TCP/IP, им необходимо "видеть" имена, а IP-протоколу — цифровые адреса, но они не могут "видеть" друг друга. Расположенный между ними промежуточный уровень должен отображать имена NetBIOS в IP-адреса и, наоборот, конвертировать IP-адреса в имена NetBIOS. Этот уровень известен как NetBIOS-over-TCP/IP (NBT) и описан в RFC (Request For Comment) 1001 и 1002.

В этих двух документах определены три основных типа узлов NetBIOS: b-узел (узел широковещания) использует широковещательные сообщения для опроса узлов сети на предмет имен NetBIOS; p-узел (point-to-point, узел двухточечной связи) использует направленные вызовы для связи с сервером имен NetBIOS, например с сервером службы адресов Интернет в среде Windows (WINS), чтобы определить IP-адрес машины по ее NetBIOS-имени; m-узел — смешанный узел, который применяет широковещательные запросы для обнаружения узла, а не обнаружив его, запрашивает сервер имен p-узлов на предмет существования такого адреса.

В этих документах рассмотрен еще один тип узла — h-узел, действие которого обратно действию m-узла, а именно: сначала выполняется направленный запрос, а при неудаче используются широковещательные запросы. Модель h-узла применяется сетевыми клиентами Microsoft по умолчанию всякий раз, когда при конфигурировании клиента указан WINS-сервер.

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

В протоколе NBT при определении IP-адресов для NetBIOS-имен используется несколько методов их распознавания. Простейший из них — применение широковещательных сообщений для обнаружения доступных ресурсов сети. При этом для каждого запроса NetBIOS узел вынужден выдавать широковещательное сообщение TCP/IP. Этот метод работает только тогда, когда в вашей ЛВС присутствует хотя бы одна система, которая может "увидеть" это сообщение и ответить на него.

Другой метод распознавания имени заключается в предварительной загрузке IP-адреса в клиентский кэш разрешения "имя—адрес". При этом не требуется никаких широковещательных сообщений, так как отображение IP-адреса находится в оперативной памяти. Вы также можете создать текстовый файл LMHOSTS, аналогичный по функции файлу HOSTS. Последний используют большинство стеков TCP/IP.

Еще один метод распознавания имени — применение WINS-серверов, которые, как описано в RFC 1001 и 1002, по сути своей являются p-узлами. Можно также использовать DNS-серверы (службы доменных имен), хотя этот метод функционально ограничен.

С помощью рекурсивного поиска NBT осуществляет отображение имен до тех пор, пока не будет найден ресурс, соответствующий данному имени. По умолчанию сетевыми клиентами Microsoft используется следующая процедура (при условии, что каждый из этих механизмов доступен): NBT просматривает свой внутренний кэш имен; NBT запрашивает известные WINS-серверы; затем выдается широковещательное сообщение; далее NBT ищет файл LMHOSTS и, наконец, выдает запрос DNS-серверам для рассматриваемого имени NetBIOS.

Если соответствие не найдено, то сообщение об ошибке типа "имя не найдено" возвращается приложению NetBIOS. Для достижения наибольшей производительности необходимо так сконфигурировать клиентские программы, чтобы наиболее часто встречающиеся NetBIOS-имена предварительно загружались в кэш клиента. Однако имейте ввиду, что объем памяти клиентского кэша достаточно мал и имена в нем будут часто "затираться", особенно если клиенты подключены к нескольким серверам. Это может привести к тому, что в каждом случае будут использоваться широковещательные запросы и запросы к WINS-серверу. Размер кэша можно увеличить, но тогда уменьшится доступный клиенту объем памяти. Наверное, это самое большое ограничение, к которому привела благородная цель спроектировать NetBIOS для небольших сетей.

База данных LMHOSTS

База данных LMHOSTS является обычным текстовым файлом, формат которого функционально аналогичен формату файла HOSTS для TCP/IP. Он включает числовой IP-адрес, знак табуляции и NetBIOS-имя (и, возможно, комментарий). Однако не смешивайте базу данных LMHOSTS с базой данных HOSTS. Хотя обе они похожи по механизму применения и по структуре, но используются для двух совершенно различных целей. Просто примите к сведению, что файл LMHOSTS позволяет NBT воспользоваться как архитектурой широковещания, так и архитектурой "точка—точка" и при этом нет необходимости иметь в вашей локальной сети выделенный сервер имен. Поняв, что "LM" в "LMHOSTS" символизирует "LAN Manager", вы многое уясните для себя.

Примерная запись в файле LMHOSTS может выглядеть следующим образом: 198.105.232.1 FTP # Microsoft’s Public FTP server. Эта строка сообщает NBT, что любые запросы NetBIOS, предназначенные узлу с NetBIOS-именем "FTP", следует направлять по адресу 198.105.232.1.

Вы должны внимательно относиться к внесению записей в файл LMHOSTS. Причиной возникновения некоторых наиболее часто встречающихся проблем является неточное "с точки зрения" системы назначение NetBIOS-имени для хоста. Например, имя хоста FTP нельзя определить просто как "FTPSERVER". В этом случае система назначения "увидит", что запрос предназначен другому хосту NetBIOS, и проигнорирует его.

Вам также может понадобиться определить отображения имен сервисов NetBIOS, а не просто отображения имен хостов. Приложения для рабочих групп могут иметь NetBIOS-имена, включая Lotus Notes, шлюзы SNA и др. Поскольку NetBIOS не использует номера портов или гнезда (sockets), как это делают IPX или TCP/IP, его ограниченное пространство имен должно быть способно поддерживать множество имен для каждой системы назначения. Например, если на одной и той же системе реализованы межсетевой интерфейс SNA, лицензионный сервер и приложение "клиент-сервер", то каждый из этих сервисов должен иметь отличное от других NetBIOS-имя, определяющее сам сервис, а не только NetBIOS-имя рабочей станции. Сервис назначения не будет отвечать на запрос приложения, если приходящее имя в точности не будет соответствовать имени требуемого сервиса.

Пример записи для приложения в файле LMHOSTS выглядит точно так же, как имя рабочей станции. При выполнении на одной рабочей станции нескольких приложений вам придется завести столько же записей в файле LMHOSTS.

Со временем некоторые фирмы—производители ПО стали присваивать довольно изощренные NetBIOS-имена своим сервисам, используя для этого различные регистры, пробелы внутри имени или добавляя непечатаемые знаки из расширенного ASCII-набора.

Для определения таких имен соответствующее поле записи заключают в кавычки. Кроме того, если вам необходимо использовать в имени шестнадцатеричный знак, его следует предварить префиксом \0х. Имена NetBIOS ограничены 15 знаками, поэтому шестнадцатеричные знаки следует разместить в начале расширенного имени. Например, запись для какого-нибудь сервиса могла бы выглядеть так: 127.1.1.1 "SNA Gateway1 \0х20" # NetBIOS-имя сервиса с шестнадцатеричным знаком в конце. В приведенном выше примере шестнадцатеричный знак 20 будет помещен в 16-й разряд NetBIOS-имени "SNA Gateway1".

Предварительная загрузка записей в кэш NBT

Имейте в виду, что обращение к файлу LMHOSTS происходит только в тех случаях, когда в памяти нет отображения NetBIOS-имени в IP-адрес и при неудаче с широковещательным запросом. Предварительно загрузив имена NetBIOS в клиентский кэш NBT, вы значительно сократите ваш широковещательный трафик и ускорите клиентские операции, поскольку драйверу NBT, прежде чем заняться поисками имени в файле LMHOSTS, не придется всякий раз ждать тайм-аута для широковещательного опроса NetBIOS.

Если вам нужно добавить часто используемое имя в файл LMHOSTS, то в конце записи следует поместить признак #PRE. Заметим, что знак "#", который в файле LMHOSTS обычно означает комментарий, в NBT в команде #PRE используется для обратной совместимости с серверами LAN Manager, не поддерживающими избирательную предварительную загрузку. Более старые системы игнорируют команду #PRE, приняв ее за комментарий. Пример записи "имя—адрес", которая должна быть предварительно загружена в кэш NBT, выглядит так: 198.105.232.1 FTP #PRE # Microsoft’s FTP server. Заметим, что после последнего признака комментария все знаки игнорируются. Эта запись заставит NBT посылать прямой запрос непосредственно хосту FTP всякий раз, когда он будет затребован, и широковещательное сообщение перед этим выдаваться не будет. Рис. 2 иллюстрирует систему, в которой используются предварительно загруженные записи NBT.

Служба WINS

Управление файлами LMHOSTS на персональных компьютерах, распределенных внутри вашей организации, может быть невероятно трудным или даже совсем невозможным делом. В ряде случаев сервер NetBIOS-имен может значительно улучшать управляемость, но при этом иметь очень высокую стоимость. По существу, как определено в RFC 1001 и 1002, WINS-сервер является p-узлом. Однако реализация его — приоритет фирмы Microsoft, собственника этой технологии. Другие системы (например, SAMBA) также предлагают серверы p-типа, но они не до конца совместимы с WINS-серверами. Последние имеют базы данных соответствия NetBIOS-имен IP-адресам, которые строятся автоматически с помощью различных источников. Если вы используете NT-серверы протокола динамической конфигурации хостов (DHCP), то WINS может просматривать базы данных DHCP с целью обнаружения NetBIOS-имен и зарегистрированных IP-адресов. Кроме того, входящие в сеть клиенты WINS будут автоматически регистрировать свои NetBIOS-имена и IP-адреса с помощью WINS-серверов, которые определены в их локальных или поддерживаемых DHCP конфигурациях. При этом они не посылают широковещательных сообщений для регистрации имен и разрешают хранить свои отображения типа "имя—адрес" на централизованном сервере удаленной системы.

WINS-серверы можно сконфигурировать и для обмена информацией с другими WINS-серверами, что позволит вам иметь копии ваших баз данных имен.

Чтобы иметь возможность ответить от имени других систем, WINS-серверы сохраняют ответы на широковещательные сообщения NetBIOS от локальных устройств. Это позволяет ранним версиям NetBIOS-приложений, которые непосредственно не поддерживают технологию WINS, использовать базу данных WINS. Когда b-узел объявляет о своем присутствии в сети, все локальные WINS-серверы сохраняют эту информацию в своих базах данных и от имени локального устройства отвечают на поисковые запросы удаленных систем. Отметим, что WINS-серверы будут подбирать ответы на широковещательные запросы только у тех сетевых сегментов, которые подключены к ним физически, поскольку системы ранних версий не умеют направлять отображения типа "имя—адрес" на удаленные WINS-серверы.

Вы также можете сконфигурировать ваши ПК как полномочные (proxy) WINS-серверы, которые отвечая на широковещательные сообщения, тем не менее не будут использованы как чисто p-узловые серверы. Когда клиент, для которого режим WINS является недоступным, пошлет широковещательное сообщение, proxy-сервер выдаст запрос заранее определенному WINS-серверу. Затем результат запомнится в его локальном NBT-кэше и proxy-сервер ответит на каждый последующий запрос NetBIOS-имени узла (рис. 3). Поскольку большинство клиентов выдают многократные широковещательные сообщения, то proxy-сервер WINS, вообще говоря, может реагировать на первоначальный запрос прежде, чем наступит тайм-аут для клиентского широковещательного сообщения. Запись содержится в кэше до истечения срока ее действия или пока пространство кэша не понадобится для новых записей. У ПК объем памяти кэша обычно небольшой, поэтому в сильно загруженной сети не следует ожидать больших преимуществ.

Использование серверов DNS

Благодаря 32-разрядной числовой адресации TCP/IP представляет собой поистине распределенный протокол, способный охватить огромные расстояния и множество сегментов сети. К сожалению, эти адреса трудно запоминаются. Поэтому была изобретена служба имен доменов (DNS), которая поддерживает иерархическое пространство имен, отображающее IP-адреса, что позволяет использовать обращения типа www.nwc.com и устраняет необходимость запоминать IP-адрес.

Удачный ход, сделанный корпорацией Microsoft по разработке WINS как механизма построения баз данных, преобразующих IP-адреса в NetBIOS-имена, не умалил достоинств службы DNS, которая существует уже много лет и обеспечивает гораздо более надежный механизм, используемый не только приложениями NetBIOS, но и другими. Однако ограничения NetBIOS все еще существенны в отношении NBT. Например, имя NetBIOS, которое вы запрашиваете, должно соответствовать имени, зарегистрированному системой-владельцем, но с помощью этого имени вы не сможете просмотреть ресурсы на хосте ftp.microsoft.com. Вместо этого вы должны будете обратиться к нему по NetBIOS-имени FTP, что существенно ограничивает применение DNS как инструмента отображения NetBIOS-имен в IP-адреса. Тем не менее эта технология весьма полезна для просмотра узлов, которые находятся в том же, что и ваши клиенты, домене TCP/IP, так как позволяет отказаться от использования файлов LMHOSTS и WINS-серверов.

С помощью DNS клиент Windows NT 4.0 имеет расширенную возможность для отображения имен и может запрашивать устройства, используя их полные доменные имена независимо от того, в каком домене находится сам клиент. Теперь, применив эту технологию, можно запросить хост ftp.microsoft.com и просмотреть его сетевые ресурсы.

На рис. 4 показано, как запросы службы DNS для узлов в удаленных доменах становятся бесполезными при использовании NBT, за исключением сетей, в которых на всех клиентах и серверах установлена Windows NT 4.0.

***

Хотя механизм NetBIOS чрезвычайно ограничен, для многопротокольных сетей он обеспечивает наиболее общий метод именования. Использование имен для узлов и сервисов делает его простым в применении, а отсутствие зависимости от любых формальных механизмов иерархической адресации придает ему гибкость. Вы можете наложить NetBIOS почти на любой протокол от IPX до DECnet или TCP/IP, и он будет работать.

Проблемы возникают в том случае, если вы пытаетесь отобразить пространство неиерархических имен на распределенное иерархическое адресное пространство. Для пользователя существует несколько возможностей построения таблицы имен, которая удовлетворит почти любое требование. Кроме того, многие проблемы корпорация Microsoft решила с помощью новой технологии в ОС Windows NT 4.0, хотя она может пригодиться только для клиентов Windows NT 4.0, подключенных к серверам Windows NT 4.0.


распечатать статью




  
2 '1997
СОДЕРЖАНИЕ

колонка редактора

• Наш хит-парад

локальные сети

• Концентраторы Ethernet для рабочих групп (обзор российского рынка)

• Выбор аппаратной платформы для Windows NT

• Основы построения структурированной кабельной системы. Часть III

корпоративные сети

• АТМ в России: первые успехи

• Принимая решение о создании сети АТМ

услуги сетей связи

• Лазерная связь — новый экономичный способ беспроводной связи

• Беспроводные сетевые технологии

• Проблемы передачи данных по телефонным линиям

• Перспективные системы и стандарты транкинговой связи

• Измерительное звено системной интеграции

интернет и интрасети

• Как настроить браузер WWW

• Microsoft и Netscape — победители в "войне" браузеров

• Моментальная интрасеть

• Интеграция Windows и Unix с помощью файловых сервисов на базе SMB

• Отображение имен NetBIOS в сетях TCP/IP

• Шлюзы IPX—IP: ваши переводчики в стране Интернет

защита данных

• Обеспечение безопасности Web-сервера

новые продукты

• StorPoint — новое средство доступа к CD-ROM; Администрирование DNS станет легче

только на сервере

• Серверы ODBS: новое слово в технологии БД



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх