Каталоги и Internet

Никто так и остался бы Никем в Internet, если бы не множество закулисных служб каталогов. Теперь к тому же эти службы учатся взаимодействовать между собой.

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

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

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

В продолжение развития этой метафоры отметим, что в юные годы Internet (до 1992 года) идентичность не имела большого значения. Компьютеров было немного, и, как следствие, их было легко найти; большинство пользователей обладали одинаковыми правами, а сложные транзакции были немногочисленны или отсутствовали вовсе.

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

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

В Internet все и каждый зависит от каталогов, знают они об этом или нет. Несколько лет назад «Нью-Йоркер» опубликовала карикатуру с подписью «В Internet никто не знает о том, что ты собака». Анонимность по-прежнему имеет место, но для большинства из нас ориентация Internet на использование каталогов представляется несомненным благом.

ПЕРВЫЙ КАТАЛОГ INTERNET

Когда появилась ARPAnet — сеть министерства обороны, предшественница современного Internet, — каталогам не придавалось большого значения. Одна из причин состояла в том, что число подключенных хостов было весьма скромным (около 25 в 1971 году).

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

Протокол управления сетью ARPAnet (Network Control Protocol, NCP) использовал алфавитно-цифровые мнемонические обозначения для идентификации некоторых сервисов (например, MIT-Multics обозначал сервис Multics в MIT). В действительности мнемонические обозначения идентифицировали только точки подключения к сети. Если предоставляющий сервис компьютер перемещался куда-либо, то, считайте, вам не повезло.

К счастью, когда Винтон Серф и другие в начале 70-х разрабатывали TCP/IP, они учли необходимость идентификации хостов независимо от точки подключения сети или MAC-адреса. Результатом стало появление IP-адресов, представляющих собой 32-разрядное число, разбитое на две части: номер сети и номер хоста.

С превращением ARPAnet в Internet сеть получила свой первый каталог. Это была таблица хостов — простой текстовый файл, содержащий список всех используемых IP-адресов вместе с присвоенными каждому из них буквенными именами. При добавлении новых хостов и имен администратор отправлял информацию об изменениях по электронной почте в Информационный центр сети (Network Information Center, NIC). Затем NIC вносил изменения в главную таблицу, HOSTS.TXT, которую пользователям приходилось периодически загружать, если они не хотели ориентироваться на устаревшую информацию.

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

Для решения этой проблемы Пол Мокапетрис и другие предложили в начале 80-х систему именования доменов (Domain Name System, DNS). Одним из новшеств DNS стало введение иерархического пространства имен, в котором имена разделялись точками для обозначения границ между уровнями иерархии (как, например, в гипотетическом адресе Jonanthan_Angel.Editorial.NetworkMagazine.SanFrancisco.mfi.com).

Как написал Мокапетрис в RFC 1034, «подходы, где предпринимается попытка составить непротиворечивую копию всей базы данных, становятся все труднее и накладнее в реализации, поэтому их следует избегать». Таким образом, DNS стала распределенной базой данных, в которую данные вносятся локально, но доступны глобально. Серверы имен представляют собой программы, где хранится полная информация о части глобального дерева доменов (обычно об административной единице, известной как зона). Местный сервер имен полностью отвечает за свою зону и может предоставить всю локальную информацию об именах и адресах без обращения к какому-либо другому серверу. Прочие запросы выполняются специальным программным агентом (resolver), обращающимся к серверам имен вверх по дереву.

Естественно, локальные серверы имен кэшируют результаты запросов, так что если какой-либо пользователь в компании уже посылал запрос на нахождение www.googolplex.com, то IP-адрес этого хоста может быть без задержки предоставлен всем остальным. Кроме того, серверы имен обмениваются информацией между собой независимо от запросов пользователей. Таким образом, хотя хранимые в различных уголках земного шара данные об идентичных частях дерева доменных имен и могут различаться в какой-то момент, все же со временем эта информация оказывается согласованной.

Подавляющее большинство серверов DNS по-прежнему представляет собой машины под управлением UNIX с Berkeley Internet Name Daemon (Bind). Демон Bind синхронизирует информацию серверов имен посредством передачи зон только в предопределенные интервалы времени. Однако в восьмой версии Bind вводит команду Notify, с помощью которой сервер может информировать остальных о том, что зона была изменена (см. RFC 1996).

