Сеть с нулевой конфигурацией ( zeroconf ) — это набор технологий, которые автоматически создают пригодную для использования компьютерную сеть на основе Internet Protocol Suite (TCP/IP) при соединении компьютеров или сетевых периферийных устройств. Она не требует ручного вмешательства оператора или специальных серверов конфигурации. Без zeroconf администратор сети должен настраивать сетевые службы , такие как протокол динамической конфигурации хоста (DHCP) и система доменных имен (DNS), или вручную настраивать сетевые параметры каждого компьютера.
Zeroconf построен на трех основных технологиях: автоматическое назначение числовых сетевых адресов для сетевых устройств, автоматическое распределение и разрешение имен хостов компьютеров и автоматическое определение местоположения сетевых служб , таких как печатающие устройства.
Компьютерные сети используют числовые сетевые адреса для идентификации конечных точек связи в сети участвующих устройств. Это похоже на телефонную сеть , которая назначает строку цифр для идентификации каждого телефона. В современных сетевых протоколах информация, которая должна быть передана, делится на серию сетевых пакетов . Каждый пакет содержит исходный и конечный адреса для передачи. Сетевые маршрутизаторы проверяют эти адреса, чтобы определить наилучший сетевой путь для пересылки пакета данных на каждом шаге к его месту назначения.
Подобно тому, как телефоны маркировались своим номером телефона, в ранних сетях было обычным делом прикреплять адресную этикетку к сетевым устройствам. Динамическая природа современных сетей, особенно жилых сетей, в которых устройства включаются только при необходимости, требует динамических механизмов назначения адресов, которые не требуют участия пользователя для инициализации и управления. Эти системы автоматически присваивают себе общие имена, выбранные либо производителем оборудования, например, марка и номер модели, либо выбранные пользователями для идентификации своего оборудования. Затем имена и адреса автоматически вводятся в службу каталогов .
Ранние компьютерные сети были построены на технологиях телекоммуникационных сетей, и поэтому протоколы, как правило, делились на две группы: те, которые предназначались для соединения локальных устройств в локальную сеть (LAN), и те, которые предназначались в первую очередь для дальней связи. Системы глобальной сети (WAN) последних, как правило, имели централизованную настройку, где администратор сети вручную назначал адреса и имена. Системы LAN, как правило, обеспечивали большую автоматизацию этих задач, так что новое оборудование можно было добавлять в LAN с минимальным вмешательством оператора и администратора.
Ранним примером системы локальной сети с нулевой конфигурацией является AppleTalk , протокол, представленный Apple Inc. для ранних компьютеров Macintosh в 1980-х годах. Компьютеры Mac, а также другие устройства, поддерживающие этот протокол, можно было добавить в сеть, просто подключив их; вся дальнейшая настройка была автоматизирована. Сетевые адреса автоматически выбирались каждым устройством с помощью протокола, известного как AppleTalk Address Resolution Protocol (AARP), в то время как каждая машина создавала собственную локальную службу каталогов с помощью протокола, известного как Name Binding Protocol (NBP). NBP включал не только имя, но и тип устройства и любую дополнительную информацию, предоставленную пользователем, такую как его физическое местоположение или доступность. Пользователи могли искать любое устройство в сети с помощью приложения Chooser , которое фильтровало имена на основе типа устройства.
В сетях Интернет-протокола (IP) база данных системы доменных имен для сети изначально поддерживалась вручную администратором сети. Попытки автоматизировать обслуживание этой базы данных привели к внедрению ряда новых протоколов, предоставляющих автоматизированные услуги, такие как протокол динамической конфигурации хоста (DHCP).
Хостам в сети должны быть назначены IP-адреса , которые однозначно идентифицируют их для других устройств в той же сети. В некоторых сетях есть центральный орган, который назначает эти адреса по мере добавления новых устройств. Были введены механизмы для автоматического выполнения этой задачи, и как IPv4, так и IPv6 теперь включают системы для автоматической настройки адреса , что позволяет устройству определять безопасный адрес для использования с помощью простых механизмов. Для локальной адресации IPv4 использует специальный блок 169.254.0.0 / 16 , [1] в то время как хосты IPv6 используют префикс fe80:: / 10. Чаще всего адреса назначаются DHCP-сервером , часто встроенным в обычное сетевое оборудование, такое как компьютерные хосты или маршрутизаторы.
Большинство хостов IPv4 используют адресацию локальной связи только в качестве последнего средства, когда DHCP-сервер недоступен. В противном случае хост IPv4 использует свой назначенный DHCP адрес для всех коммуникаций, глобальных или локальных. Одна из причин заключается в том, что хосты IPv4 не обязаны поддерживать несколько адресов на интерфейс, хотя многие это делают. Другая причина заключается в том, что не каждый хост IPv4 реализует распределенное разрешение имен (например, многоадресную DNS ), поэтому обнаружение автоматически настроенного локального адреса связи другого хоста в сети может быть затруднено. Обнаружение назначенного DHCP адреса другого хоста требует либо распределенного разрешения имен, либо одноадресного DNS-сервера с этой информацией; в некоторых сетях есть DNS-серверы, которые автоматически обновляются с помощью назначенной DHCP информации о хосте и адресе.
Хосты IPv6 должны поддерживать несколько адресов на интерфейс; более того, каждый хост IPv6 должен настраивать локальный адрес ссылки, даже если доступны глобальные адреса. Хосты IPv6 могут дополнительно самостоятельно настраивать дополнительные адреса при получении сообщений с объявлениями маршрутизатора, тем самым устраняя необходимость в DHCP-сервере. [2]
Хосты IPv4 и IPv6 могут случайным образом генерировать специфичную для хоста часть автоматически настроенного адреса. Хосты IPv6 обычно объединяют префикс длиной до 64 бит с 64-битным EUI-64, полученным из назначенного на заводе 48-битного MAC-адреса IEEE . Преимущество MAC-адреса в том, что он является глобально уникальным, что является основным свойством EUI-64. Стек протокола IPv6 также включает обнаружение дубликатов адресов для избежания конфликтов с другими хостами. В IPv4 этот метод называется автонастройкой локального адреса . [1] Однако Microsoft называет это автоматической частной IP-адресацией (APIPA) [3] или автоматической настройкой протокола Интернета ( IPAC ). Эта функция поддерживается в Windows, по крайней мере, с Windows 98. [4]
Интернет-протоколы используют IP-адреса для связи, но их нелегко использовать людям; в частности, IPv6 использует очень длинные строки цифр, которые нелегко ввести вручную. Чтобы решить эту проблему, Интернет уже давно использует DNS, который позволяет связывать понятные человеку имена с IP-адресами и включает код для поиска этих имен в иерархической системе баз данных. Пользователи вводят доменные имена, такие как example.org , которые программное обеспечение DNS компьютера ищет в базах данных DNS для получения IP-адреса, а затем передает этот адрес в стек протоколов для дальнейшей связи. [5]
Поиск адреса с помощью DNS требует знания IP-адреса DNS-сервера. Обычно это достигалось путем ввода адреса известного сервера в поле на одном из устройств в сети. В ранних системах это обычно требовалось на каждом устройстве, но теперь это было перемещено на один уровень вверх в иерархии к DHCP-серверам или широкополосным устройствам, таким как кабельные модемы , которые получают эту информацию от своего интернет-провайдера . Это снизило требования к администрированию на стороне пользователя и обеспечивает ключевой элемент доступа с нулевой конфигурацией. [5]
DNS был предназначен для предоставления единых имен группам устройств в пределах одной административной области, например example.org , предоставляемых службой имен. Назначение адреса локальному устройству, например, thirdfloorprinter.example.org , обычно требует доступа администратора к DNS-серверу и часто выполняется вручную. Кроме того, традиционные DNS-серверы не должны автоматически корректировать изменения в конфигурации. Например, если принтер перемещается с одного этажа на другой, ему может быть назначен новый IP-адрес локальным DHCP-сервером. [5]
Для решения проблемы автоматической настройки Microsoft реализовала службу имен NetBIOS , частью которой является служба обозревателя компьютеров , уже входящая в состав Microsoft Windows for Workgroups 3.11 [6] еще в 1992 году. Служба имен NetBIOS не требует настройки в сетях с одной подсетью и может использоваться совместно с сервером WINS или сервером Microsoft DNS, поддерживающим безопасную автоматическую регистрацию адресов. Эта система имеет небольшие, но не нулевые, накладные расходы на управление даже в очень крупных корпоративных сетях. Протоколы, которые может использовать NetBIOS, являются частью набора открытых протоколов Server Message Block (SMB) [6] , которые также доступны в Linux и iOS, хотя Windows обычно поддерживает более широкий диапазон так называемых диалектов, которые могут быть согласованы между клиентами Windows, поддерживающими их. Например, службы обозревателя компьютеров, работающие на серверных операционных системах или более поздних версиях Windows, выбираются в качестве так называемого главного браузера по сравнению с теми, которые не работают на серверной операционной системе или работают на более старых версиях Windows. [6]
В 2000 году Билл Мэннинг и Билл Вудкок описали Multicast Domain Name Service [7], которая породила реализации Apple и Microsoft. Обе реализации очень похожи. Multicast DNS (mDNS) от Apple опубликована как предложение по стандартизации RFC 6762, в то время как Link-local Multicast Name Resolution (LLMNR) от Microsoft опубликована как информационный RFC 4795. LLMNR включена в каждую версию Windows, начиная с Windows Vista [8] и действует как параллельная альтернатива для NetBIOS Name Service от Microsoft по IPv4 и как замена по IPv6, поскольку NetBIOS недоступен по IPv6. Реализация Apple доступна как служба Bonjour с 2002 года в Mac OS X v10.2. Реализация Bonjour (mDNSResponder) доступна по лицензии Apache 2 Open Source License [9] и включена в Android Jelly Bean и более поздние версии [10] по той же лицензии.
Использование служб NetBIOS или LLMNR в Windows по сути является автоматическим, поскольку использование стандартных API-интерфейсов DNS-клиента приведет к использованию либо NetBIOS, либо LLMNR в зависимости от того, какое имя разрешается (является ли имя локальным именем или нет), действующей конфигурации сети (например, действующих суффиксов DNS) и (в корпоративных сетях) действующих политик (отключены ли LLMNR или NetBIOS), хотя разработчики могут обойти эти службы для поиска отдельных адресов.
Протоколы mDNS и LLMNR имеют небольшие различия в подходе к разрешению имен. mDNS позволяет сетевому устройству выбирать доменное имя в локальном пространстве имен DNS и объявлять его с помощью специального многоадресного IP-адреса. Это вводит специальную семантику для домена верхнего уровня local , [11] что некоторые члены IETF считают проблемой. [12] Текущий проект LLMNR позволяет сетевому устройству выбирать любое доменное имя, что некоторые члены IETF считают угрозой безопасности. [13] mDNS совместим с DNS-SD, как описано в следующем разделе, в то время как LLMNR — нет. [14]
Службы имен, такие как mDNS, LLMNR и другие, не предоставляют информацию о типе устройства или его статусе. Например, пользователь, ищущий ближайший принтер, может столкнуться с трудностями, если принтеру присвоено имя «Боб». Обнаружение служб предоставляет дополнительную информацию об устройствах. Обнаружение служб иногда сочетается со службой имен , как в протоколе привязки имен Apple и NetBIOS Microsoft .
NetBIOS в Windows поддерживает отдельные хосты в сети для объявления служб, таких как общие папки и принтеры. Он также поддерживает, например, сетевой принтер для объявления себя как хоста, совместно использующего принтерное устройство и любые связанные службы, которые он поддерживает. В зависимости от того, как устройство подключено (напрямую к сети или к хосту, который его совместно использует) и какие протоколы поддерживаются. Однако клиенты Windows, подключающиеся к нему, могут предпочесть использовать SSDP или WSD с помощью NetBIOS. NetBIOS является одним из поставщиков в Windows, реализующих более общий процесс обнаружения, называемый обнаружением функций , который включает встроенных поставщиков для PnP, Registry, NetBIOS, SSDP и WSD [15], из которых первые два являются только локальными, а последние три поддерживают обнаружение сетевых устройств. Ни один из них не требует какой-либо настройки для использования в локальной подсети. NetBIOS традиционно поддерживался только в дорогих принтерах для корпоративного использования, хотя некоторые принтеры начального уровня с Wi-Fi или Ethernet поддерживают его изначально, что позволяет использовать принтер без настройки даже в очень старых операционных системах.
Web Services Dynamic Discovery ( WS-Discovery ) — это техническая спецификация, которая определяет протокол многоадресного обнаружения для поиска служб в локальной сети. Он работает через порт TCP и UDP 3702 и использует многоадресный IP-адрес 239.255.255.250 . Как следует из названия, фактическое взаимодействие между узлами осуществляется с использованием стандартов веб-служб, в частности SOAP-over-UDP . Windows поддерживает его в форме Web Services for Devices и Devices Profile for Web Services . Многие устройства, такие как принтеры HP и Brother, поддерживают его.
DNS-SD (DNS Service Discovery[16]) позволяет клиентам обнаруживать именованный список экземпляров служб и разрешать эти службы в имена хостов с помощью стандартных DNS-запросов. Спецификация совместима с существующим одноадресным DNS-сервером и клиентским программным обеспечением, но работает одинаково хорошо с mDNS в среде с нулевой конфигурацией. Каждый экземпляр службы описывается с помощью записи DNS SRV[17]и DNS TXT[18]. Клиент обнаруживает список доступных экземпляров для заданного типа службы, запрашивая запись DNS PTR[18]имени этого типа службы; сервер возвращает ноль или более имен в форме <Service>.<Domain>, каждое из которых соответствует паре записей SRV/TXT.Запись SRVразрешается в доменное имя, предоставляющее экземпляр, в то время как TXT может содержать параметры конфигурации, специфичные для службы. Затем клиент может разрешить запись A/AAAA для доменного имени и подключиться к службе.
Типы услуг предоставляются по принципу «первым пришел — первым обслужен». Реестр типов услуг изначально поддерживался DNS-SD.org, [16] но с тех пор был объединен с реестром IANA для записей DNS SRV. [19]
В 1997 году Стюарт Чешир предложил адаптировать зрелый протокол привязки имен Apple к сетям IP, чтобы решить проблему отсутствия возможности обнаружения служб. [20] Впоследствии Чешир присоединился к Apple и стал автором проектов предложений IETF для mDNS и обнаружения служб на основе DNS, поддерживая переход от AppleTalk к сетям IP. В 2002 году Apple объявила о реализации обоих протоколов под названием Rendezvous [21] (позже переименованный в Bonjour). Впервые он был включен в Mac OS X 10.2 , заменив протокол определения местоположения служб (SLP), используемый в 10.1 . [ необходима ссылка ] В 2013 году предложения были ратифицированы как RFC 6762 [22] и RFC 6763. [23]
mDNS использует пакеты, похожие на одноадресные DNS , для разрешения имен хостов, за исключением того, что они отправляются по многоадресной ссылке. Каждый хост прослушивает порт mDNS, 5353, передаваемый на известный многоадресный адрес, и разрешает запросы на запись DNS своего имени хоста .local (например, A , AAAA , CNAME ) на свой IP-адрес. Когда клиенту mDNS необходимо разрешить локальное имя хоста в IP-адрес, он отправляет запрос DNS на это имя на известный многоадресный адрес; компьютер с соответствующей записью A/AAAA отвечает своим IP-адресом. Многоадресный адрес mDNS — 224.0.0.251 для IPv4 и ff02::fb для локальной адресации IPv6.
DNS Service Discovery или DNS-SD запросы также могут быть отправлены с использованием mDNS для получения DNS-SD с нулевой конфигурацией. [24] Это использует записи DNS PTR , SRV, TXT для объявления экземпляров типов сервисов, доменных имен для этих экземпляров и дополнительных параметров конфигурации для подключения к этим экземплярам. Но записи SRV теперь могут разрешаться в доменные имена .local , которые mDNS может разрешать в локальные IP-адреса.
DNS-SD используется продуктами Apple, большинством сетевых принтеров, многими дистрибутивами Linux, включая Debian и Ubuntu , [25] и рядом сторонних продуктов для различных операционных систем. Например, многие сетевые приложения OS X , написанные Apple, включая Safari , iChat и Messages , могут использовать DNS-SD для поиска близлежащих серверов и одноранговых клиентов. Windows 10 включает поддержку DNS-SD для приложений, написанных с использованием JavaScript. [26] Отдельные приложения могут включать свою собственную поддержку в более старых версиях операционной системы, так что большинство клиентов мгновенного обмена сообщениями и VoIP в Windows поддерживают DNS-SD. Некоторые дистрибутивы Unix , BSD и Linux также включают DNS-SD. Например, Ubuntu поставляет Avahi , реализацию mDNS/DNS-SD, в своем базовом дистрибутиве.
UPnP имеет несколько компонентов протокола, предназначенных для обнаружения служб.
Simple Service Discovery Protocol (SSDP) — это протокол UPnP, используемый в Windows XP и более поздних версиях. SSDP использует уведомления HTTP, которые предоставляют URI типа службы и уникальное имя службы (USN). Типы служб регулируются руководящим комитетом Universal Plug and Play. SSDP поддерживается многими производителями принтеров, NAS и устройств, такими как Brother. Он поддерживается определенными марками сетевого оборудования и многими устройствами межсетевого экрана SOHO , где хост-компьютеры за ним могут пробивать дыры для приложений. Он также используется в домашних кинотеатрах ПК для упрощения обмена медиаданными между хост-компьютерами и медиацентром.
Digital Living Network Alliance (DLNA) — еще один набор стандартов, использующий UPnP для обнаружения сетевых устройств. DLNA имеет длинный список известных производителей, выпускающих такие устройства, как телевизоры, устройства NAS и т. д., которые его поддерживают. DLNA поддерживается всеми основными операционными системами. Обнаружение сервисов DLNA накладывается поверх SSDP.
SLP поддерживается сетевыми принтерами Hewlett-Packard , Novell и Sun Microsystems . SLP описан в RFC 2608 и RFC 3224, а реализации доступны как для Solaris , так и для Linux .
AllJoyn — это программный стек с открытым исходным кодом для множества устройств, от устройств IoT до полноразмерных компьютеров, для обнаружения и управления устройствами в сетях (Wifi, Ethernet) и других соединениях (Bluetooth, ZigBee и т. д.). Он использует mDNS и HTTP поверх UDP и других протоколов.
RFC 2608, стандарт SLP для определения того, где получить услуги, был опубликован в июне 1999 года рабочей группой SVRLOC IETF. [27]
RFC 3927, стандарт выбора адресов для сетевых элементов, был опубликован в марте 2005 года рабочей группой IETF Zeroconf. В группу вошли представители Apple, Sun и Microsoft. [28]
LLMNR был представлен для официального принятия в рабочей группе IETF DNSEXT, однако не получил консенсуса и поэтому был опубликован как информационный RFC 4795 в январе 2007 года. [29]
После того, как LLMNR не стал стандартом Интернета, и учитывая, что mDNS/DNS-SD используется гораздо шире, чем LLMNR, IETF попросила Apple представить спецификации mDNS/DNS-SD для публикации в качестве информационного RFC. [ необходима ссылка ]
В феврале 2013 года mDNS и DNS-SD были опубликованы как предложения по стандартизации RFC 6762 и RFC 6763.
Поскольку mDNS работает по другой модели доверия, чем одноадресный DNS — доверяя всей сети, а не назначенному DNS-серверу, он уязвим для атак спуфинга любой системой в пределах того же широковещательного домена . Как SNMP и многие другие протоколы управления сетями, он также может использоваться злоумышленниками для быстрого получения подробных знаний о сети и ее машинах. [30] Из-за этого приложения должны по-прежнему аутентифицировать и шифровать трафик к удаленным хостам (например, через RSA , SSH и т. д.) после обнаружения и разрешения их через DNS-SD/mDNS. LLMNR страдает от аналогичных уязвимостей. [31]
Bonjour от Apple, использует mDNS и DNS Service Discovery. Apple изменила свою предпочтительную технологию zeroconf с SLP на mDNS и DNS-SD между Mac OS X 10.1 и 10.2 , хотя SLP продолжает поддерживаться Mac OS X.
mDNSResponder от Apple имеет интерфейсы для C и Java [32] и доступен на BSD, Apple Mac OS X, Linux, других операционных системах на базе POSIX и MS Windows. Загрузки для Windows доступны на веб-сайте Apple. [33]
Avahi — это реализация Zeroconf для Linux и BSD . Она реализует IPv4LL , mDNS и DNS-SD. Она входит в состав большинства дистрибутивов Linux и устанавливается по умолчанию на некоторых из них. Если она работает совместно с nss-mdns, она также предлагает разрешение имен хостов. [34]
Avahi также реализует библиотеки двоичной совместимости, которые эмулируют Bonjour и историческую реализацию mDNS Howl, поэтому программное обеспечение, созданное для использования этих реализаций, также может использовать Avahi через интерфейсы эмуляции.
Microsoft Windows CE 5.0 включает собственную реализацию LLMNR от Microsoft.
Systemd реализует как mDNS, так и LLMNR в systemd-resolved.
Если DHCP-сервер не доступен для назначения хосту IP-адреса, хост может выбрать свой собственный адрес link-local . Используя адрес link-local, хосты могут взаимодействовать по этому каналу, но только локально; Доступ к другим сетям и Интернету невозможен. Доступны некоторые реализации IPv4-адресов link-local:
Все вышеперечисленные реализации являются автономными демонами или плагинами для клиентов DHCP , которые работают только с локальными IP-адресами. Другой подход заключается в том, чтобы включить поддержку в новых или существующих клиентов DHCP:
Ни одна из этих реализаций не решает такие проблемы ядра, как широковещательная передача ответов ARP [41] или закрытие существующих сетевых подключений.
Примечания
Источники