Сеть с нулевой конфигурацией

Сеть с нулевой конфигурацией ( 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 включают системы автоконфигурации адресов , которые позволяют устройству определять безопасный адрес для использования с помощью простых механизмов. Для локальной адресации специальный блок 169.254.0.0/16 IPv4 использует , в то время как хосты IPv6 используют префикс fe80:: / 10 . Чаще всего адреса назначаются DHCP-сервером , часто встроенным в обычное сетевое оборудование, такое как компьютерные хосты или маршрутизаторы.

Большинство хостов IPv4 используют локальную адресацию только в крайнем случае, когда DHCP-сервер недоступен. В противном случае хост IPv4 использует свой адрес, назначенный DHCP, для всех коммуникаций, глобальных или локальных. Одна из причин заключается в том, что хосты IPv4 не обязаны поддерживать несколько адресов на интерфейс, хотя многие это делают. Другая причина заключается в том, что не каждый хост IPv4 реализует распределенное разрешение имен (например, многоадресную рассылку DNS ), поэтому обнаружение автоматически настроенного локального адреса канала другого хоста в сети может быть затруднено. Для обнаружения адреса другого хоста, назначенного DHCP, требуется либо распределенное разрешение имен, либо одноадресный DNS-сервер с этой информацией; В некоторых сетях есть DNS-серверы, которые автоматически обновляются с помощью назначенной DHCP информации об хосте и адресе.

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

Хосты IPv4 и IPv6 могут случайным образом генерировать специфичную для хоста часть автоматически настроенного адреса. Хосты IPv6 обычно сочетают в себе префикс длиной до 64 бит с 64-битным EUI-64, полученным из назначенного на заводе 48-битного IEEE MAC-адреса . Преимущество MAC-адреса состоит в том, что он глобально уникален, что является основным свойством EUI-64. Стек протоколов IPv6 также включает обнаружение повторяющихся адресов, чтобы избежать конфликтов с другими хостами. В IPv4 этот метод называется автоконфигурацией локального адреса канала . Однако Microsoft называет это автоматической частной IP-адресацией (APIPA). или автоматическая настройка интернет-протокола ( IPAC ). Эта функция поддерживается в Windows, по крайней мере, с Windows 98 .

Обнаружение службы имен

Интернет-протоколы используют IP-адреса для связи, но людям нелегко их использовать; IPv6, в частности, использует очень длинные строки цифр, которые нелегко ввести вручную. Чтобы решить эту проблему, в Интернете уже давно используется DNS, который позволяет связать удобочитаемые имена с IP-адресами и включает код для поиска этих имен в иерархической системе баз данных. Пользователи вводят доменные имена, например example.org , которые программное обеспечение DNS компьютера ищет в базах данных DNS для получения IP-адреса, а затем передает этот адрес в стек протоколов для дальнейшей связи.

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

DNS был предназначен для предоставления единых имен группам устройств в одной области администрирования, например example.org , предоставляемых службой имен. Назначение адреса локальному устройству, например, Thirdfloorprinter.example.org , обычно требует доступа администратора к DNS-серверу и часто выполняется вручную. Кроме того, традиционные DNS-серверы не должны автоматически корректировать изменения в конфигурации. Например, если принтер перемещается с одного этажа на другой, локальный DHCP-сервер может назначить ему новый IP-адрес.

Чтобы удовлетворить потребность в автоматической настройке, Microsoft внедрила службу имен NetBIOS , частью которой является служба браузера компьютеров , уже включенная в Microsoft Windows для рабочих групп 3.11. еще в 1992 году. Служба имен NetBIOS не требует настройки в сетях с одной подсетью и может использоваться вместе с WINS -сервером или DNS-сервером Microsoft, который поддерживает безопасную автоматическую регистрацию адресов. Эта система имеет небольшие, но не нулевые затраты на управление даже в очень крупных корпоративных сетях. Протоколы, которые может использовать NetBIOS, являются частью набора открытых протоколов Server Message Block (SMB). которые также доступны в Linux и iOS, хотя Windows обычно поддерживает более широкий спектр так называемых диалектов, которые могут быть согласованы между поддерживающими ее клиентами Windows. Например, службы браузера компьютеров, работающие в серверных операционных системах или более поздних версиях Windows, выбираются в качестве так называемого главного браузера вместо тех, которые не используют серверную операционную систему или работают под управлением более старых версий Windows.

В 2000 году Билл Мэннинг и Билл Вудкок описали службу многоадресных доменных имен. что породило реализации Apple и Microsoft. Обе реализации очень похожи. (mDNS) от Apple Многоадресная рассылка DNS опубликована как предложение по стандартизации. RFC   6762 (LLMNR) Microsoft , а разрешение многоадресной рассылки по локальной ссылке опубликовано в информационных целях. РФК   4795 . LLMNR включен в каждую версию Windows, начиная с Windows Vista. и действует как параллельная альтернатива службе имен Microsoft NetBIOS через IPv4 и как замена IPv6, поскольку NetBIOS недоступен через IPv6. Реализация Apple доступна как сервис Bonjour с 2002 года в Mac OS X v10.2. Реализация Bonjour (mDNSResponder) доступна по лицензии Apache 2 с открытым исходным кодом. и включен в Android Jelly Bean и более поздние версии. по той же лицензии.

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

Протоколы mDNS и LLMNR имеют незначительные различия в подходе к разрешению имен. mDNS позволяет сетевому устройству выбирать доменное имя в локальном DNS пространстве имен и объявлять его, используя специальный IP-адрес многоадресной рассылки. Это вводит специальную семантику для домена верхнего уровня local , что некоторые члены IETF считают проблемой. Текущий проект LLMNR позволяет сетевому устройству выбирать любое доменное имя, что некоторые члены IETF считают угрозой безопасности. mDNS совместим с DNS-SD, как описано в следующем разделе, а LLMNR — нет.

Обнаружение службы

Службы имен, такие как mDNS, LLMNR и другие, не предоставляют информацию о типе устройства или его статусе. Например, пользователь, ищущий ближайший принтер, может столкнуться с трудностями, если принтеру будет присвоено имя «Боб». Обнаружение службы предоставляет дополнительную информацию об устройствах. Обнаружение службы иногда сочетается со службой имен Apple , как в протоколе привязки имен и NetBIOS от Microsoft .

Обнаружение службы NetBIOS

NetBIOS в Windows поддерживает отдельные узлы в сети для рекламы таких служб, как общие файловые ресурсы и принтеры. Он также поддерживает, например, сетевой принтер для рекламы себя в качестве хоста, совместно использующего принтер и любые связанные службы, которые он поддерживает. В зависимости от того, как устройство подключено (к сети напрямую или к хосту, который его разделяет) и какие протоколы поддерживаются. Однако клиенты Windows, подключающиеся к нему, могут предпочесть использовать SSDP или WSD с использованием NetBIOS. NetBIOS — один из поставщиков Windows, реализующий более общий процесс обнаружения, получивший название « обнаружение функций» , который включает встроенные поставщики для PnP, реестра, NetBIOS, SSDP и WSD. из которых первые два предназначены только для локального использования, а последние три поддерживают обнаружение сетевых устройств. Ни один из них не требует какой-либо настройки для использования в локальной подсети. NetBIOS традиционно поддерживается только в дорогих принтерах для корпоративного использования, хотя некоторые принтеры начального уровня с Wi-Fi или Ethernet поддерживают его изначально, что позволяет использовать принтер без настройки даже в очень старых операционных системах.

WS-Обнаружение

Динамическое обнаружение веб-служб ( WS-Discovery ) — это техническая спецификация, определяющая протокол многоадресного обнаружения для обнаружения служб в локальной сети. Он работает через порт TCP и UDP 3702 и использует многоадресный IP-адрес 239.255.255.250 . Как следует из названия, фактическая связь между узлами осуществляется с использованием стандартов веб-сервисов, в частности SOAP-over-UDP . Windows поддерживает его в форме веб-служб для устройств и профиля устройств для веб-служб . Многие устройства, такие как принтеры HP и Brother, поддерживают его.

Обнаружение служб на основе DNS

DNS-SD (обнаружение служб DNS ) позволяет клиентам обнаруживать именованный список экземпляров служб и сопоставлять эти службы с именами хостов с помощью стандартных DNS-запросов. Эта спецификация совместима с существующим программным обеспечением одноадресных DNS-серверов и клиентов, но одинаково хорошо работает с mDNS в среде с нулевой конфигурацией. Каждый экземпляр службы описывается с помощью DNS SRV. и DNS-текст записывать. Клиент обнаруживает список доступных экземпляров для данного типа службы, запрашивая DNS PTR. запись имени этого типа услуги; сервер возвращает ноль или более имен в формате <Сервис>.<Домен>, каждое из которых соответствует паре записей SRV/TXT. разрешается Запись SRV в имя домена, предоставляющего экземпляр, а TXT может содержать параметры конфигурации, специфичные для службы. Затем клиент может разрешить запись A/AAAA для имени домена и подключиться к службе.

Типы услуг предоставляются в порядке очереди. Реестр типов служб изначально поддерживался DNS-SD.org. но с тех пор был объединен с реестром IANA для записей DNS SRV.

История

В 1997 году Стюарт Чешир Apple предложил адаптировать зрелый протокол привязки имен к IP-сетям, чтобы решить проблему отсутствия возможности обнаружения сервисов. Впоследствии Чешир присоединился к Apple и стал автором проектов предложений IETF по mDNS и обнаружению служб на основе DNS, поддерживая переход от AppleTalk к IP-сетям. В 2002 году Apple объявила о реализации обоих протоколов под названием Rendezvous. (позже переименованный в Бонжур). Впервые он был включен в Mac OS X 10.2 , заменив протокол определения местоположения службы (SLP), использовавшийся в версии 10.1 . В 2013 году предложения были ратифицированы как RFC   6762 и РФК   6763 .

DNS-SD с многоадресной рассылкой

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 с нулевой конфигурацией. При этом используются записи DNS PTR , SRV, TXT для объявления экземпляров типов служб, доменных имен для этих экземпляров и дополнительных параметров конфигурации для подключения к этим экземплярам. Но записи SRV теперь могут разрешаться в доменные имена .local , которые mDNS может разрешать в локальные IP-адреса.

Поддерживать

DNS-SD используется продуктами Apple, большинством сетевых принтеров, многими дистрибутивами Linux, включая Debian и Ubuntu . и ряд сторонних продуктов для различных операционных систем. Например, многие сетевые приложения OS X, написанные Apple, включая Safari , iChat и Messages , могут использовать DNS-SD для поиска ближайших серверов и одноранговых клиентов. Windows 10 включает поддержку DNS-SD для приложений, написанных с использованием JavaScript. Отдельные приложения могут иметь собственную поддержку в более старых версиях операционной системы, например, большинство клиентов обмена мгновенными сообщениями и VoIP в Windows поддерживают DNS-SD. Некоторые дистрибутивы Unix , BSD и Linux также включают DNS-SD. Например, Ubuntu поставляет Avahi , реализацию mDNS/DNS-SD, в своем базовом дистрибутиве.

УПнП

UPnP имеет некоторые компоненты протокола, предназначенные для обнаружения служб.

SSDP

Простой протокол обнаружения служб (SSDP) — это протокол UPnP, используемый в Windows XP и более поздних версиях. типа службы SSDP использует уведомления HTTP-уведомления, которые содержат URI и уникальное имя службы (USN). Типы услуг регулируются Руководящим комитетом Universal Plug and Play. SSDP поддерживается многими производителями принтеров, NAS и бытовой техники, такими как Brother. Он поддерживается некоторыми марками сетевого оборудования, а также во многих SOHO брандмауэрах , где хост-компьютеры, стоящие за ним, могут пробивать дыры для приложений. Он также используется в компьютерных системах домашнего кинотеатра для облегчения обмена мультимедиа между главными компьютерами и медиацентром.

DLNA

Digital Living Network Alliance (DLNA) — это еще один набор стандартов, использующий UPnP для обнаружения сетевых устройств. DLNA имеет длинный список известных производителей, производящих устройства, такие как телевизоры, устройства NAS и т. д., которые ее поддерживают. DLNA поддерживается всеми основными операционными системами. Обнаружение службы DLNA расположено поверх SSDP.

Усилия по созданию стандартного протокола IETF

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.

RFC   3927 , стандарт выбора адресов для сетевых элементов, был опубликован в марте 2005 года рабочей группой IETF Zeroconf. В группу входили представители Apple, Sun и Microsoft.

LLMNR был представлен для официального принятия в рабочую группу IETF DNSEXT, однако не смог достичь консенсуса и поэтому был опубликован как информационный. RFC   4795 в январе 2007 г.

После того, как LLMNR не стал стандартом Интернета, а также учитывая, что mDNS/DNS-SD используется гораздо шире, чем LLMNR, IETF попросил Apple также представить спецификации mDNS/DNS-SD для публикации в качестве информационного RFC.

В феврале 2013 года mDNS и DNS-SD были опубликованы как предложения по стандартизации. RFC   6762 и РФК   6763 .

Проблемы безопасности

Поскольку mDNS работает по другой модели доверия, чем одноадресный DNS — доверяя всей сети, а не назначенному DNS-серверу, он уязвим для поддельных атак со стороны любой системы в том же широковещательном домене . Как и SNMP и многие другие протоколы управления сетью, злоумышленники могут использовать его для быстрого получения подробной информации о сети и ее машинах. По этой причине приложения должны по-прежнему аутентифицировать и шифровать трафик к удаленным хостам (например, через RSA , SSH и т. д.) после их обнаружения и разрешения через DNS-SD/mDNS. LLMNR страдает аналогичными уязвимостями.

Основные реализации

Яблоко Привет

Bonjour от Apple использует mDNS и обнаружение служб DNS. Apple изменила предпочитаемую технологию Zeroconf с SLP на mDNS и DNS-SD между Mac OS X 10.1 и 10.2 , хотя SLP продолжает поддерживаться Mac OS X.

Apple mDNSResponder имеет интерфейсы для C и Java и доступен в BSD, Apple Mac OS X, Linux, других POSIX операционных системах на базе и MS Windows. Загрузки для Windows доступны на веб-сайте Apple.

Здание

Avahi — это реализация Zeroconf для Linux и BSD . Он реализует IPv4LL , mDNS и DNS-SD. Он входит в большинство дистрибутивов Linux и в некоторых устанавливается по умолчанию. При запуске вместе с nss-mdns он также предлагает разрешение имен хостов.

Avahi также реализует библиотеки двоичной совместимости, которые эмулируют Bonjour и историческую реализацию mDNS Howl, поэтому программное обеспечение, созданное для использования этих реализаций, также может использовать Avahi через интерфейсы эмуляции.

MS Windows CE 5.0

Microsoft Windows CE 5.0 включает собственную реализацию LLMNR от Microsoft.

Системад

Systemd реализует как mDNS, так и LLMNR в systemd-resolved.

Локальные адреса IPv4

Если DHCP-сервер не доступен для назначения хосту IP-адреса, хост может выбрать свой собственный локальный адрес канала . Используя локальный адрес канала, хосты могут обмениваться данными по этому каналу, но только локально; Доступ к другим сетям и Интернету невозможен. Доступны некоторые реализации локальных IPv4-адресов:

• Apple Mac OS и MS Windows поддерживают локальные адреса ссылок начиная с Windows 98 и Mac OS 8.5 (обе выпущены в 1998 году). Apple выпустила свою реализацию с открытым исходным кодом в пакете Darwin bootp.
• Avahi содержит реализацию IPv4LL в инструменте avahi-autoipd.
• IP с нулевой конфигурацией (zcip)
• BusyBox может встроить простую реализацию IPv4LL.
• Конюшня, ответвление Busybox предлагает слегка модифицированную реализацию IPv4LL под названием llad.
• Зероконф — это пакет, основанный на Simple IPv4LL, укороченной реализации Артура ван Хоффа .

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

• Элвис Пфютценройтер написал патч для клиента/сервера uDHCP.
• dhcpcd — это клиент с открытым исходным кодом DHCP- для Linux и BSD , который включает поддержку IPv4LL. Он включен в стандартную комплектацию NetBSD .

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

См. также

• Бонжур Спящий Прокси
• Беспроводная нулевая конфигурация
• Протокол разрешения имен узлов (PNRP)

Ссылки

Примечания

Источники

• Гуттман, Эрик (2001), «Автоконфигурация IP-сетей: включение локальной связи», IEEE Internet Computing , 5 (3): 81–86, doi : 10.1109/4236.935181

Внешние ссылки

• JmDNS , Source forge , чистая Java-реализация mDNS/DNS-SD.
• pyZeroConf , Source forge, 11 июля 2015 г. чистом Python . , реализация mDNS/DNS-SD на
• Mono.Zeroconf , проект Mono , кроссплатформенный (Linux, MS Windows, Apple Mac), унифицированная библиотека Mono/.NET для Zeroconf, поддерживающая как Bonjour, так и Avahi.
• WxServDisc , Source forge, 13 июня 2013 г. , кроссплатформенный модуль обнаружения сервисов на базе wxWidgets без внешних зависимостей.
• Чешир, Стюарт, Многоадресная DNS (проект) .
• Чешир, Стюарт, Спецификация обнаружения служб на основе DNS (проект), DNS-SD .
• Чешир, Стюарт, Zeroconf (технический разговор), заархивировано из оригинала (видео) 2 марта 2008 г. , получено 8 марта 2006 г.
• Cheshire, Stuart, Zeroconf , включая интернет-черновики.
• DNS-SD , обнаружение служб на основе DNS
• «Многоадресный DNS» .
• Протокол определения местоположения службы, версия 2 . дои : 10.17487/RFC2608 . РФК 2608 .
• Стейнберг, Дэниел; Чешир, Стюарт, Сети с нулевой конфигурацией: Полное руководство , О'Рейли .