СКАЖИ, КТО ТЫ?

Появление DNS упростило процедуру отслеживания IP-адресов. Однако IP-адреса никогда не были хорошим способом проверки идентичности.

Одна из причин, о которой мы упоминали ранее, состоит в том, что один многопользовательский хост мог иметь один разделяемый многими пользователями IP-адрес. Другая причина — в том, что один хост мог иметь несколько IP-адресов, если он подключался к Internet с помощью нескольких разных интерфейсных плат. Таким образом, разные IP-адреса могли относиться к одному и тому же хосту, пользователю или процессу.

Достижения в области технологии еще более усугубили положение дел. Например, в 1990 году появился Point-to-Point Protocol (PPP, см. RFC 1171). В случае PPP IP-адрес присваивается хосту только на время коммутируемого соединения. Хуже того, выделенные серверу PPP адреса могут использоваться повторно, поэтому они не имеют реального значения.

Во временных сетях устройства без постоянной памяти, такие, как маршрутизаторы, принтеры или X-терминалы, могли получить IP-адрес при запуске с помощью протокола начальной загрузки (Bootstrap Protocol, BOOTP). На своем сервере BOOTP администраторы сетей вели таблицу, где указывался аппаратный адрес каждого устройства вместе с выделенным ему IP-адресом.

Однако все это еще цветочки. Появление протокола динамической конфигурации хостов (Dynamic Host Configuration Protocol, DHCP) в 1993 году, с одной стороны, повысило удобство, а с другой — увеличило неопределенность. В данном случае адреса из «арендуемого пула», т. е. группы IP-адресов, присваиваются клиентам в порядке их обращения и предоставляются корпоративными серверами DHCP. В принципе, IP-адреса могут назначаться на длительный срок, как следует из определения «арендуемый», но на это не следует полагаться. (Отсюда опасения пользователей относительно использования серверов на цифровых абонентских линиях (Digital Subscriber Line, DSL) или в кабельных сетях, в которых IP-адреса выделяются с помощью DHCP.) Более подробную информацию о DHCP можно почерпнуть из RFC 1531 и статьи «DHCP и DNS: динамичный дуэт» из LAN №6 за 1997 год.

Предложенная в RFC 2136 в августе 1997 года Dynamic DNS (DDNS) описывает взаимодействие между сервером DHCP и сервером DNS. С ее помощью сервер DHCP может вносить изменения на выполняющемся сервере имен, а тот в свою очередь может извещать о них другие серверы имен. При известном имени (например, rover.networkmagazine.com) DDNS позволяет найти данный хост, даже если его IP-адрес меняется ежедневно.

Microsoft не поддерживает DDNS в Windows 95/98 или NT 4.0, хотя она может быть реализована посредством программного обеспечения независимых поставщиков, такого, как Meta IP от Check Point Software Technologies или Shadow IPserver от Network Telesystems. DDNS будет, однако, поддерживаться в Windows 2000, и в этом отношении Windows 2000 не будет отставать от NetWare 5.0.

Ввиду важности вопросов защиты в DDNS RFC 2137 описывает схему организации защищенных обновлений DNS с помощью цифровых подписей. К сожалению, она пока не реализована ни в Windows 2000, ни в NetWare 5, ни в Bind 8; скорее всего, ее поддержка появится в следующей редакции Bind.

Записи DNS содержат информацию о Mail Exchange (ME) для идентификации адреса сервера, принимающего электронную почту для данного домена. Однако любая дополнительная информация о хостах, например о местонахождении и серийном номере, может храниться только в виде простых комментариев.

«Люди воспринимают DNS как готовый каталог и надеются, что он может решить и другие их проблемы, — говорит Тим Хоус, вице-президент и ведущий специалист отдела серверных продуктов Netscape Communications. — Я думаю, такой подход ошибочен: лучшее — враг хорошего».

«DNS — это отличный специализированный каталог и важный формообразующий компонент Internet, — добавляет Самм ДиСтазио, директор по стратегическому рыночному планированию в Novell. — DNS по отношению к другим каталогам — как ступица в колесе, но при этом они более приспособлены для управления выходящей за рамки DNS информацией».

