Сеть с нулевой конфигурацией ( zeroconf ) — это набор технологий, которые автоматически создают пригодную к использованию компьютерную сеть на основе набора протоколов Интернета (TCP/IP) при соединении компьютеров или сетевых периферийных устройств. Он не требует ручного вмешательства оператора или специальной настройки серверов. Без Zeroconf сетевой администратор должен настроить сетевые службы , такие как протокол динамической конфигурации хоста (DHCP) и систему доменных имен (DNS), или настроить сетевые параметры каждого компьютера вручную.
Zeroconf построен на трех основных технологиях: автоматическое назначение числовых сетевых адресов сетевым устройствам, автоматическое распределение и разрешение имен хостов компьютеров , а также автоматическое определение местоположения сетевых служб , таких как печатающие устройства.
Компьютерные сети используют числовые сетевые адреса для идентификации конечных точек связи в сети участвующих устройств. Это похоже на телефонную сеть , которая назначает строку цифр для идентификации каждого телефона. В современных сетевых протоколах передаваемая информация разделяется на ряд сетевых пакетов . Каждый пакет содержит адреса источника и назначения для передачи. Сетевые маршрутизаторы проверяют эти адреса, чтобы определить лучший сетевой путь при пересылке пакета данных на каждом этапе к месту назначения.
Подобно тому, как на телефонах был указан их телефонный номер, в ранних сетях было обычной практикой прикреплять адресную метку к сетевым устройствам. Динамический характер современных сетей, особенно жилых сетей, в которых устройства включаются только при необходимости, требует наличия механизмов динамического назначения адресов, не требующих участия пользователя для инициализации и управления. Эти системы автоматически присваивают себе общие имена, выбранные либо производителем оборудования, например марка и номер модели, либо выбранные пользователями для идентификации своего оборудования. Имена и адреса затем автоматически вводятся в службу каталогов .
Ранние компьютерные сети были построены на основе технологий телекоммуникационных сетей, и поэтому протоколы, как правило, делились на две группы: те, которые предназначены для подключения локальных устройств к локальной сети (LAN), и те, которые предназначены в первую очередь для связи на большие расстояния. Последние системы глобальной сети (WAN), как правило, имели централизованную настройку, при которой сетевой администратор вручную назначал адреса и имена. Системы локальных сетей, как правило, обеспечивали большую автоматизацию этих задач, поэтому новое оборудование можно было добавлять в локальную сеть с минимальным вмешательством оператора и администратора.
Ранним примером системы локальной сети с нулевой конфигурацией является AppleTalk , протокол, представленный Apple Inc. для первых компьютеров Macintosh в 1980-х годах. Компьютеры Mac, а также другие устройства, поддерживающие этот протокол, можно было добавить в сеть, просто подключив их; вся дальнейшая настройка была автоматизирована. Сетевые адреса автоматически выбирались каждым устройством с использованием протокола, известного как протокол разрешения адресов AppleTalk (AARP), в то время как каждая машина создавала собственную локальную службу каталогов с использованием протокола, известного как протокол привязки имен (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-серверы не должны автоматически корректировать изменения в конфигурации. Например, если принтер перемещается с одного этажа на другой, локальный DHCP-сервер может назначить ему новый IP-адрес. [5]
Чтобы удовлетворить потребность в автоматической настройке, Microsoft реализовала службу имен NetBIOS , частью которой является служба браузера компьютеров, уже включенная в Microsoft Windows for Workgroups 3.11 [6] еще в 1992 году. Служба имен NetBIOS не требует настройки в сетях с одной подсетью. и может использоваться совместно с WINS- сервером или DNS-сервером Microsoft, который поддерживает безопасную автоматическую регистрацию адресов. Эта система имеет небольшие, но не нулевые затраты на управление даже в очень крупных корпоративных сетях. Протоколы, которые может использовать NetBIOS, являются частью набора открытых протоколов Server Message Block (SMB) [6] , которые также доступны в Linux и iOS, хотя Windows обычно поддерживает более широкий спектр так называемых диалектов, которые могут быть согласованы между клиентами Windows. которые поддерживают это. Например, службы браузера компьютеров, работающие в серверных операционных системах или более поздних версиях Windows, выбираются в качестве так называемого главного браузера вместо тех, которые не используют серверную операционную систему или работают под управлением более старых версий Windows. [6]
В 2000 году Билл Мэннинг и Билл Вудкок описали службу многоадресных доменных имен [7] , которая породила реализации Apple и Microsoft. Обе реализации очень похожи. Многоадресная DNS (mDNS) Apple опубликована в виде стандартного предложения RFC 6762, а разрешение многоадресных имен Microsoft для локальной многоадресной рассылки (LLMNR) опубликовано как информационный RFC 4795. LLMNR включен в каждую версию Windows, начиная с Windows Vista [8] и действует в качестве параллельной альтернативы службе имен Microsoft NetBIOS через IPv4 и в качестве замены IPv6, поскольку NetBIOS недоступен через IPv6. Реализация Apple доступна как сервис Bonjour с 2002 года в Mac OS X v10.2. Реализация Bonjour (mDNSResponder) доступна по лицензии Apache 2 с открытым исходным кодом [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, реестра, NetBIOS, SSDP и WSD [15] , из которых первые два предназначены только для локального использования, а последние три поддерживают обнаружение сетевых устройств. Ни один из них не требует какой-либо настройки для использования в локальной подсети. NetBIOS традиционно поддерживается только в дорогих принтерах для корпоративного использования, хотя некоторые принтеры начального уровня с Wi-Fi или Ethernet поддерживают его изначально, что позволяет использовать принтер без настройки даже в очень старых операционных системах.
Динамическое обнаружение веб-служб ( WS-Discovery ) — это техническая спецификация, определяющая протокол многоадресного обнаружения для обнаружения служб в локальной сети. Он работает через порт TCP и UDP 3702 и использует многоадресный IP-адрес 239.255.255.250 . Как следует из названия, фактическая связь между узлами осуществляется с использованием стандартов веб-сервисов, в частности SOAP-over-UDP . Windows поддерживает его в форме веб-служб для устройств и профиля устройств для веб-служб . Многие устройства, такие как принтеры HP и Brother, поддерживают его.
DNS-SD (Обнаружение служб DNS[16]) позволяет клиентам обнаруживать именованный список экземпляров служб и сопоставлять эти службы с именами хостов с помощью стандартных DNS-запросов. Эта спецификация совместима с существующим программным обеспечением одноадресных DNS-серверов и клиентов, но одинаково хорошо работает с mDNS в среде с нулевой конфигурацией. Каждый экземпляр службы описывается с помощью записей DNS SRV[17]и DNS TXT[18]. Клиент обнаруживает список доступных экземпляров для данного типа службы, запрашивая запись DNS PTR[18]с именем этого типа службы; сервер возвращает ноль или более имен в формате <Сервис>.<Домен>, каждое из которых соответствует паре записей 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, также известное как запросы 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 имеет некоторые компоненты протокола, предназначенные для обнаружения служб.
Простой протокол обнаружения служб (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 до полноразмерных компьютеров, для обнаружения и управления устройствами в сетях (Wi-Fi, 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. Apple изменила предпочитаемую технологию нулевой конфигурации с 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-адреса, хост может выбрать свой собственный локальный адрес канала . Используя локальный адрес канала, хосты могут обмениваться данными по этому каналу, но только локально; Доступ к другим сетям и Интернету невозможен. Доступны некоторые реализации локальных IPv4-адресов:
Все вышеперечисленные реализации представляют собой автономные демоны или плагины для DHCP -клиентов, которые работают только с локальными IP-адресами. Другой подход — включить поддержку в новые или существующие клиенты DHCP:
Ни одна из этих реализаций не решает проблемы ядра, такие как широковещательная рассылка ответов ARP [41] или закрытие существующих сетевых подключений.
Примечания
Источники