Какой компонент назначит компьютеру ip адрес даже если в сети отсутствует работающий dhcp сервер

Обновлено: 06.07.2024

APIPA служит отказоустойчивым при проблемах DHCP

Как работает APIPA

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

При сбое процесса DHCP Windows автоматически назначает IP-адрес из частного диапазона, который 169.254.0.1 , 169.254.254.255 . Используя протокол разрешения адресов (ARP), клиенты проверяют, что выбранный адрес APIPA является уникальным в сети, прежде чем использовать его. Затем клиенты периодически проверяют DHCP-сервер, обычно каждые пять минут, и автоматически обновляют свои адреса, когда DHCP-сервер может обслуживать запросы.

Например, при запуске компьютера под управлением Windows 10 он несколько секунд ждет DHCP-сервер, прежде чем использовать IP-адрес из диапазона APIPA. Более ранние версии Windows ищут DHCP-сервер в течение трех минут.

Все устройства APIPA используют маску сети по умолчанию 255.255.0.0 и все находятся в одной подсети.

APIPA включается по умолчанию в Windows всякий раз, когда сетевой интерфейс ПК настроен для DHCP. Эта опция называется автоконфигурацией в утилитах Windows, таких как ipconfig. Администратор компьютера может отключить эту функцию, отредактировав реестр Windows и установив для следующего значения ключа значение 0:

Если вы не видите IPAutoconfiguration Enabled в списке, по умолчанию он равен 1. Вам нужно будет добавить новый REG_DWORD и установить его в 0.

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

Ограничения APIPA

Адреса APIPA не попадают ни в один из частных диапазонов IP-адресов, определенных стандартом Интернет-протокола, и ограничены для использования только в локальных сетях. Как и частные IP-адреса, тесты ping или любые другие запросы на подключение из Интернета и других внешних сетей не могут быть направлены непосредственно на устройства APIPA.

Устройства, настроенные APIPA, могут взаимодействовать с одноранговыми устройствами в своей локальной сети, но не могут взаимодействовать вне ее. Хотя APIPA предоставляет клиентам Windows пригодный для использования IP-адрес, он не предоставляет клиенту адреса сервера имен (DNS или WINS) и сетевого шлюза, как это делает DHCP.

Локальные сети не должны пытаться вручную назначать адреса в диапазоне APIPA, так как это приведет к конфликтам IP-адресов. Чтобы сохранить преимущество APIPA, связанное с указанием отказов DHCP, администраторы должны избегать использования этих адресов для каких-либо других целей и вместо этого ограничивают свои сети использованием стандартных диапазонов IP-адресов.

В этой статье описывается, как использовать автоматическую адресацию протокола управления передачей или протокола Интернета (TCP/IP) без наличия в сети сервера DHCP. Версии операционной системы, перечисленные в разделе "применимо к" этой статьи, имеют функцию автоматического назначения частных IP-адресов (APIPA). с помощью этой функции компьютер Windows может назначить себе IP-адрес в случае, если DHCP-сервер недоступен или не существует в сети. Эта функция делает настройку и поддержку небольшой локальной сети (LAN), использующей протокол TCP/IP, менее сложной.

Дополнительные сведения

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

компьютер на базе Windows, настроенный на использование DHCP, может автоматически назначать себе IP-адрес, если DHCP-сервер недоступен. Например, это может произойти в сети без DHCP-сервера или в сети, если DHCP-сервер временно отключен для обслуживания.

Служба Assigned Numbers Authority (IANA) заблокировала 169.254.0.0-169.254.255.255 для автоматического назначения частных IP-адресов. В результате APIPA предоставляет адрес, который гарантирует не конфликт с направляемыми адресами.

После того, как сетевому адаптеру был назначен IP-адрес, компьютер может использовать протокол TCP/IP для взаимодействия с любым другим компьютером, подключенным к той же локальной сети, который также настроен для APIPA или IP-адрес вручную задан как 169.254. x. y (где x. y — уникальный идентификатор клиента) с маской подсети 255.255.0.0. Обратите внимание, что компьютер не может взаимодействовать с компьютерами в других подсетях или с компьютерами, которые не используют автоматическую частных IP-адресов. Автоматическая Частная IP-адресация включена по умолчанию.

Вы можете отключить его в любом из следующих случаев.

В сети используются маршрутизаторы.

Сеть подключена к Интернету без NAT или прокси-сервера.

Обратите внимание, что для вступления изменений в силу необходимо перезагрузить компьютер. можно также определить, использует ли компьютер APIPA с помощью средства Winipcfg в Windows Millennium edition, Windows 98 или Windows 98 Second Edition:

