Сеть без конфигурации

редактировать
технологии для автоматической настройки сетевого подключения

Сеть без конфигурации (zeroconf ) представляет собой набор технологий, который автоматически создает пригодную для использования компьютерную сеть на основе Internet Protocol Suite (TCP / IP), когда компьютеры или сетевые периферийные устройства соединены между собой. Не требует ручного вмешательства оператора или специальных серверов конфигурации. Без zeroconf сетевой администратор должен настроить сетевые службы, такие как Протокол динамической конфигурации хоста (DHCP) и Система доменных имен (DNS), или настроить каждую настройки сети компьютера вручную.

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

Содержание

  • 1 Фон
  • 2 Выбор адреса
  • 3 Обнаружение службы имен
  • 4 Обнаружение службы
    • 4.1 Обнаружение службы NetBIOS
    • 4.2 WS-Discovery
    • 4.3 Служба на основе DNS обнаружение
      • 4.3.1 История
      • 4.3.2 DNS-SD с многоадресной рассылкой
      • 4.3.3 Поддержка
    • 4.4 UPnP
      • 4.4.1 SSDP
      • 4.4.2 DLNA
      • 4.4. 3 Попытки создать стандартный протокол IETF
    • 4.5 AllJoyn
  • 5 Стандартизация
  • 6 Проблемы безопасности
  • 7 Основные реализации
    • 7.1 Apple Bonjour
    • 7.2 Avahi
    • 7.3 MS Windows CE 5.0
    • 7.4 Systemd
    • 7.5 Link-local IPv4-адреса
  • 8 См. Также
  • 9 Ссылки
  • 10 Внешние ссылки

Предпосылки

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

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

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

Ранним примером системы LAN с нулевой конфигурацией является AppleTalk, протокол, представленный Apple Inc. для первых компьютеров Macintosh в 1980-е годы. Mac, а также другие устройства, поддерживающие этот протокол, можно было добавить в сеть, просто подключив их; вся дальнейшая настройка была автоматизирована. Сетевые адреса автоматически выбирались каждым устройством с использованием протокола, известного как протокол разрешения адресов AppleTalk (AARP), в то время как каждая машина создавала свою собственную локальную службу каталогов с использованием протокола, известного как протокол привязки имен (NBP). NBP включал не только имя, но и тип устройства, а также любую дополнительную информацию, предоставленную пользователем, такую ​​как его физическое местонахождение или доступность. Пользователи могут искать любое устройство в сети с помощью приложения Chooser, которое фильтрует имена в зависимости от типа устройства.

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

Выбор адреса

Хостам в сети должны быть назначены IP-адреса, которые однозначно идентифицируют их для других устройств в той же сети. В некоторых сетях есть центральный орган, который назначает эти адреса при добавлении новых устройств. Были введены механизмы для автоматической обработки этой задачи, и теперь и IPv4, и IPv6 включают системы для автоконфигурации адреса, что позволяет устройству определять безопасный адрес для использования с помощью простых механизмов. Для локальной адресации IPv4 использует специальный блок 169.254.0.0/16, как описано в RFC 3927, а хосты 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-серверы автоматически исправят изменения в конфигурации. Например, если принтер переносится с одного этажа на другой, ему может быть назначен новый IP-адрес локальным DHCP-сервером.