LDAP ВЫХОДИТ НА СЦЕНУ

Наиболее полезные каталоги хранились и продолжают храниться в нестандартном виде такими приложениями, как Lotus Notes, cc:Mail и Microsoft Exchange. Единственный безотказный способ узнать чей-либо адрес электронной почты — это снять телефонную трубку и позвонить ему.

Однако ситуация постепенно меняется благодаря появлению в 1993 г. упрощенного протокола доступа к каталогу (Lightweight Directory Access Protocol, LDAP). Первая служба каталога общего назначения для сообщества пользователей TCP/IP, LDAP, позволяет практически любому приложению извлекать информацию из каталогов стандартным образом. (Дополнительную информацию об LDAP смотри в статье «Служба каталогов: в единстве — сила» в этом номере LAN.)

Сам по себе LDAP — это не каталог и не файловая система. Он не может заменить собой двухэтапную запись данных, истинную реляционную структуру или язык запросов наподобие SQL. По словам Тима Хоуза, создателя LDAP (вместе со Стивом Килле и Уэнджиком Йенгом): «Это протокол доступа к каталогу. Но я предпочитаю рассматривать его как нечто большее, потому что LDAP содержит также информационную модель, способ именования, API и многое другое».

В частности, LDAP 3 (RFC 2251) описывает информационную модель, определяемую в терминах элементов со специфическими атрибутами и значениями, регламентирующими то, какого рода данные могут храниться и как они себя ведут. Он также имеет схему, определяющую стандартные значения и атрибуты для представления объектов реального мира — людей, организаций, стран.

Функциональная модель LDAP определяет для клиентов стандартные методы доступа, модификации и манипулирования данными в каталоге. Она вводит девять базовых операций: добавление, удаление, модификацию, установление связи, отмену связи, поиск, сравнение, изменение отличительного имени и отказ.

Протокол LDAP как таковой определяет, как его модели и функции отображаются на TCP/IP. Наконец, LDAP API предоставляет стандартный набор вызовов и определений функций, которые программы, написанные на C/C++, Java, JavaScript, Perl и других языках, могут использовать для доступа к каталогу.

В настоящее время работа ведется также над стандартизацией представления в LDAP информации DNS (см., в частности, RFC 2247 и 2377).

DNS использует транспорт без установления соединения, в то время как LDAP ориентирован на установление соединения с принятием определенных мер безопасности. Серверы белых страниц иногда разрешают анонимный доступ, но пользователей можно также заставить идентифицировать себя, прежде чем им будет предоставлена информация из каталога. В случае Netscape Directory Server, например, пароли пользователей могут храниться на сервере в виде открытого текста или необратимого хэша. Кроме того, соединения LDAP могут быть защищены с помощью Secure Sockets Layer (SSL).

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

Каталоги могут быть организованы множеством разных способов и содержать самую разную информацию. Например, в одной компании база данных электронной почты может содержать изображения каждого пользователя в формате JPEG и дату его поступления на работу, тогда как в другой — нет. Поэтому для того, чтобы клиент LDAP мог взаимодействовать с сервером, он должен знать, как организованы данные на этом сервере, что может представлять серьезную проблему.

Что касается LDAP 3 (RFC 2251), то в нем это стало возможным. LDAP 3-совместимый сервер каталога может сообщать информацию о своей схеме другому серверу или клиенту. Помимо «публикации схемы» LDAP 3 вводит также класс административных клиентов, способных модифицировать схему на лету.

Однако LDAP имеет один серьезный пробел. Чтобы служба каталогов была действительно глобальной, наподобие DNS, она должна предусматривать стандартный способ тиражирования данных между серверами. Это необходимо как из соображений производительности, так и для обеспечения избыточности.

В настоящее время LDAP предлагает формат обмена данными LDAP (LDAP Data Interchange Format, LDIF) — простой текстовый формат для представления элементов в каталоге и, факультативно, изменений в этих элементах. Импорт и экспорт файлов LDAP — либо вручную, либо с помощью таких средств, как сценарии на Perl, — позволяет, в принципе, синхронизировать несколько каталогов между собой. Однако, как указывает Хоуз, во многих случаях хотелось бы иметь более надежную связь.