Сведения о TCP/IP можно настроить вручную, что полностью отключает DHCP. Вы можете отключить автоматическое назначение частных IP-адресов (но не DHCP), отредактировав реестр. это можно сделать, добавив запись реестра DWORD "ипаутоконфигуратионенаблед" со значением 0x0 в следующий раздел реестра для Windows Millennium edition, Windows98 или Windows 98 Second Edition: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP

для Windows 2000, Windows XP и Windows Server 2003 можно отключить APIPA, добавив запись реестра DWORD "ипаутоконфигуратионенаблед" со значением 0x0 в следующий раздел реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Adapter GUID>

Подраздел GUID адаптера является глобальным уникальным идентификатором (GUID) для адаптера локальной сети компьютера.

При указании значения 1 для записи DWORD Ипаутоконфигуратионенаблед будет включено APIPA, что является состоянием по умолчанию, если это значение не указано в реестре.

Примеры того, где можно использовать APIPA

Пример 1. нет предыдущего IP-адреса и DHCP-сервера

Пример 2. предыдущий IP-адрес без DHCP-сервера

Пример 3. срок действия аренды истекает и DHCP-сервер отсутствует

Автоматическая частная IP-адресация (APIPA) — это отказоустойчивый DHCP — сервер, который защищает компьютерную систему от сбоев, вызывая резервный механизм для локальных сетей Интернет-протокола версии 4 (IPv4), поддерживаемых Microsoft Windows. С помощью APIPA клиенты DHCP могут получать IP-адреса, даже если серверы DHCP не работают. APIPA существует во всех современных версиях Windows, включая Windows 10 .

Как работает APIPA

Когда происходит сбой процесса DHCP, Windows автоматически назначает IP-адрес из частного диапазона, который составляет от 169.254.0.1 до 169.254.254.255. Используя протокол разрешения адресов ( ARP ), клиенты проверяют, что выбранный адрес APIPA является уникальным в сети, прежде чем использовать его. Затем клиенты периодически проверяют DHCP-сервер — обычно каждые пять минут — и автоматически обновляют свои адреса, когда DHCP-сервер может обслуживать запросы.

Например, при запуске компьютера с установленной Windows 10 он несколько секунд ждет DHCP-сервер, прежде чем использовать IP из диапазона APIPA. Более ранние версии Windows ищут DHCP-сервер в течение трех минут.

Все устройства APIPA используют маску сети по умолчанию 255.255.0.0 и все находятся в одной подсети .

APIPA включается по умолчанию в Windows всякий раз, когда сетевой интерфейс ПК настроен для DHCP. Эта опция называется автоконфигурацией в утилитах Windows, таких как ipconfig . Администратор компьютера может отключить эту функцию, отредактировав реестр Windows и установив для следующего значения ключа значение 0:

Если IPAutoconfiguration Enabled отсутствует в списке, то по умолчанию он равен 1. Вместо этого добавьте новый REG_DWORD и установите его в 0.

Сбои в процессе DHCP указывают на то, что устранение неполадок в сети необходимо для выявления и устранения проблем, мешающих работе DHCP должным образом.

Ограничения APIPA

Адреса APIPA не попадают ни в один из диапазонов частных IP-адресов, определенных стандартом Интернет-протокола, и ограничены для использования только в локальных сетях. Как и частные IP-адреса, тесты ping или другие запросы на подключение из Интернета и других внешних сетей не могут быть отправлены напрямую на устройства APIPA.

Устройства, настроенные APIPA, могут взаимодействовать с одноранговыми устройствами в их локальной сети, но не могут взаимодействовать вне ее. Хотя APIPA предоставляет клиентам Windows пригодный для использования IP-адрес, он не предоставляет клиенту адреса сервера имен ( DNS или WINS ) и сетевого шлюза, как это делает DHCP.

Локальные сети не должны пытаться вручную назначать адреса в диапазоне APIPA, так как это приведет к конфликтам IP-адресов . Чтобы сохранить преимущество APIPA, связанное с указанием отказов DHCP, избегайте использования этих адресов для каких-либо других целей и ограничивайте использование сетями стандартных диапазонов IP-адресов.

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

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

Немного теории и решения интересных и не очень практических задач — под катом.

В современной локальной сети выдачей адресов обычно занимаются специализированные сервисы с поддержкой протоколов. Самым популярным из них является DHCP (Dynamic Host Configuration Protocol).

