URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 88648
[ Назад ]
Исходное сообщение
"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 07-Апр-10 23:39 
стоит FreeBSD 7.2, на ней isc-dhcpd крутится.
Ситуация: в сети "вынь", получила ИП 10.10.10.100 от сервака, успешно появилась заметка в dhcpd.leases и dhcpd.leases~. Допустим какой-то компьютер занимает на время этот адрес в сети, соответственно "вынь" получает другой, к примеру 10.10.10.200. Адрес 10.10.10.100 снова освобождается. В dhcpd.leases и dhcpd.leases~ удаляем запись 10.10.10.100, а 10.10.10.200 переписываем на 10.10.10.100, перезапускаем dhcpd. Но "вынь" не берет адрес 10.10.10.100, а снова требует 10.10.10.200 - сервер соглашается.
Это понятно что первым делом "вынь" пытается вернуть себе адрес тот, который был у нее в предыдущий раз.
Вопрос: можно ли заставить ее брать именно тот адрес, который предлагает сервер dhcpd? Есть ли такая опция? Ведь если прописать статику, то "вынь" сразу послушается.
Содержание
Сообщения в этом обсуждении
"isc-dhcpd не выдает предыдущий адрес"
Отправлено cuad0 , 08-Апр-10 00:09 
>Допустим какой-то компьютер занимает на время этот
>адрес в сети, соответственно "вынь" получает другой, к примеру 10.10.10.200.

Будем считать, что "вынь" получает адрес путем отказа от старого (decline) и получения нового (discover, request, ack)?

>а снова требует 10.10.10.200

следовательно, продляет свою аренду последнего dhcp-запроса


>Вопрос: можно ли заставить ее брать именно тот адрес, который предлагает сервер
>dhcpd? Есть ли такая опция? Ведь если прописать статику, то "вынь"
>сразу послушается.

Ну так и пропишите 


 host winda {
    hardware ethernet <mac-адрес>;
    fixed-address 10.10.10.100;
 }

это заставляет dhcpd на любое свое предложение со стороны клиента отвечать nack-ом. После такого клиент безусловно примет offer от сервера.

Конфиг бы показали... authoritative?

"isc-dhcpd не выдает предыдущий адрес"
Отправлено cuad0 , 08-Апр-10 00:26 
>В dhcpd.leases и dhcpd.leases~ удаляем запись 10.10.10.100

И зачем вы пытаетесь работать за dhcpd?
Кстати, почитайте http://www.opennet.me/cgi-bin/opennet/man.cgi?topic=dhcpd&ca...
там же ссылки на рус. маны по dhcpd.conf и dhcpd.leases.

"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 08-Апр-10 00:51 
Спасибо что откликнулись.
Я как раз и написал, что если статику прописать, то "вынь" обязательно примет ИП. Это я знаю.
Вы хотите сказать, что если я удалю lease средством dhcpd (через консоль), то сервер будет nack выдавать? хмммм
"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 08-Апр-10 01:35 
>Спасибо что откликнулись.
>Я как раз и написал, что если статику прописать, то "вынь" обязательно
>примет ИП. Это я знаю.
>Вы хотите сказать, что если я удалю lease средством dhcpd (через консоль),
>то сервер будет nack выдавать? хмммм

фигню я про консоль написал

"isc-dhcpd не выдает предыдущий адрес"
Отправлено cuad0 , 08-Апр-10 01:58 
>Я как раз и написал, что если статику прописать, то "вынь" обязательно
>примет ИП. Это я знаю.

Так ведь получается, что если вы пытаетесь всеми правдами-неправдами заставить винду взять обратно 100-й адрес, то тут больше именно статика и подходит. А то, что периодически появляется комп с таким же ip, то это скорее неверное построение сети - смените ip на "внезапном" компе и не будет проблем. Да и вообще, зачем винде возвращать адрес? Пусть пользует тот, который дали.

>Вы хотите сказать, что если я удалю lease средством dhcpd (через консоль),
>то сервер будет nack выдавать? хмммм

Нет, более того, удаляя лиз собственноручно (который, к тому же, скорее всего не просрочен), может возникнуть ситуация, когда новый хост запросит ip, а dhcpd выдаст ему лиз, который, по факту, уже получен другим клиентом. Но dhcpd-то и не знает об этом, в dhcpd.leases пусто на сей счет. Так что внося изменения в *.leases вы, тем самым, можете натворить хаоса в сети. Оставьте это дело dhcpd, не мешайте ему :)

