Dhcpv6 client 1000 ошибка

Перейти к содержанию

systemd version the issue has been seen with
systemctl —version
systemd 241 (241-9-gc1f8ff8+)

My configuration file is as below.

cat /etc/systemd/network/00-eth0.network
[Match]
Name=eth0
[Network]
DHCP=yes >>> I tried with ipv6 also but didn’t work.
IPv6AcceptRA=yes >> it always set the /proc/sys/net/ipv6/conf/eth0/accept_ra to 0
DuplicateAddressDetection=yes
[DHCP]
ClientIdentifier=mac

systemctl restart systemd-networkd
cat /proc/sys/net/ipv6/conf/eth0/accept_ra
0

ip addr output

ip addr show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 72:e2:84:14:24:1b brd ff:ff:ff:ff:ff:ff
inet 10.5.5.11/22 brd 10.5.7.255 scope global dynamic eth0
valid_lft 38128sec preferred_lft 38128sec
inet6 fe80::70e2:84ff:fe14:241b/64 scope link
valid_lft forever preferred_lft forever

ip addr show output shows the link local address which suggest that ipv6 is enabled on the interface.

ls -lrt /proc/net/if_inet6
-r—r—r— 1 root root 0 Apr 9 06:09 /proc/net/if_inet6

if_inet6 is also present.

In the below traces I could have seen that DHCPv4 started and get the v4 address but v6 client didn’t start at all.

###Systemd-networkd debug traces

eth0: Acquiring IPv4 link-local address
IPV4LL: Picked new IP address 169.254.36.40.
eth0: Acquiring DHCPv4 lease
DHCP CLIENT (0xd4f44d73): STARTED on ifindex 2
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=10 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
eth0: Setting addresses
DHCP CLIENT (0xd4f44d73): DISCOVER
lo: Link state is up-to-date
lo: Unmanaged
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_31 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=11 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
eth0: Removing address: 169.254.36.40/16 (valid forever)
eth0: Removing address: 10.5.5.11/22 (valid for 11h 57min 35s)
eth0: Addresses set
eth0: Setting routes
eth0: Routes set
IPV4ACD: Probing 169.254.36.40
DHCP CLIENT (0xd4f44d73): OFFER
DHCP CLIENT (0xd4f44d73): REQUEST (requesting)
DHCP CLIENT (0xd4f44d73): ACK
DHCP CLIENT (0xd4f44d73): lease expires in 11h 59min 58s
DHCP CLIENT (0xd4f44d73): T2 expires in 10h 29min 58s
DHCP CLIENT (0xd4f44d73): T1 expires in 6h
eth0: DHCPv4 address 10.5.5.11/22
eth0: Updating address: 10.5.5.11/22 (valid for 12h)
eth0: DHCP: No routes received from DHCP server: No data available
eth0: DHCP: No gateway received from DHCP server: No data available
IPV4ACD: Probing 169.254.36.40
IPV4ACD: Probing 169.254.36.40
IPV4ACD: ANNOUNCE

Unexpected behavior you saw

I was thinking that having the above configuration will start the DHCPv6 Client but I don’t see anything in the debug traces.

Steps to reproduce the problem

Having the above network configuration file and restart the systemd-networkd

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

DHCP сервер Windows 2016 не раздает адреса

И так ваш DHCP сервер поднятый на Windows Server 2016 или любой другой версии перестал раздавать IP адреса и в журнале вы видите следующею ошибку.

Решить эту проблему очень просто. Для этого запускаем оснастку DHCP.

Далее раскрываем дерево DHCP и кликаем правой кнопкой на IPv4 выбираем Свойства.

В открывшемся окне переходим на вкладку Дополнительно, тут кликаем на пункт Привязки.

В открывшемся окне ставим галочку напротив нужного сетевого интерфейса.

Все сохраняем и перезапускаем службу DHCP. После проделанных действий данная ошибка должна исчезнуть и сервер заработать, если конечно у вас нет других проблем. Причины по которым может появится такая ошибка могут быть связанны с какими либо манипуляциями с сетевым интерфейсов. Например установка hyper-v или других виртуальных машин.

Сервис, выдающий 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: смешивать, но не взбалтывать».

Поиск сетевых сервисов. Например, принтеров. Пожалуй, самым известным протоколом является UPnP, который помимо прочего умеет сам открывать порты на роутерах. Протокол довольно сложен, в нем используется целый набор надстроек вроде использования http, в отличие от второго известного протокола — DNS-SD (DNS Service Discovery), который попросту использует SRV-записи, в том числе при работе mDNS.

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

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

В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters и поставить ему значение 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 пакетов».

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

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

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

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

В этом разделе я рассмотрю практическое применение опций DHCP на оборудовании MikroTik. Сразу обращу внимание на то, что не все опции задаются очевидно, формат параметров описан в wiki. Следует отметить также то, что опции клиент применяет, только когда сам их попросит. В некоторых серверах можно принудительно отправить настройки: например, в ISC DHCP Server за это отвечает директива dhcp-parameter-request-list, а в Dnsmasq —* *—dhcp-option-force. MikroTik и Windows такого не умеют.

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:

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

Подробнее можно прочитать в статье «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 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.

Ввиду простоты протокола и присутствия широковещательных запросов есть эффективные атаки на инфраструктуру — в основном типа MITM («человек посередине»). Атаки производятся посредством поднятия своего DHCP-сервера или релея: ведь если контролировать выдачу сетевых настроек, можно запросто перенаправить трафик на скомпрометированный шлюз. Для облегчения атаки используется DHCP starvation (представляясь клиентом или релеем, злоумышленник заставляет «родной» DHCP-сервер исчерпать свои IP-адреса). Подробнее про реализацию атаки можно почитать в статье «Атакуем DHCP», методом же защиты является DHCP Snooping.

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

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

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

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

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

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