Поэтому IETF создала рабочую группу для определения стандартов на автоматическое оперативное тиражирование под названием LDAP Duplication/Replication/Updating (LDUP). Она опубликовала несколь-ко относящихся к этой теме проектов стандартов Internet, окончательные же версии должны появиться к концу 1999 года.

Тиражирование каталога может оказаться опасным занятием, если там, куда он копируется, не уделяют ему такого же внимания, как вы. Группа расширений LDAP (LDAP Extension, LDAPEXT) работает над определением стандартной модели контроля доступа и уже опубликовала ряд проектов. LDAPEXT занимается также вопросом начальной загрузки, т. е. тем, как клиент может определить местонахождение сервера LDAP, к которому он мог бы обратиться. Кроме того, она разрабатывает механизм для передачи информации LDAP по транспорту UDP без установления соединения.

LDAP НА РЫНКЕ

Один из главных вопросов о любом LDAP-совместимом продукте — какую роль он выполняет: клиента, сервера или обе. Большинство серверов обмена сообщениями предлагают шлюзы LDAP в свои внутренние нестандартные каталоги. Некоторые даже превратились в клиентов LDAP, переложив задачу управления каталогом на сетевую ОС или другой каталог.

Если каталоги для обмена сообщениями переходят на LDAP как на стандартный протокол доступа, то разработчики сетевых ОС, в определенной мере, идут своим собственным путем. С одной стороны, NetWare 5 предлагает встроенный интерфейс LDAP 3, а с другой — данные DNS и DHCP хранятся в NDS. Windows 2000 задействует DHCP, DNS и LDAP, а также автоматически регистрирует хосты с помощью DDNS. Однако с переходом сетевых ОС на стандарты Internet они должны будут чем-то отличаться от конкурентов, например нестандартными расширениями.

«Нас, в Netscape, это не очень заботит, — говорит Хоуз. — Один каталог не подойдет для всех задач, и Active Directory, и NDS решают иные проблемы, нежели каталоги для Extranet».