"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 08-Апр-10 04:11 
>>Я как раз и написал, что если статику прописать, то "вынь" обязательно
>>примет ИП. Это я знаю.
>
>Так ведь получается, что если вы пытаетесь всеми правдами-неправдами заставить винду взять
>обратно 100-й адрес, то тут больше именно статика и подходит. А
>то, что периодически появляется комп с таким же ip, то это
>скорее неверное построение сети - смените ip на "внезапном" компе и
>не будет проблем. Да и вообще, зачем винде возвращать адрес? Пусть
>пользует тот, который дали.

На самом деле построение играет роль, но с тупыми в доску свичами ничего не сделаешь, а компы юзеров мне не подконтрольны. Поэтому когда какое-нить ламо начнет беспроводной раутер настраивать и тыкать куда попало кабель, то могут произойти разные вещи, например: раутеру присваивается адрес какого-нибудь чела в сети (10.10.10.100 в нашем случае) в качестве теста =), ну или поднимается DHCP-сервер на раутере, с незнания прописывается диапазон моей сети - итого имеем два сервера с одним диапазоном... Короче это все флейм.
Вернуть адрес необходимо, т.к. привязываются некоторые сетевые сервисы к ИПу. Знаю, знаю... будут возгласы, ну зачем такой геморрой с привязками, придумали себе головной боли... Надо. Короче, это другая тема для обсуждения.


>>Вы хотите сказать, что если я удалю lease средством dhcpd (через консоль),
>>то сервер будет nack выдавать? хмммм
>
>Нет, более того, удаляя лиз собственноручно (который, к тому же, скорее всего
>не просрочен), может возникнуть ситуация, когда новый хост запросит ip, а
>dhcpd выдаст ему лиз, который, по факту, уже получен другим клиентом.
>Но dhcpd-то и не знает об этом, в dhcpd.leases пусто на
>сей счет. Так что внося изменения в *.leases вы, тем самым,
>можете натворить хаоса в сети. Оставьте это дело dhcpd, не мешайте
>ему :)

Если я лезу в dhcpd.leases, то я зная что делаю, т.е. удаляемый хост уже отсутствует в сети и больше не появится.

Как временное решение попробую и посмотрю что будет:
прописываю ping check false; Т.о. по логике dhcpd перед выдачей сетевого адреса он не будет проверят ping'ом свободен ли ИП, а сразу и всегда будет его давать. Поэтому если чей-то ИП занят, то юзеры увидят на компе мессагу о совпадающих адресах, соответственно тот который прописал ИП вручную (а как же иначе) по логике полезет менять на другой, настоящий владелец ИПа немного попаникует и успокоится.
=)))

"isc-dhcpd не выдает предыдущий адрес"
Отправлено cuad0 , 08-Апр-10 14:12 
>Короче это все флейм.

Действенный способ от избавления геморроя - выделяйте себе сети в "нестандартных" диапазонах. Т.е. не заезженных мануалами 10.0.0.0/8, 192.168.0.0/24, 192.168.1.0/24 а что-нить вроде 10.22.0.0/16, 192.168.8.0/24 - пусть ламеры сами разбираются почему настраиваемое оборудование не видит локалку, а дефолтные настройки оборудования не поспособствуют ругани по arp.


>Вернуть адрес необходимо

Для прояснения картины можете почитать rfc2131. По большому счету, ip считается выделенным на max-lease-time времени. Пока время не истечет, аренда не закончится, даже если клиент этим адресом не пользуется (если только сам клиент не откажется от аренды). Этот момент учитывают как сервер, так и клиент. Если вы правите dhcpd.leases, то аналогичную по сути операцию надо сделать на клиенте, чтобы он никаким образом не узнал, что у него была какая-то аренда. Ну и раз компы клиентов вам не подконтрольны, тут вы ничего не поделаете. И в спецификациях dhcp нет какого-нибудь сообщения типа DHCPREVOKE, позволяющего отобрать у клиента лиз. Соответственно, нет и фичи у dhcpd.

>Если я лезу в dhcpd.leases, то я зная что делаю, т.е. удаляемый
>хост уже отсутствует в сети и больше не появится.

Но все равно это не ваша задача, dhcpd.leases - служебный файл, он для dhcpd, а не вас. Вы же в логи syslogd сами не пишите :)


>прописываю ping check false; Т.о. по логике dhcpd перед выдачей сетевого адреса
>он не будет проверят ping'ом свободен ли ИП, а сразу и
>всегда будет его давать.