К другим методам защиты можно отнести Port Security («привязка» определенного MAC-адреса к порту маршрутизатора, при обнаружении трафика с других адресов порт будет блокироваться), Анализ трафика на количество DHCP-запросов и ответов или ограничение их количества, ну и, конечно, различные системы IPSIDS.

Если говорить не только о защите сети, но и о надежности, то не лишним будет упомянуть и про возможности отказоустойчивого 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?

История аренды IP-адресов на DHCP сервере

История аренды IP-адресов на DHCP сервере

Добрый день! Уважаемые читатели и гости одного из популярнейших IT блогов Pyatilistnik.org. В прошлый раз мы с вами разобрали тему по отключению защитника Windows 8.1. Сегодня мы разберем интересную тему по системному администрированию, а именно, как и где посмотреть историю аренды IP-адресов на сервере DHCP в Windows. Я расскажу вам сценарии, при которых эти знания окажутся для вас весьма полезными и необходимыми, да и вообще инженеры очень редко смотрят и изучают логи DHCP сервера.

Постановка задачи

И так у вас развернут DHCP сервер на Windows. В какой-то момент вам потребовалось выяснить, кем был зарезервирован IP-адрес, например несколько дней назад. Когда у вас время аренды большое, это сделать проще, если настроено резервирование, то это еще проще, но мы рассмотрим, что у вас время аренды, пусть будет сутки и резервирования нет. Благодаря моей инструкции вы сможете вычислить компьютер и mac-адрес устройства, кто получал нужный нам ip-адрес.

Как найти историю аренды ip-адресов DHCP

Откройте оснастку DHCP, и откройте свойства вашего пула IPV6 или IPV6. Убедитесь, что у вас включена функция «Вести журнал аудита DHCP«, если нет то включаем ее.

На вкладке «Дополнительно» вы можете посмотреть куда сохраняется журнал с событиями сервера. По умолчанию, это C:Windowssystem32dhcp.

Переходим в каталог C:Windowssystem32dhcp. Тут будут нужные нам файлы DhcpSrvLog.log. таких файлов будет 7, на каждый день недели.

Открыв файл вам сразу выскочит подсказка по кодам событий:

• 00 Ведение журнала начато.
• 01 Ведение журнала остановлено.
• 02 Ведение журнала временно приостановлено из-за нехватки места на диске.
• 10 Клиенту выдан новый IP-адрес.
• 11 Аренда продлена клиентом.
• 12 Аренда отменена клиентом.
• 13 IP-адрес уже используется в сети.
• 14 Запрос на аренду не может быть удовлетворен, так как исчерпан пул адресов этой области.
• 15 В аренде отказано.
• 16 Аренда удалена.
• 17 Срок аренды истек, а DNS-записи для истекших аренд не удалены.
• 18 Срок аренды истек, и DNS-записи удалены.
• 20 Клиенту выдан BOOTP-адрес.
• 21 Клиенту выдан динамический BOOTP-адрес.
• 22 Не удалось удовлетворить запрос на выдачу BOOTP-адреса, так как исчерпан пул адресов для BOOTP.
• 23 IP-адрес BOOTP удален, так как он не используется.
• 24 Начата очистка IP-адресов.
• 25 Статистика очистки IP-адресов.
• 30 Запрос на обновление DNS к именованному DNS-серверу.
• 31 Сбой обновления DNS.
• 32 Успешное обновление DNS.
• 33 Пакет отброшен в соответствии с политикой NAP.
• 34 Сбой запроса на обновление DNS. Превышено ограничение для очереди запросов на обновление DNS.
• 35 Сбой запроса на обновление DNS.
• 36 из-за несоответствия хэша ИД клиента или того, что сервер находится в режиме ожидания обработки отказа.
• 50+ Коды выше 50 используются для сведений о выявленных неавторизованных серверах.
• 11000 Обращение DHCPv6.
• 11001 Объявление DHCPv6.
• 11002 Запрос DHCPv6.
• 11003 Подтверждение DHCPv6.
• 11004 Обновление DHCPv6.
• 11005 Повторная привязка DHCPv6.
• 11006 Отклонение DHCPv6.
• 11007 Освобождение DHCPv6.
• 11008 Запрос информации DHCPv6.
• 11009 Заполнение области DHCPv6.
• 11010 Запуск DHCPv6.
• 11011 Остановка DHCPv6.
• 11012 Приостановка журнала аудита DHCPv6.
• 11013 Файл журнала DHCPv6.
• 11014 Недопустимый DHCPv6-адрес.
• 11015 DHCPv6-адрес уже используется.
• 11016 DHCPv6-клиент удален.
• 11017 DNS-запись DHCPv6 не удалена.
• 11018 Срок действия DHCPv6 истек.
• 11019 Устаревшие и удаленные аренды DHCPv6.
• 11020 Начало очистки базы данных DHCPv6.
• 11021 Окончание очистки базы данных DHCPv6.
• 11022 Запрос обновления DNS для IPv6.
• 11023 Сбой обновления DNS для IPv6.
• 11024 Успешное обновление DNS для IPv6.
• 11028 Сбой запроса обновления DNS для IPv6. Превышен предел очереди запросов на обновление DNS.
• 11029 Сбой запроса обновления DNS для IPv6.
• 11030 Записи DHCPv6-клиента без отслеживания состояния очищены.
• 11031 Запись DHCPv6-клиента без отслеживания состояния очищена, так как для нее истек интервал очистки.
• 11032 Запрос информации DHCPV6 с IPv6-клиента без отслеживания состояния.

Вот для примера, как выглядит продление аренды адреса.