В принципе, специально для функционирования небольших сетей был создан стек технологий под названием Zeroconf. Он позволяет обойтись без каких-либо централизованных сервисов и серверов, включая, но не ограничиваясь выдачей IP-адресов. Им закрываются (ну, или почти закрываются) следующие вопросы:

Получение IP-адреса (Automatic Private IP Addressing или APIPA). Система сама назначает себе IP из сети 169.254.0.0/16 (кроме сеток /24 в начале и конце диапазона), основываясь на MAC-адресе и генераторе псевдослучайных чисел. Такая система позволяет избежать конфликтов, а адрес из этой сети называют link-local — в том числе и потому, что эти адреса не маршрутизируются.

Поиск по имени. Система анонсирует свое сетевое имя, и каждый компьютер работает с ним как с DNS, храня записи у себя в кэше. Apple использует технологию mDNS (Multicast DNS), а Microsoft — LLMNR (Link-local Multicast Name Resolution), упомянутую в статье «Домены, адреса и Windows: смешивать, но не взбалтывать».

При всех плюсах Zeroconf — без каких-либо сакральных знаний можно собрать рабочую сеть, просто соединив компьютеры на физическом уровне, — IT-специалистам он может даже мешать.

Немного раздражает, не так ли?

В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и поставить ему значение 0.

Разумеется, Zeroconf подходит разве что для небольших изолированных сетей (например, встретились с приятелем с ноутбуками, соединили их по Wi-Fi и давай играть Diablo II, не тратя время на какие-то сервера), да и выводить локальную сеть в интернет тоже хочется. Чтоб не мучаться со статическими настройками каждого компьютера, были созданы специальные протоколы, включая героя дня — DHCP.

Одна из первых реализаций протокола для выдачи IP-адресов появилась более 30 лет назад и называлась RARP (Reverse Address Resolution Protocol). Если немного упростить принцип его работы, то выглядело это так: клиент делал запрос на широковещательный адрес сети, сервер его принимал, находил в своей базе данных привязку MAC-адреса клиента и IP — и отправлял в ответ IP.

Схема работы RARP протокола.

И все вроде работало. Но у протокола были минусы: нужно было настраивать сервер в каждом сегменте локальной сети, регистрировать MAC-адреса на этом сервере, а передавать дополнительную информацию клиенту вообще не было возможности. Поэтому на смену ему был создан протокол BOOTP (Bootstrap Protocol).

Изначально он использовался для бездисковых рабочих станций, которым нужно было не только выдать IP-адрес, но и передать клиенту дополнительную информацию, такую, как адрес сервера TFTP и имя файла загрузки. В отличие от RARP, протокол уже поддерживал relay — небольшие сервисы, которые пересылали запросы «главному» серверу. Это сделало возможным использование одного сервера на несколько сетей одновременно. Вот только оставалась необходимость ручной настройки таблиц и ограничение по размеру для дополнительной информации. Как результат, на сцену вышел современный протокол DHCP, который является совместимым расширением BOOTP (DHCP-сервер поддерживает устаревших клиентов, но не наоборот).

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

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

Схема общения клиента с сервером пересылки и сервером.

На нескольких собеседованиях меня спрашивали: «А какой транспорт и порт использует DHCP?» На всякий случай отвечаем: «Сервер UDP:67, клиент UDP:68».

С разными реализациями DHCP-сервера сталкивались многие, даже при настройке домашней сети. Действительно, сейчас сервер есть:

На практически любом маршрутизаторе, особенно SOHO.
На системах Windows Server. О сервере и его настройке можно почитать в официальной документации.
На системах *nix. Пожалуй, самое популярное ПО — ISC DHCP Server (dhcpd) и «комбайн» Dnsmasq.

Конкретных реализаций довольно много, но, например, на SOHO-маршрутизаторах настройки сервера ограничены. В первую очередь это касается дополнительных настроек, помимо классического «IP-адрес, маска, шлюз, сервер DNS». А как раз эти дополнительные опции и вызывают наибольший интерес в работе протокола. С полным списком можно ознакомиться в соответствующем RFC, я же разберу несколько интересных примеров.

Option 6 и Option 15. Начнем с простого. Настройка под номером 6 — это серверы DNS, назначаемые клиентам, 15 — суффикс DNS. Назначение суффикса DNS может быть полезным при работе с доменными ресурсами в недоменной сети, как я описывал в статье «Как мы сокращали персонал через Wi-Fi». Настройка MikroTik под спойлером.