«В мире Extranet каталоги обеспечивают взаимодействие между организацией и ее клиентами и поставщиками», — говорит Стив Келле, президент Messaging Direct (http://www.messagingdirect.com). Однако он предупреждает: «Сегодня мы имеем одну DNS, и в конечном итоге мы будем иметь один каталог LDAP. То, как он реализуется сейчас, ведет только к фрагментированию». В конце концов, по мнению Келле, тенденции объединения возобладают, но это займет от 5 до 10 лет.

Келле, Хоуз и ДиСтазио из Novell соглашаются с тем, что каталоги будущего — находящиеся у провайдеров Internet, как DNS сегодня, — приведут к коренным изменениям в Internet. По мнению ДиСтазио, это будет механизм взаимоотношений, который заменит простое соединение на взаимодействие «один на один». «Люди получат возможность использовать свою персональную информацию в качестве оборотного средства», — говорит он. (Об идее персональной информации и хранения индивидуальных мандатов смотри во врезке «В ожидании цифрового меня».)

СБОРНАЯ СОЛЯНКА

В краткосрочной перспективе меню для Internet выглядит как сборная солянка — пикантная смесь из LDAP, DNS, X.500, каталогов сетевых ОС и метакаталогов. Такие продукты, как VIA Server от Zoomit и Synchronicity от NetVision, будут пользоваться возрастающим спросом для синхронизации множества каталогов или в целях правильного объединения каталогов, когда один и тот же пользователь зарегистрирован в них под разными именами. В мае 1999 года IBM представила службу метакаталога SecureWay, которой отводится важная роль в предложениях этой компании.

«Метакаталог не следует воспринимать как конечное хранилище, где будет собрана вся информация, — предостерегает Хоуз. — Это не столько конечный пункт, сколько дорога к нему».

Одно ясно: когда большинство пользователей имеет в своем распоряжении несколько устройств — настольную систему, портативный компьютер, PDA, сетевой принтер, телефон на базе IP — каждый со своим собственным IP-адресом, никто не будет даже надеяться определить личность владельца на основании только 32-разрядного числа. Перекличка обернулась гораздо более трудной задачей.

В ожидании цифрового меня

На конференции BrainShare в марте 1999 года Novell поразила участников объявлением инициативы, нацеленной непосредственно на потребителей, а не на сетевых администраторов. Получившая название digitalme (да, именно так, все буквы строчные), она стремится привлечь интерес обычного Джо Модема к NDS и LDAP, играя на его озабоченности конфиденциальностью. Реализация данной инициативы должна позволить пользователям Internet защищенным образом хранить и распространять информацию о своей персоне — имена и пароли, адреса электронной почты, номера кредитных карт — решая, кто что имеет право ее видеть, посредством использования цифровых meCards.

Но после того как в «Нью-Йорк Таймс» была опубликована статья на эту тему, ничего больше о digitalme не было слышно. Возможно, однако, что вскоре мы услышим кое-что новое: когда эта статья готовилась к печати, сервер http://www.digitalme.com находился на реконструкции. Пока же мы можем сказать, что digitalme будет работать совместно с NDS 8 и BorderManager, но при этом сочетать услуги каталога и посредника несколько иным образом.

Например, пароли и «плюшки» для всех серверов Web будут перемещены с локального ПК пользователя в каталог, находящийся под контролем посредника под названием «брокер персоналий». После первоначальной регистрации пользователя на сервере Web посредник впоследствии будет аутентифицировать его автоматически. Закладки браузера будут, что весьма удобно, доступны, где бы пользователь ни находился.

Самм ДиСтазио, директор по стратегическому рыночному планированию в Novell, полагает, что персональная информация будет храниться «у тех провайдеров Internet, кто захочет предлагать иные услуги, помимо просто установления соединения», хотя она может также размещаться и в банках или у других заслуживающих доверия информационных брокеров. ДиСтазио называет эти накопители информации «инфопосредниками». В некоторых случаях, и только с разрешения пользователя, такие узлы, как Amazon.com, могут обращаться для получения информации непосредственно к инфопосредникам. В других случаях агент-посредник digitalme будет перехватывать формы, заполнять их за пользователя и представлять заполненную форму для одобрения.

Ресурсы Internet

Интересующий вас RFC можно прочесть на http://www.ietf.org/rfc/rfcXXXX.txt/, где вместо XXXX необходимо подставить номер RFC (включая нули, если необходимо, вместо одной или двух первых цифр).

О DNS

RFC 875 («Шлюзы, архитектуры и слонопотамы») и RFC 1498 («Об именовании и связывании сетевых адресатов») содержат любопытную историческую информацию. Написанный Полом Мокапетрисом RFC 1034 представляет собой хорошее введение в DNS.

Касающиеся DNS документы RFC и перечни ресурсов можно найти на http://www.dns.net/rfc и http://www.dns.net/dnsrd/.

Check Point Software Technologies предлагает статью «Управление IP-адресами: прошлое, настоящее и будущее» на http://www.metainfo.com/products/understand.cfm/.

Хартия рабочей группы Dynamic Host Configuration опубликована на http://ietf.org/html.charters/dhc-charter.html.

О LDAP

«Путеводитель по LDAP и ответы на часто задаваемые вопросы» Джеффа Ходжеса можно найти на http://www.kingsmountain.com. Еще одну подборку ответов на часто задаваемые вопросы по LDAP можно прочитать на http://www.critical-angle.com/ldapworld/ldapfaq.html.

Хартия рабочей группы LDAP Duplication/Replication/Updating (LDUP) опубликована на http://ietf.org/html.charters/ldup-charter.html.

Хартия рабочей группы LDAP Extension (LDAPEXT) опубликована на http://ietf.org/html.charters/ldapext-charter.html.

Относящиеся к почтовым стандартам Internet списки рассылки, включая несколько посвященных LDAP, располагаются на сервере Internet Mail Consortium по адресу: http://www.imc.org.

О каталогах вообще

Novell предлагает «Полную таксономию службы каталогов» на http://www.novell.com/corp/strategy/fsd/fsd_taxonomy.html.

«Сравнение каталогов и реляционных баз данных для предприятий» — одна из нескольких интересных статей на http://www.messagingdirect.com/directory.html.