А клиент может сделать свой request и получить вполне законный ack. Но если проверка пингом выключена - может начаться звездецок в сети. С другой стороны, клиент еще должен (хотя не обязан) по arp проверить предложенный адрес на предмет занятости. Если это так, он выбирает другое предложение или снова запрашивает dhcpd. Так что выключение пинга мало чему может помочь.


>соответственно тот который прописал
>ИП вручную (а как же иначе) по логике полезет менять на
>другой, настоящий владелец ИПа немного попаникует и успокоится.

Иногда это называют наивностью :) Все зависит от многих факторов... Первый может не полезть менять, а впадет в панику. Второй же может не успокоиться и начать строчить в саппорт/админу/какой-нибудь форум...


"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 08-Апр-10 17:33 
>>Короче это все флейм.
>
>Действенный способ от избавления геморроя - выделяйте себе сети в "нестандартных" диапазонах.
>Т.е. не заезженных мануалами 10.0.0.0/8, 192.168.0.0/24, 192.168.1.0/24 а что-нить вроде 10.22.0.0/16,
>192.168.8.0/24 - пусть ламеры сами разбираются почему настраиваемое оборудование не видит
>локалку, а дефолтные настройки оборудования не поспособствуют ругани по arp.

Адреса названы мною вымышленные, а использую я именно те редкие диапазоны, только тут юзер посмотрел какой его компу выдавался адрес в сети и давай своему беспроводному раутеру перебирать из этого диапазона.

>[оверквотинг удален]
>Для прояснения картины можете почитать rfc2131. По большому счету, ip считается выделенным
>на max-lease-time времени. Пока время не истечет, аренда не закончится, даже
>если клиент этим адресом не пользуется (если только сам клиент не
>откажется от аренды). Этот момент учитывают как сервер, так и клиент.
>Если вы правите dhcpd.leases, то аналогичную по сути операцию надо сделать
>на клиенте, чтобы он никаким образом не узнал, что у него
>была какая-то аренда. Ну и раз компы клиентов вам не подконтрольны,
>тут вы ничего не поделаете. И в спецификациях dhcp нет какого-нибудь
>сообщения типа DHCPREVOKE, позволяющего отобрать у клиента лиз. Соответственно, нет и
>фичи у dhcpd.

Вот это уже на мой вопрос ответ. Все что вы написали это я знаю. Не ясен лишь тот момент, когда прописываешь статику, то не смотря на отсутствие dhcprevoke клиент возьмет предложенный адрес, не смотря на другой адрес полученный в предыдущий раз. Вот меня этот момент интересует, каким это образом так происходит. Т.е. получается в случае с статикой клиенту как бы принудительно всучивается адрес. Вот я и "мечтал" об опции, которая заставляет клиента брать адрес, предложенный сервером и который был прописан в dhcpd.leases, а не статической записью.
хмм, надеюсь понятно изъясняюсь.


>>Если я лезу в dhcpd.leases, то я зная что делаю, т.е. удаляемый
>>хост уже отсутствует в сети и больше не появится.
>
>Но все равно это не ваша задача, dhcpd.leases - служебный файл, он
>для dhcpd, а не вас. Вы же в логи syslogd сами
>не пишите :)

хы
логи и файл лизов разные вещи все-таки


>>прописываю ping check false; Т.о. по логике dhcpd перед выдачей сетевого адреса
>>он не будет проверят ping'ом свободен ли ИП, а сразу и
>>всегда будет его давать.
>
>А клиент может сделать свой request и получить вполне законный ack. Но
>если проверка пингом выключена - может начаться звездецок в сети. С
>другой стороны, клиент еще должен (хотя не обязан) по arp проверить
>предложенный адрес на предмет занятости. Если это так, он выбирает другое
>предложение или снова запрашивает dhcpd. Так что выключение пинга мало чему
>может помочь.

Вот и посмотрю что получится в итоге.

"isc-dhcpd не выдает предыдущий адрес"
Отправлено cuad0 , 08-Апр-10 18:32 
(за точную достоверность не ручаюсь; частично диалог зависит и от политики клиента):
к - клиент, с - сервер.
к: ау, есть кто-нибудь тут? дайте адрес! (discover)
с: прив, я сервер .0.1, а ты в сети .0.1/24. Выбирай любой адрес: .100, [.101, ...] (offer)
к: хм, мне нравится .100, пожалуй возьму (request)
с: ок (ack)

...прошло max-lease-time времени...

к: с, можно я дальше адресом попользуюсь? (request)
с: да наздоровье (ack)

...прошло время, клиент ребутнулся...

к: ау, есть кто-нибудь тут? дайте адрес! (discover)
с: прив, я сервер .0.1, а ты в сети .0.1/24. Бери адрес: .105, [.106]. (offer)
к: (рыскает в загашнике, находит старый лиз) А можно .100? (request)
с: ни фига, он занят, бери другой (nak)
к: ладно, возьму .105 (request)
с: ок (ack)

...прошло время, клиент ребутнулся, серверу в конфиг написали статику для клиента...

к: ау, есть кто-нибудь тут? дайте адрес! (discover)
с: а, это снова ты, К. Я сервер .0.1, ты в сети .0.1/24. Бери адрес: .100. (offer)
к: (рыскает в загашнике, находит старый лиз) А можно .105? (request)
с: фиг. я сказал тебе, бери .100 (nak)
к: да че ты нервничаешь?
с: у меня указ давать тебе только один и тот же адрес, без всяких вольностей и "можно".
к: да? значит ни 105, ни 111, ни 222 ты мне не дашь?
с: ага.
к: ладно, не нервничай, возьму .100, тем более номер тоже козырный (request)
с: так бы сразу! (ack)

>логи и файл лизов разные вещи все-таки

Но их объединяет одно, они не предназначены для редактирования.


Попробуйте на винде что-нить типа
ipconfig /release
ipconfig /renew

"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 08-Апр-10 17:50 
напишу конкретнее.
1. комп1 получил адрес 10.10.10.100, погонял пакеты по сети и выключился.
2. включается комп2 и назначает себе адрес 10.10.10.100 вручную.
3. включается комп1 и пытается воспользоваться своим назначенным адресом 10.10.10.100, запрашивая разрешение у сервера - получает отказ, т.к. он щас занят, а также получает предложение взять другой адрес 10.10.10.200. комп1 соглашается на адрес 10.10.10.200.
4. комп2 выключается и больше в сети не появляется.
5. Удаляем dhcpd.leases записи на 10.10.10.100 и правим записи 10.10.10.200, изменяя ип на 10.10.10.100. Ребутим серв.
6. У компа1 перезапускаем сеть, он запрашивает адрес у сервера, сервер ему предлагает 10.10.10.100 (согласно dhcpd.leases), а комп1 хочет 10.10.10.200 - сервер не против. комп1 сохраняет за собой 10.10.10.200. -> В dhcpd.leases на этот комп имеется две записи на комп1 10.10.10.100 и 10.10.10.200.
Не прокатило

7. Прописываем статику на комп1 адрес 10.10.10.100.
8. комп1 после перезапуска молча берет этот адрес и не возникает, что у него до этого что-то было другое.

Хочется так:
...
пункт 6: У компа1 перезапускаем сеть, он запрашивает адрес у сервера, сервер ему предлагает 10.10.10.100 (согласно dhcpd.leases), а комп1 хочет 10.10.10.200 - сервер отвечает: "нееее, у меня записано в dhcpd.leases, что 10.10.10.100, значит его и будешь юзать". Комп1 повинуется. И это без использования статической записи.

"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 08-Апр-10 18:11 
The declines keyword

        allow declines;
        deny declines;
        ignore declines;

       The  DHCPDECLINE  message  is used by DHCP clients to indicate that the
       lease the server has offered is not valid.   When the server receives a
       DHCPDECLINE  for  a  particular  address,  it  normally  abandons  that
       address, assuming that some unauthorized system is using it.   Unfortu-
       nately,  a  malicious  or buggy client can, using DHCPDECLINE messages,
       completely exhaust the DHCP server's allocation pool.   The server will
       reclaim these leases, but while the client is running through the pool,
       it may cause serious thrashing in the DNS, and it will also  cause  the
       DHCP server to forget old DHCP client address allocations.

       The declines flag tells the DHCP server whether or not to honor DHCPDE-
       CLINE messages.   If it is set to deny or ignore in a particular scope,
       the DHCP server will not respond to DHCPDECLINE messages.


Если прописать "deny declines" вместе с опцией "ping check false", то получается в пункте 3, что серверу наплевать что ему клиент говорит про занятый кем-то 10.10.10.100, при этом сам сервер не будет проверять свободен адрес или нет. Соответственно, заставляя использовать этот адрес.
Я правильно понял?

"isc-dhcpd не выдает предыдущий адрес"
Отправлено cuad0 , 08-Апр-10 18:38 
> Если прописать "deny declines" вместе с опцией "ping check false", то
>получается в пункте 3, что серверу наплевать что ему клиент говорит
>про занятый кем-то 10.10.10.100, при этом сам сервер не будет проверять
>свободен адрес или нет. Соответственно, заставляя использовать этот адрес.
> Я правильно понял?

Примерно так. Теоретически, так можно до бесконечности общаться: "бери .100", "он занят, дай дугой", "бери .100", "он занят, дай другой".

А все это вместе дает ситуацию, когда серверу, клиенту и всем остальным наплевать на то, что творится в сети - никто за свои слова не отвечает :)

"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 08-Апр-10 18:46 
>[оверквотинг удален]
>>про занятый кем-то 10.10.10.100, при этом сам сервер не будет проверять
>>свободен адрес или нет. Соответственно, заставляя использовать этот адрес.
>> Я правильно понял?
>
>Примерно так. Теоретически, так можно до бесконечности общаться: "бери .100", "он занят,
>дай дугой", "бери .100", "он занят, дай другой".
>
>А все это вместе дает ситуацию, когда серверу, клиенту и всем остальным
>наплевать на то, что творится в сети - никто за свои
>слова не отвечает :)

Да тут просто комп1 покажет что "локальная сеть ограничена или отсутствует" и так будет до тех пор, пока комп2 не освободит адрес или не выключится.
Это да. Лучшее решение либо все вручную прописывать (без дхцп), умное железо ставить, отрубать привязку сервисов к адресам.
эх...

"isc-dhcpd не выдает предыдущий адрес"
Отправлено cuad0 , 08-Апр-10 19:17 
>Да тут просто комп1 покажет что "локальная сеть ограничена или отсутствует" и
>так будет до тех пор, пока комп2 не освободит адрес или
>не выключится.
>Это да. Лучшее решение либо все вручную прописывать (без дхцп), умное железо
>ставить, отрубать привязку сервисов к адресам.
>эх...

По мне так вообще, если комп используется в качестве каких-либо сервисов, то ему назначается статичный ип (имя хоста и запись в локальном днс, если есть), а статичный ip вообще выводится из диапазона dhcp (и подальше от него). Не знаю, почему вы так сразу не сделали.

"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 08-Апр-10 23:19 
>[оверквотинг удален]
>>не выключится.
>>Это да. Лучшее решение либо все вручную прописывать (без дхцп), умное железо
>>ставить, отрубать привязку сервисов к адресам.
>>эх...
>
>По мне так вообще, если комп используется в качестве каких-либо сервисов, то
>ему назначается статичный ип (имя хоста и запись в локальном днс,
>если есть), а статичный ip вообще выводится из диапазона dhcp (и
>подальше от него). Не знаю, почему вы так сразу не сделали.
>

О чем Вы говорите. Это все очевидные вещи, конечно же у меня все так. Привязка к сетевым сервисам в моем случае, это когда кто-нить воспользовался услугой (сервисом), то сервер запоминает с какого адреса это было сделано. Соответственно, если у пользователя меняется адрес, то он воспользоваться этой услугой уже не сможет, пока не восстановится сетевой адрес обратно, либо пока это не сделает администратор по просьбе юзверя.

"isc-dhcpd не выдает предыдущий адрес"
Отправлено cuad0 , 09-Апр-10 01:51 
Интересно стало, что это за сервис, если не секрет?
Сам принцип такого сервиса с запоминанием адресов в сети, где ip не гарантирован конкретному хосту из-за возможной коллизии _и_ наличия dhcpd, мне кажется, эммм, странноват.
По мне так проблему надо бы решать не дерганием dhcpd, а переработкой сервиса.
Ну, либо, смотрите в сторону DDNS и ресолвингу по имени хоста на вашем сервисе.

"isc-dhcpd не выдает предыдущий адрес"
Отправлено KENTus , 09-Апр-10 12:37 
>Интересно стало, что это за сервис, если не секрет?
>Сам принцип такого сервиса с запоминанием адресов в сети, где ip не
>гарантирован конкретному хосту из-за возможной коллизии _и_ наличия dhcpd, мне кажется,
>эммм, странноват.
>По мне так проблему надо бы решать не дерганием dhcpd, а переработкой
>сервиса.
>Ну, либо, смотрите в сторону DDNS и ресолвингу по имени хоста на
>вашем сервисе.

Надо будет посмотреть в сторону DDNS. Спасибо за идею.