Знание, что сервер DNS — это тоже опция, недавно пригодилось мне, когда разным клиентам нужно было выдать разные серверы DNS. Решение вида «выдать один сервер и сделать разные правила dst-nat на 53 порт» не подходило по ряду причин. Часть конфигурации снова под спойлером.

Option 66 и Option 67. Эти настройки пришли еще с BOOTP и позволяют указать TFTP-сервер и образ для сетевой загрузки. Для небольшого филиала довольно удобно установить туда микротик и бездисковые рабочие станции и закинуть на маршрутизатор подготовленный образ какого-нибудь ThinStation. Пример настройки DHCP:

Option 121 и Option 249. Используются для передачи клиенту дополнительных маршрутов, что может быть в ряде случаев удобнее, чем прописывать маршруты на шлюзе по умолчанию. Настройки практически идентичные, разве что клиенты Windows предпочитают вторую. Для настройки параметра маршруты надо перевести в шестнадцатеричный вид, собрав в одну строку маску сети назначения, адрес сети и шлюз. Также, по RFC, необходимо добавить и маршрут по умолчанию. Вариант настройки — под спойлером.

Предположим, нам нужно добавить клиентам маршрут вида dst-address=10.0.0.0/24 gateway=192.168.88.2, а основным шлюзом будет 192.168.88.1. Приведем это все в HEX:

Данные для настройки	DEC	HEX
Маска	24	0x18
Сеть назначения	10.0.0.0	0x0A 00 00
Шлюз	192.168.88.2	0xc0 a8 58 02
Сеть по умолчанию	0.0.0.0/0	0x00
Шлюз по умолчанию	192.168.88.1	0xc0 a8 58 01

Соберем все это счастье в одну строку и получим настройку:

Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route».

Option 252. Автоматическая настройка прокси-сервера. Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC)». К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Можно использовать для этого пакет hotspot или возможности metarouter, но лучше разместить файл где-либо еще.

Option 82. Одна из полезнейших опций — только не для клиента, а для DHCP-релея. Позволяет передать серверу информацию о порте коммутатора, к которому подключен клиент, и id самого коммутатора. Сервер на основе этой информации в свою очередь может выдать уже клиенту какой-то определенный набор настроек или просто занести в лог — чтобы в случае необходимости найти порт подключения клиента, не приходилось заходить на все свитчи подряд (особенно, если они не в стеке).

После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.

Выдача адресов с option 82.

Информация выдается в шестнадцатиричном формате. Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82».

Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.

Это функция коммутатора, которая позволяет «привязать» DHCP-сервер к определенному порту. Ответы DHCP на других портах будут заблокированы. В некоторых коммутаторах можно настроить и работу с Option 82 при ее обнаружении в пакете (что говорит о присутствии релея): отбросить, заменить, оставить без изменения.

В коммутаторах MikroTik включение DHCP Snooping производится в настройках бриджа:

Настройка в других коммутаторах происходит аналогичным образом.

Стоит отметить, что не все модели MikroTik имеют полную аппаратную поддержку DHCP Snooping — она есть только у CRS3xx.

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

Красивая коммутационная — залог здоровья.

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

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

Разберем более практичные варианты.

В системах Windows Server начиная с 2012 система резервирования DHCP работает «из коробки», в режиме балансировки нагрузки (active-active) или в режиме отказоустойчивости (active-passive). С подробным описанием технологии и настройками можно ознакомиться в официальной документации. Отмечу, что отказоустойчивость настраивается на уровне зоны, поэтому разные зоны могут работать в разном режиме.

Настройка отказоустойчивости DHCP-сервера в Windows.

В ISC DHCP Server для настройки отказоустойчивости используется директива failover peer, синхронизацию данных предлагается делать самостоятельно — например, при помощи rsync. Подробнее можно почитать в материале «Два DHCP сервера на Centos7. »

Если же делать отказоустойчивое решение на базе MikroTik, то без хитростей не обойтись. Один из вариантов решения задачи был озвучен на MUM RU 18, а затем и опубликован в блоге автора. Если вкратце: настраиваются два сервера, но с разным параметром Delay Threshold (задержка ответа). Тогда выдавать адрес будет сервер с меньшей задержкой, а с большей задержкой — только при выходе из строя первого. Синхронизацию информации опять же приходится делать скриптами.

Лично я в свое время изрядно потрепал себе нервов, когда в сети «случайно» появился роутер, подключенный в локальную сеть и WAN, и LAN интерфейсами.

Расскажите, а вам приходилось сталкиваться с проказами DHCP?

Читайте также: