no free leases что значит
Клиенты получают неверные настройки (IP-адреса) по DHCP
Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).
Второй вариант чаще всего гораздо удобнее, ведь настройки не придётся прописывать руками. Но наверняка многим приходилось сталкиваться с ситуацией, когда клиентское устройство получает совершенно другой IP-адрес вместо корректных настроек от DHCP-сервера. И тогда очень важно понять, почему так происходит и как всё быстро исправить. В посте я расскажу об этом.
Симптомы
Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам. Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции.
Диагностика на стороне клиента
Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).
Вывод команд покажет текущий IP-адрес и другие настройки на сетевом адаптере (или всех адаптерах, если их несколько). При этом, если на сетевом адаптере нет корректного IP-адреса, возможных вариантов его настроек может быть немного.
Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х
Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.
Пожалуй, самое очевидное действие в такой ситуации — попытаться снова получить IP-адрес, отправив повторно DHCP-запрос, а заодно убедиться, что на устройстве запущен DHCP-клиент. Это можно сделать несколькими способами:
При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если DHCP-клиент не запущен, сперва его необходимо включить. После этого нужно снова проверить настройки. Если результат остался прежним, проверьте работоспособность сетевого драйвера и стека протоколов TCP/IP в целом. Проще всего это сделать с помощью команды ping 127.0.0.1 (так называемая проверка внутренней обратной петли). Если в результате выполнения команды ответ от собственного сетевого адаптера получен, можно считать диагностику на стороне клиента завершённой и переходить к диагностике со стороны DHCP-сервера.
Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер
Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.
Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER). При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.
Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет:
Дальше дело за малым. Во-первых, можно воспользоваться сервисом macvendors.com или аналогичным и по MAC-адресу определить производителя оборудования этого устройства. У Wireshark есть такая функция. Во-вторых, если есть управляемые коммутаторы в сети, найти по MAC, в какой порт какого коммутатора подключено это устройство. После нейтрализации недоверенного DHCP-сервера клиенту, скорее всего, удастся получить верные настройки. Для предотвращения таких инцидентов в будущем рекомендуется внедрить методы защиты от атак на DHCP на сетевом оборудовании.
Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет
Если это так, то стоит вернуться к проверке не только самого IP-адреса, но и всех остальных настроек. И особенно к проверке маски, адреса шлюза по умолчанию и адресов DNS-серверов, так как именно через шлюз устройству предстоит связываться с другими сетями, а с помощью DNS-серверов — преобразовывать доменные имена в IP-адреса.
Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.
Диагностика на стороне сервера
Итак, диагностика на стороне клиента показала, что проблем не обнаружено. Независимо от реализации DHCP-сервера, теперь необходимо пошагово проверить ряд предположений, начиная с самых простых и очевидных.
Запущен ли DHCP как сервис?
В зависимости от ОС, дистрибутива и реализации DHCP-сервера, проверить это можно по-разному. Если сервис остановлен и есть ошибки в конфигурационных файлах, то запустить его не удастся. Это первая отправная точка. Если сервис запущен, можно переходить к следующему шагу.
Приходят ли запросы от клиентов на DHCP-сервер?
Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.
Нет ни запросов, ни ответов?
Предположим, что у нас есть по крайней мере один клиент, которому не удаётся получить настройки, и запрос от него точно должен был прийти на сервер. Если этого не произошло, очевидно, что клиент либо сам не отправляет запрос, либо запрос не доходит до сервера по разным причинам. Может, он блокируется на промежуточном сетевом оборудовании или в сети некорректно работает ретрансляция DHCP-запросов dhcp_relay.
Чтобы это проверить, можно в первом случае вернуться к диагностике на стороне клиента и проследить с помощью анализатора сетевого трафика, что клиент отправляет DHCP-запрос. Во втором — проверить настройки на промежуточном сетевом оборудовании.
Запрос(ы) есть, ответа(ов) нет?
Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.
Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).
Второй вариант чаще всего гораздо удобнее, ведь настройки не придётся прописывать руками. Но наверняка многим приходилось сталкиваться с ситуацией, когда клиентское устройство получает совершенно другой IP-адрес вместо корректных настроек от DHCP-сервера. И тогда очень важно понять, почему так происходит и как всё быстро исправить. В посте я расскажу об этом.
Симптомы
Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам. Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции.
Диагностика на стороне клиента
Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).
Вывод команд покажет текущий IP-адрес и другие настройки на сетевом адаптере (или всех адаптерах, если их несколько). При этом, если на сетевом адаптере нет корректного IP-адреса, возможных вариантов его настроек может быть немного.
Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х
Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.
Пожалуй, самое очевидное действие в такой ситуации — попытаться снова получить IP-адрес, отправив повторно DHCP-запрос, а заодно убедиться, что на устройстве запущен DHCP-клиент. Это можно сделать несколькими способами:
При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если DHCP-клиент не запущен, сперва его необходимо включить. После этого нужно снова проверить настройки. Если результат остался прежним, проверьте работоспособность сетевого драйвера и стека протоколов TCP/IP в целом. Проще всего это сделать с помощью команды ping 127.0.0.1 (так называемая проверка внутренней обратной петли). Если в результате выполнения команды ответ от собственного сетевого адаптера получен, можно считать диагностику на стороне клиента завершённой и переходить к диагностике со стороны DHCP-сервера.
Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер
Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.
Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER). При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.
Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет:
Дальше дело за малым. Во-первых, можно воспользоваться сервисом macvendors.com или аналогичным и по MAC-адресу определить производителя оборудования этого устройства. У Wireshark есть такая функция. Во-вторых, если есть управляемые коммутаторы в сети, найти по MAC, в какой порт какого коммутатора подключено это устройство. После нейтрализации недоверенного DHCP-сервера клиенту, скорее всего, удастся получить верные настройки. Для предотвращения таких инцидентов в будущем рекомендуется внедрить методы защиты от атак на DHCP на сетевом оборудовании.
Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет
Если это так, то стоит вернуться к проверке не только самого IP-адреса, но и всех остальных настроек. И особенно к проверке маски, адреса шлюза по умолчанию и адресов DNS-серверов, так как именно через шлюз устройству предстоит связываться с другими сетями, а с помощью DNS-серверов — преобразовывать доменные имена в IP-адреса.
Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.
Диагностика на стороне сервера
Итак, диагностика на стороне клиента показала, что проблем не обнаружено. Независимо от реализации DHCP-сервера, теперь необходимо пошагово проверить ряд предположений, начиная с самых простых и очевидных.
Запущен ли DHCP как сервис?
В зависимости от ОС, дистрибутива и реализации DHCP-сервера, проверить это можно по-разному. Если сервис остановлен и есть ошибки в конфигурационных файлах, то запустить его не удастся. Это первая отправная точка. Если сервис запущен, можно переходить к следующему шагу.
Приходят ли запросы от клиентов на DHCP-сервер?
Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.
Нет ни запросов, ни ответов?
Предположим, что у нас есть по крайней мере один клиент, которому не удаётся получить настройки, и запрос от него точно должен был прийти на сервер. Если этого не произошло, очевидно, что клиент либо сам не отправляет запрос, либо запрос не доходит до сервера по разным причинам. Может, он блокируется на промежуточном сетевом оборудовании или в сети некорректно работает ретрансляция DHCP-запросов dhcp_relay.
Чтобы это проверить, можно в первом случае вернуться к диагностике на стороне клиента и проследить с помощью анализатора сетевого трафика, что клиент отправляет DHCP-запрос. Во втором — проверить настройки на промежуточном сетевом оборудовании.
Запрос(ы) есть, ответа(ов) нет?
Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.
No free leases что значит
Всем привет
Есть работающий конфиг dhcp сервера, по необходимости была добавлена сетевая и прописан vlan. Добавляю subnet для влана и походу отваливается основной интерфейс (fxp0), начинает сыпать ошибками DHCPDISCOVER from 90:5f:2e:d5:4d:50 via fxp0: network net: no free leases.
Пытался вручную указать кто на каком интерфейсе, тоже самое. Влан (vlan6) апи получает.
# dhcpd.conf
#allow leasequery;
#stash-agent-options=true;
##
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
#log-facility local7;
server-identifier dhcp-v.znu.edu.ua;
server-name dhcp-v;
# option definitions common to all supported networks.
option domain-name «znu.edu.ua»;
option domain-name-servers uno.znu.edu.ua, duo.znu.edu.ua, iserver.znu.edu.ua;
default-lease-time 14400; # 4 h
min-lease-time 7200; # 2 h
max-lease-time 21600; # 6 h
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
ddns-update-style interim;
ddns-rev-domainname «in-addr.arpa»;
ddns-domainname «znu.edu.ua»;
ddns-ttl 7200;
update-static-leases on;
use-host-decl-names on;
#ignore client-updates;
allow client-updates;
deny duplicates;
option local-pac-serv code 252 = text ;
option local-pac-serv «http://proxy.znu.edu.ua/proxy.pac\000» ;
option pac-serv code 252 = text ;
option pac-serv «http://proxy.znu.edu.ua/proxy.pac\000» ;
# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
option subnet-mask 255.255.248.0;
option routers 10.1.100.153;
option netbios-dd-server 10.1.100.2, 10.1.100.4;
option netbios-name-servers 10.1.100.2, 10.1.100.4;
option ntp-servers 10.1.100.2;
option domain-name-servers 10.1.100.2, 10.1.100.4;
option domain-name «znu.edu.ua»;
# server-identifier dhcp-v.znu.edu.ua;
server-name dhcp-v;
option dhcp-server-identifier 10.1.100.9;
ddns-domainname «znu.edu.ua»;
use-host-decl-names on;
class «eva» <
match if ( ( substring (option host-name,0,3) = «eva» ) or
( substring (option host-name,0,3) = «EVA» ) or
( substring (option host-name,0,3) = «Eva» )
);>
class «abitura» <
match if ( ( substring (option host-name,0,3) = «abo») or
( substring (option host-name,0,3) = «Abo») or
( substring (option host-name,0,3) = «ABO»)
);>
class «labs» <
match if ( ( substring (option host-name,0,3) = «lab») or
( substring (option host-name,0,3) = «Lab») or
( substring (option host-name,0,3) = «LAB»)
);>
class «pasha» <
match if ( ( substring (option host-name,0,8) = «microsof») or
( substring (option host-name,0,8) = «MICROSOF»)
);>
class «telephones» <
match if ( ( substring (option host-name,0,7) = «android») or
( substring (option host-name,0,5) = «iPhone») or
( substring (option host-name,0,5) = «iphone») or
( substring (option host-name,0,7) = «Android») or
( substring (option host-name,0,4) = «iPad»)
);>
shared-network net <
update-static-leases on;
ddns-updates on;
option netbios-node-type 8;
# ddns-rev-domainname «1.10.in-addr.arpa»;
ddns-rev-domainname «in-addr.arpa»;
subnet 10.1.96.0 netmask 255.255.248.0 <
# interface fxp0;
allow unknown-clients;
ddns-updates on;
option subnet-mask 255.255.248.0;
option routers 10.1.100.153;
option netbios-dd-server 10.1.100.2, 10.1.100.4;
option netbios-name-servers 10.1.100.2, 10.1.100.4;
option ntp-servers 10.1.100.2;
option domain-name-servers 10.1.100.2, 10.1.100.4;
option domain-name «znu.edu.ua»;
option dhcp-server-identifier 10.1.100.9;
server-name dhcp-v;
ddns-domainname «znu.edu.ua»; >
deny unknown-clients;
deny members of «labs»;
deny members of «abitura»;
deny members of «eva»;
deny members of «pasha»;>
deny members of «telephones»;
deny members of «labs»;
deny members of «abitura»;
deny members of «eva»;
deny members of «pasha»;>
deny members of «telephones»;
deny members of «labs»;
deny members of «abitura»;
deny members of «pasha»; >
deny members of «telephones»;
deny members of «abitura»;
deny members of «eva»;
deny members of «pasha»;>
subnet 10.1.8.0 netmask 255.255.248.0 <
# interface fxp0;
allow unknown-clients;
ddns-updates on;
option subnet-mask 255.255.248.0;
option routers 10.1.10.153;
option netbios-dd-server 10.1.10.2, 10.1.100.4;
option netbios-name-servers 10.1.10.2, 10.1.10.4;
option ntp-servers 10.1.10.2;
option domain-name-servers 10.1.10.2, 10.1.10.4;
option domain-name «znu.edu.ua»;
option dhcp-server-identifier 10.1.10.9;
server-name dhcp-v;
ddns-domainname «znu.edu.ua»; >
deny members of «telephones»;
deny members of «labs»;
deny members of «eva»;
deny members of «pasha»;>
>#shared networks end.
#vlans subnet
subnet 10.168.8.0 netmask 255.255.252.0 <
allow unknown-clients;
# interface vlan6;
range 10.168.8.5 10.168.11.254;
ddns-updates on;
option routers 10.168.8.3;
option subnet-mask 255.255.252.0;
option netbios-dd-server 10.1.10.2, 10.1.100.4;
option netbios-name-servers 10.1.10.2, 10.1.10.4;
option ntp-servers 10.1.10.2;
option domain-name-servers 10.1.10.2, 10.1.10.4;
option domain-name «znu.edu.ua»;
option dhcp-server-identifier 10.168.8.3;
server-name dhcp-v;
>
# ifconfig
fxp0: flags=8843 metric 0 mtu 1500
options=2009
ether 00:0e:a6:8c:29:ef
inet 10.1.100.9 netmask 0xfffff800 broadcast 10.1.103.255
inet6 fe80::20e:a6ff:fe8c:29ef%fxp0 prefixlen 64 scopeid 0x6
inet 10.1.10.9 netmask 0xfffff800 broadcast 10.1.15.255
nd6 options=29
media: Ethernet autoselect (100baseTX )
status: active
xl0: flags=8843 metric 0 mtu 1500
options=82009
ether 00:04:75:99:b1:52
inet 172.16.67.1 netmask 0xffffff00 broadcast 172.16.67.255
inet6 fe80::204:75ff:fe99:b152%xl0 prefixlen 64 scopeid 0x7
nd6 options=29
media: Ethernet autoselect (100baseTX )
status: active
ipfw0: flags=8801 metric 0 mtu 65536
nd6 options=29
lo0: flags=8049 metric 0 mtu 16384
options=600003
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x9
inet 127.0.0.1 netmask 0xff000000
nd6 options=21
vlan6: flags=8843 metric 0 mtu 1500
ether 00:04:75:99:b1:52
inet 10.168.8.3 netmask 0xfffffc00 broadcast 10.168.11.255
inet6 fe80::204:75ff:fe99:b152%vlan6 prefixlen 64 scopeid 0xa
nd6 options=29
media: Ethernet autoselect (100baseTX )
status: active
vlan: 6 parent interface: xl0
в чем может быть проблема?