Чтобы удовлетворить потребность в автоматической настройке, Microsoft внедрила NetBIOS Name Service, частью которого является Служба обозревателя компьютеров, уже присутствующая в Microsoft Windows для рабочих групп 3.11 еще в 1992 году. Служба имен NetBIOS не требует настройки в сетях с одной подсетью и может использоваться вместе с WINS сервер или сервер Microsoft DNS, поддерживающий безопасную автоматическую регистрацию адресов. Эта система имеет небольшие, но не нулевые накладные расходы на управление даже в очень больших корпоративных сетях. Протоколы, которые NetBIOS может использовать, являются частью набора открытых протоколов Server Message Block (SMB), которые также доступны в Linux и iOS, хотя Windows обычно поддерживает более широкий диапазон так называемых диалектов, которые можно согласовать. между клиентами Windows, которые его поддерживают. Например, службы компьютерного браузера, работающие в серверных операционных системах или более поздних версиях Windows, выбираются в качестве так называемого основного браузера по сравнению с теми, которые не работают под управлением серверной операционной системы или работают под управлением более старых версий Windows. Билл Мэннинг и Билл Вудкок описали службу многоадресных доменных имен, которая породила реализации Apple и Microsoft. Обе реализации очень похожи. Apple Multicast DNS (mDNS) публикуется как предложение по отслеживанию стандартов RFC 6762, а Microsoft Link-local Multicast Name Resolution (LLMNR) публикуется как информационный RFC 4795. LLMNR включен в каждую версию Windows, начиная с Windows Vista, и действует как параллельная альтернатива службе имен NetBIOS от Microsoft по 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-адрес многоадресной рассылки. Это вводит особую семантику для локального домена, что считается проблемой некоторыми членами IETF. Текущий проект LLMNR позволяет сетевому устройству выбирать любое доменное имя, что считается угрозой безопасности некоторыми членами IETF. mDNS совместим с DNS-SD, как описано в следующем разделе, а LLMNR - нет.

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

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

Microsoft NetBIOS Service Discovery

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

WS-Discovery

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

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

DNS-SD позволяет клиентам обнаруживать именованный список экземпляров служб и преобразовывать эти службы в имена узлов с помощью стандартных запросов DNS. Спецификация совместима с существующим одноадресным DNS-сервером и клиентским программным обеспечением, но одинаково хорошо работает с mDNS в среде с нулевой конфигурацией. Каждый экземпляр службы описывается с помощью записи DNS SRV и DNS TXT. Клиент обнаруживает список доступных экземпляров для данного типа службы, запрашивая запись 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 (позже переименована в Bonjour). Впервые он был включен в Mac OS X 10.2, заменив протокол определения местоположения службы, используемый в 10.1. В 2013 году предложения были ратифицированы как RFC 6762 и RFC 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-SD) также могут быть отправлены с использованием mDNS для получения DNS-SD с нулевой конфигурацией. При этом используются записи DNS PTR, SRV, TXT для объявления экземпляров типов служб, доменных имен для этих экземпляров и дополнительных параметров конфигурации для подключения к этим экземплярам. Но записи SRV теперь могут преобразовываться в имена доменов.local, которые mDNS может преобразовывать в локальные IP-адреса.

Поддержка

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

UPnP

UPnP имеет несколько вариантов протокола с целью обнаружения службы.

SSDP

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

DLNA

DLNA - это еще один набор стандартов, который использует UPnP для обнаружения сетевых устройств, у которого есть длинный список производителей, производящих устройства, которые его поддерживают, например телевизоры из большинства, если не всех крупные бренды, устройства NAS и т. д. Таким образом, он также поддерживается всеми основными операционными системами.

Работа над стандартным протоколом IETF

Протокол определения местоположения службы (SLP) поддерживается сетью сетью принтеров Hewlett-Packard , Novell и Sun Microsystems. SLP описан в RFC 2608 и RFC 3224, и реализации доступны как для Solaris и Linux.

AllJoyn

AllJoyn - это программный стек с открытым исходным кодом для множества устройств, от мельчайших устройств IoT до самых больших компьютеров, для обнаружения и управления устройствами в сетях ( Wifi, Ethernet) и другие ссылки (Bluetooth, ZigBee и т. Д.). Он использует (среди прочего) mDNS и HTTP через UDP.

Стандартизация

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

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

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

RFC 2608, стандарт SLP для выяснения, где получить услуги, был опубликован рабочей группой SVRLOC IETF.

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

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

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

Apple Bonjour

Bonjour (ранее известный как Rendezvous) от 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 и доступен в BSD, Apple Mac OS X, Linux, других операционных системах на основе POSIX и MS Windows. Загрузки Windows доступны на веб-сайте Apple.

Avahi

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 включает собственную реализацию Microsoft LLMNR.

Systemd

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

Link-local IPv4-адреса

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

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

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

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

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

См. Также

Ссылки

Примечания

Источники

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

Последняя правка сделана 2021-06-23 08:37:07
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте