Программа dhcdrop (http://www.netpatch.ru/dhcdrop.html) предназначена для тестирования DHCP серверов при их настройке, и отслеживания или подавления ложных DHCP серверов в сетях провайдеров. Подавление серверов осуществляется при помощи атаки DHCP starvation.
Возможности программы:
- поддерживаемые платформы: Linux, FreeBSD, Windows.
- возможность задания списка игнорируемых DHCP серверов.
- возможность тестового запуска без активизации атаки DHCP starvation. Осуществляется отправкой запроса DHCPDISCOVER без посылки DHCPREQUEST. В случае обнаружения DHCP сервера выдаётся соответствующее сообщение и программа завершается.
- возможность автоматизировать поиск и подавление ложных DHCP серверов в сети при помощи простого скрипта использующего код возврата программы.
- возможность конфигурирования параметров тестирования, атаки DHCP starvation и некоторых опций запросов DHCP.
- возможность стресс-тестирования DHCP сервера при помощи режима флуда DHCPDISCOVER запросов.URL: http://www.netpatch.ru/dhcdrop.html
Новость: http://www.opennet.me/opennews/art.shtml?num=22575
Ура, теперь каждый школьник сможет досить DHCP сервера провайдера.
>Ура, теперь каждый школьник сможет досить DHCP сервера провайдера.Ага, вон они уже чуть ниже радуются. И заодно спрашивают, что сделать, чтобы их не досили.
Хуже точно не стало. Потому что раньше "каждый школьник" мог поднять свой дхцп-сервер и тем самым нагадить своему прову. Теперь это стало чревато.Вообще сам давно собирался такую прогу написать, да все руки не доходили. Спасибо ребятам.
В крон, однозначно :)
>Хуже точно не стало. Потому что раньше "каждый школьник" мог поднять свой
>дхцп-сервер и тем самым нагадить своему прову. Теперь это стало чревато.
>
>
>Вообще сам давно собирался такую прогу написать, да все руки не доходили.
>Спасибо ребятам.
>
>В крон, однозначно :)А оборудование настроить правильно прову что мешает?.. Один костыль другим подправлять, блин. :-\
> А оборудование настроить правильно прову что мешает?..Чаще всего мешает отсутствие денег на умные железяки умеющие делать DHCP snooping ;-)
>> А оборудование настроить правильно прову что мешает?..
>
>Чаще всего мешает отсутствие денег на умные железяки умеющие делать DHCP snooping
>;-)Ага. Это называется "времени на то, чтобы что-то сделать, вечно не хватает, но зато на переделки время всегда находится".
> Ага. Это называется "времени на то, чтобы что-то сделать, вечно не хватает, но зато на переделки время всегда находится".Что-то вы упорно не желаете меня понимать. "Время" далеко не всегда равно "деньги". Были бы везде умные железки умеющие фильтровать по ACL - ни кто бы с этим не парился. Да вот только что бы перевести не маленькую сеть (десятки тысяч хостов) целиком на умные железки - сами посчитайте сколько надо $$$...
>> Ага. Это называется "времени на то, чтобы что-то сделать, вечно не хватает, но зато на переделки время всегда находится".
>
>Что-то вы упорно не желаете меня понимать. "Время" далеко не всегда равно
>"деньги". Были бы везде умные железки умеющие фильтровать по ACL -
>ни кто бы с этим не парился. Да вот только что
>бы перевести не маленькую сеть (десятки тысяч хостов) целиком на умные
>железки - сами посчитайте сколько надо $$$...Хех. Я когда на нынешнюю работу пришёл (не-ИТ контора), здесь тоже уже стояло много умных железок. Если б ими ещё и пользовались… Мозги нужны, мозги. Тогда и экономить будут на том, на чём надо. :)
Согласен. Да только вот как вы понимаете - экономика и экономия далеко не всегда в руках IT специалистов.
Вот потому и приходится адаптироваться под существующие реалии.
Вы с чем собираетесь бороться?
Если с "левыми" DHCP серверами, то DHCP snooping Вам не нужен. Достаточно ACL способный выделить udp с портом источника 67, остальное по вкусу.
>Вы с чем собираетесь бороться?
>Если с "левыми" DHCP серверами, то DHCP snooping Вам не нужен.
>Достаточно ACL способный выделить udp с портом источника 67, остальное по
>вкусу.И все-таки это паллиатив. До появления этой проги единственной эффективной мерой была монтировка... красная :)
Пардон, действительно выше написал ерунду про DHCP snooping - просто в голове эта тема вертелась. Конечно в такой ситуации нужен ACL.
>А оборудование настроить правильно прову что мешает?.. Один костыль другим подправлять, блин.
>:-\Меньше всего меня интересуют половые трудности провайдеров.
Гораздо важнее - давить крыс в своей корпоративной локалке.
> Потому что раньше "каждый школьник" мог поднять свой дхцп-сервер и тем самым нагадить
> своему прову.А я думал что нормальные провы это уже пролечили - путем установки до юзеров свичей способных применять хотя-бы простейшее фильтрование.Удавить юзерам порт 67 - и все, возможность такого саботажа исключается на корню.А так да - видел как подъем левого DHCP положил админам корпоративную локалку, когда кто-то по головотяпству поднял левый DHCP.Выглядит это и правда прикольно - юзерье начинает отхватеывать левые айпи и после этого плотной стаей идет иметь мозг админу :)
> Теперь это стало чревато.
Теперь провы с хреновым оборудованием и школьники будут меряться пиписьками - у кого DHCP сдохнет первым :)
ну наконец то..
Искал такую с год назад и не нашел.
Теперь все в ажуре
Самому написать за пол часа можно.
Странно, что тогда никто не написал...
>Странно, что тогда никто не написал...У меня есть заготовки необходимых скриптов. А вот студентам подавай готовое
Тереь вопрос, как защитить "правильный" dhcp сервер от подобных програм??
Модуль recent спасет отца русской демократии ;)
>Модуль recent спасет отца русской демократии ;)А его что, под arptables уже портировали?
DHCP в iptables не верит :)
ebtables вобще-то ;)
да вобщем-то мы тут обсудили, спасает только MAC-биндинг на порту доступа + DHCP Snooping на аггрегации или на досутпе если есть возможность. все остальное прога обойдет.
>Тереь вопрос, как защитить "правильный" dhcp сервер от подобных програм??Глупый вопрос (простите за прямоту).
У правильного сервера всегда жестко прописан набор обслуживаемых маков, поэтому к такому досу он не чувствителен.
А те, кто к макам не привязывается, сами такую участь заслужили.
Вон на днях мой криворукий коллега в соседнем сегменте сети поднял свой сервак. Маками своими ограничиться не озаботился. А для половины моих компов его сервак по сетевой дистанции ближе (такая уж у нас дурацкая система). В результате - пол-сети в ауте. Особенно красиво это выглядело с учетом того, что у них авторизация через новелл-клиент: нет сети - нет компа.
> авторизация через новелл-клиент: нет сети - нет компа.Так в NDS есть же вход на комп локальным пользователем без подключения сетевых ресурсов.
>> авторизация через новелл-клиент: нет сети - нет компа.
>
>Так в NDS есть же вход на комп локальным пользователем без подключения
>сетевых ресурсов.Нет. У нас системная авторизация через нетварь идет. Пока в новеле не авторизуешься, до локальной авторизации не допустят.
Или я что-то упустил?
> Пока в новеле не авторизуешься, до локальной авторизации не допустят.
> Или я что-то упустил?В окне авторизации можно поставить галку "Только в рабочей станции" и после в "Дополнительно" задать локального пользователя и имя компьютера(либо пользователь и имя домена для AD при смешанной авторизации).Я говорю о полноценном Novell Client 32.
PS: Это возможно конечно отключить политиками, но на мой взгляд это просто вредительство в данном случае.
А есть какая нибудь нормальная система, что бы однозначно идентифицировать dhcp сервак клиентом, через сертификат например. Что бы он другие dhcp сервера игнорил?
>А есть какая нибудь нормальная система, что бы однозначно идентифицировать dhcp сервак
>клиентом, через сертификат например. Что бы он другие dhcp сервера игнорил?Вам не кажется что сие хоронит идею DHCP?Идея то в автоматическом получении параметров клиентами после широковещательного запроса.Т.е. админам достаточно DHCP сервак поднять и клиенты сами получат адреса.А если на каждую машину что-то там предустанавливать - можно просто статичные айпишники вбить.Ничем не лучше особо.Рукоблудство 1 фиг надо на каждой машине.Трабл простой: а кому мы будем доверять по умолчанию при автоконфигурации?Какому DHCP?И почему - именно ему?Чем он лучше иных с точки зрения клиента?Правильно - кому доверять может определить только админ.Ну, если ему это на каждой машине определять придется, чем это так уж лучше прописки статичных айпишников?Автоконфигурации уже все-равно не получается... (какая разница-влить на комп сертификат или просто настройки сети?)
Когда машину в домен вводишь, все равно приходится кого нибудь посылать, что бы настроил и ввел логин и пароль. Либо еще както заранее озаботиться и подготовить соответсвующий диск, а значит туда можно и ручками нужный сертификат пихнуть.PS. Увы не смог оперативно ответить, а значит и ответа от вас скорее всего не дождусь.
не кажется.DHCP хороша тем что клиенту не надо пояснять что делать - они комп включили и в сети. а статика - надо чтобы они ещё и правильно сеть настроили.
>>Тереь вопрос, как защитить "правильный" dhcp сервер от подобных програм??
>
>Глупый вопрос (простите за прямоту).
>
>У правильного сервера всегда жестко прописан набор обслуживаемых маков, поэтому к такому
>досу он не чувствителен.
>
>А те, кто к макам не привязывается, сами такую участь заслужили.Лично я руки таким провайдерам отрывать готов, которые до сих пор к MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная. Да и в корпоративной сети это тоже не всегда приемлемо, к сожалению (уже больше из-за самодурства начальства, но не суть).
Это две стороны одной медали: вы смотрите со стороны пользователя, я смотрю со стороны админа. С точки зрения локалки, дхцп-сервер без привязки к "контингенту" - более чем достаточное основание для кастрации его владельца.В сети провайдера, где дхцп должен быть _только один_, это еще в принципе терпимо.
>Лично я руки таким провайдерам отрывать готов, которые до сих пор к MAC'ам привязываются.
Впервые вижу человека, которому не нравится белый IP :)
>Это две стороны одной медали: вы смотрите со стороны пользователя, я смотрю
>со стороны админа.Я стараюсь смотреть с обеих сторон, иначе общий язык находить сложно. Всё-таки компы для людей, а не наоборот.
> С точки зрения локалки, дхцп-сервер без привязки к
>"контингенту" - более чем достаточное основание для кастрации его владельца.Лишний DHCP-сервер - да, за такое у меня докладная заму генерального по безопасности сразу идёт. А вот "лишний" компьютер - это, порой, приходится терпеть. :(
>В сети провайдера, где дхцп должен быть _только один_, это еще в
>принципе терпимо.
>
>>Лично я руки таким провайдерам отрывать готов, которые до сих пор к MAC'ам привязываются.
>
>Впервые вижу человека, которому не нравится белый IP :)Эммм... Не понял. Вы про то, чтобы кто-то другой в сети не начал притворяться моим IP-шником? Так мой пров, например, уже года полтора как научился пользоваться VLAN'ами (другое дело, что долгое время у нас в доме стояло какое-то г***о, которое с ними криво работало, но однажды оно, наконец, сгорело :) ), очень помогает. И на работе сейчас я стараюсь реализовать эту схему.
>Я стараюсь смотреть с обеих сторон, иначе общий язык находить сложно. Всё-таки
>компы для людей, а не наоборот.Он смотрит с точки зрения "провайдерского" адмна.А вы с точки зрения "корпоративного" ;)
>Лишний DHCP-сервер - да, за такое у меня докладная заму генерального по
>безопасности сразу идёт.Провайдера мало утешит взбучку юзеру устроить.Как минимум - юзеры сегмента вставшего из-за дятла раком будут осаждать саппорт.А то и бабло за недооказание услуги резонно попросят назад.Ну а долбо...в в локалках спосбных перепутать у своего роутера WAN и LAN, чисто в силу бестолковости - навалом.И их в отличие от сотрудников - не уволишь.И вообще, от "увольнения" юзера, даже тупого, в минусе - прежде всего сам пров.В общем то эзернет никогда не предназначался для крупномасштабного провайдинга, а интернет протоколы делались с иными целями и задачами.А время рассудило иначе.В итоге нормальные провы обученые жизнью и суровыми реалиями нынче просто давят фильтрами на "продвинутых" свичах перед юзерами такие левые DHCP, посему у них просто нет проблем с DHCP.Ну и всякие там плюшки типа отключения юзеру порта ремотным управлением скриптом дернутым из биллинга если юзер не заплатил, etc.Это борьба с теми кто тотально не хочет платить за доступ ... при дерьмовом оборудовании у прова чувак может до упора юзать LAN прова, бесплатно.При том что он за поддержку инфраструктуры оной сети ни копейки не платит а вот прову обслуживание огроменной сети что-то стоит, т.е. при большом числе халявщиков пров оказывается в лузерах.Все эти простые соображения заставляют провов использовать иные подходы нежели у корпоративщиков.
>>Я стараюсь смотреть с обеих сторон, иначе общий язык находить сложно. Всё-таки
>>компы для людей, а не наоборот.
>
>Он смотрит с точки зрения "провайдерского" адмна.А вы с точки зрения "корпоративного"
>;)Вы таки думаете, что я не представляю себе масштаб проблем, которые может вызвать у провайдера левый DHCP-сервер? :)
>[оверквотинг удален]
>обученые жизнью и суровыми реалиями нынче просто давят фильтрами на "продвинутых"
>свичах перед юзерами такие левые DHCP, посему у них просто нет
>проблем с DHCP.Ну и всякие там плюшки типа отключения юзеру порта
>ремотным управлением скриптом дернутым из биллинга если юзер не заплатил, etc.Это
>борьба с теми кто тотально не хочет платить за доступ ...
>при дерьмовом оборудовании у прова чувак может до упора юзать LAN
>прова, бесплатно.При том что он за поддержку инфраструктуры оной сети ни
>копейки не платит а вот прову обслуживание огроменной сети что-то стоит,
>т.е. при большом числе халявщиков пров оказывается в лузерах.Все эти простые
>соображения заставляют провов использовать иные подходы нежели у корпоративщиков.Вы это мне рассказываете? Зачем??? :))
>Вы это мне рассказываете? Зачем??? :))А черт вас знает - если вы в курсе то почему вы с вон тем админом спорите?Вы б в его шкуре (админ у прова) рассуждали наверное примерно как он.Если исходить с позиций неубиваемости сети простейшими методами саботажа.Разве нет?
P.S. а вот в IPv6 такие фортели с захапывнием всех айпи как я понимаю не прокатят в силу очень большого колчества айпишников... :P
>>Вы это мне рассказываете? Зачем??? :))
>
>А черт вас знает - если вы в курсе то почему вы
>с вон тем админом спорите?Вы б в его шкуре (админ у
>прова) рассуждали наверное примерно как он.Если исходить с позиций неубиваемости сети
>простейшими методами саботажа.Разве нет?И рассуждаю. Почему когда я соглашаюсь, надо пытаться всё равно спорить — вот этого я понять не могу. :))
>P.S. а вот в IPv6 такие фортели с захапывнием всех айпи как
>я понимаю не прокатят в силу очень большого колчества айпишников... :PБолее того, множество MAC-адресов заведомо меньше множества IPv6-адресов ;)
> P.S. а вот в IPv6 такие фортели с захапывнием всех айпи как я понимаю не прокатят в силу очень большого колчества айпишников... :PЭээ, вы как бы не правы. В принципе в IPv4 более 4х миллиардов адресов, но это не значит что надо все захапывать :-) Пул DHCP сервера ограничен вовсе не адресным пространством IP протокола. Пул ограничен настройками DHCP сервера, и обычно состоит из сотни-другой адресов на подсеть. Так что хоть IPv4, хоть IPv6 - принципиальной разницы нет. Есть практическая разница - IPv6 тулзой пока не поддерживается.
К вопросу о привязке MAC->IP в настройках DHCP сервера. Ладно, допустим что мы её вовсе отменили. Советую задуматься - как осуществлять такую услугу как "бан" по IP адресу на локальных ресурсах? Жёстко банить юзера на умном оборудовании - помоему как-то не красиво, когда в случае со статически выдаваемым IP адресом это можно делать через web-формочку форума например, или через командную строку чата.
А уж если локальный ресурс принадлежит юзеру, а не провайдеру... То у него вообще практически нет шансов раз и на всегда забанить злодея на своём ресурсе - доступа к умным девайсам провайдера он ведь не имеет.
А вот провайдера у которого больше пары тыщь юзеров и нет круглосуточного сапорта способного сменить MAC адрес девайса - точно следует попинать ногами.
>Лично я руки таким провайдерам отрывать готов, которые до сих пор к
>MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная.Эээ а прописать мак адрес - не того?Даже многие soho роутеры по этой причине умеют fake-ить мак на WAN порту.Чтоб юзер мог прикинуться шлангом^W своей старой сетевухой...
>>Лично я руки таким провайдерам отрывать готов, которые до сих пор к
>>MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная.
>
>Эээ а прописать мак адрес - не того?Даже многие soho роутеры по
>этой причине умеют fake-ить мак на WAN порту.Чтоб юзер мог прикинуться
>шлангом^W своей старой сетевухой...Многие, но не все. Мне ли рассказывать, что сначала обычно приобретается "крутое" железо, а уже потом, когда ничего не получается, зовут специалиста всё это настроить. Это я именно про SOHO.
И не все сетевухи умеют прикидываться. Более того, если одни могут этот MAC запомнить, то другим его надо вбивать при каждом запуске, что чревато (в клинических случаях, кои наблюдать приходилось) опять же автоматическим отключением порта провайдера - дескать, мелькнул чужой MAC. Более того, я сталкивался с сетевухой, которую смена MAC банально вводила в нестабильный режим — через некоторое время она тупо переставала обрабатывать пакеты, пока ей не сделаешь up/down. Кажется, это было что-то на VIA, но могу и соврать.
Да, и о чём мы вообще все здесь спорим, если по сути друг с другом согласны? :)
>это настроить. Это я именно про SOHO.Ну да.При этом спасибо если человек отличит WAN от LAN :D.
>порта провайдера - дескать, мелькнул чужой MAC.
Мне кажется что пров сам себя нагревает в этом случае - лишней нагрузкой на саппорт.При том - не совсем понятно, а что приобретается взамен?Ну, кроме геморроя саппорту?
>Более того, я сталкивался с сетевухой, которую смена MAC банально вводила
>в нестабильный режим — через некоторое время она тупо переставала обрабатывать пакеты,Как оригинально.Но обычно юзеры хотят просто расшарить инет на несколько компов.При этом всяко нужен какой-то роутер.Ну и наверное если делать не через зад а по уму - то к его покупке (или сборке, если это писюк) следует подойти с пониманием вопроса, что требуется в конкретном случае и будет ли все это вообще работать.И уж определенно можно обойти грабельки стронкой.А кто делает фиг знает что и зачем - получает соответствующий результат.Вон у нас тут корбина (и еще много кого) с PPTP для интернета и DHCP для LAN.Ну и нифига не любой soho роутер жрет как бы два внешних интерфейса (эзернет с dhcp + pptp).Некоторые не любят имена pptp cерваков вместо IP.И так далее.Если кто покупает хз что и зачем и не интересуясь совместимостью - он обламывается, да.И ему никто не виноватНо народ тем не менее как-то роутеры все-таки использует.Т.е. - даже юзеры могут не тормозить.А кто тормозит и покупает только по критерию "это круто" - нагревает сам себя на бабки и беготню.Хороший стимул поумнеть :)
>пока ей не сделаешь up/down.
Мде.Ну и бяка...
>Да, и о чём мы вообще все здесь спорим, если по сути
>друг с другом согласны? :)Тут вы правы.Только и ограничение по MAC иногда можно понять.И от кой-чего в каких-то условиях оно защищает.Ну вот например, атаки с юзежом этой утили как я понимаю обломаются :).Кстати видел еще такую настройку DHCP - всем известным машинам выдаются прописанные айпи (привязка IP к mac на DHCP).Наверное при этом трудно подгадить такой утилью - IP закрепленный за конкретным маком только ему и будет выдан.Т.е. хаксор с утилей начнет получать фигу.А те кто прописан (легитимные юзеры) свой IP всяко получат.И это можно пролечить на стороне DHCP сервера.Что наверное попроще порой чем оборудование менять :).Система костылей и подпорочек, конечно, при том увеличивающая административный геморрой.
>Лично я руки таким провайдерам отрывать готов, которые до сих пор к
>MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная. Да и
>в корпоративной сети это тоже не всегда приемлемо, к сожалению (уже
>больше из-за самодурства начальства, но не суть).В корпоративном секторе привязка MAC к IP и железу больше необходимость, чем паранойя или самодурства начальства. А в некоторых вещах это есть вообще обязаловка И ИМХО это правильно. И эта стратегия на практике остается адекватной когда у тебя в сети более 50 компов, и полюбому найдется 10-30% умников которые будут тыкаться в соседние розетки и менять ИП. Пример из личной практики: в одной конторе когда появился инет он толком кроме админов и 1 отделу никому и даром не нужен был. Но после прошествии некоторого месяца народ эту тему выкурил по полной. Доходило до того что народ обходил бан по IP методом мониторинга тачек которые имели доступ т.е. в случае если эта тачка выключена то на сетевухе менялся IP и оп инет есть. И что самое главное этим промышляла отнють не молодежь ;)
>>Лично я руки таким провайдерам отрывать готов, которые до сих пор к
>>MAC'ам привязываются. Жутко неудобно. Особенно если техподдержка не круглосуточная. Да и
>>в корпоративной сети это тоже не всегда приемлемо, к сожалению (уже
>>больше из-за самодурства начальства, но не суть).
>
>В корпоративном секторе привязка MAC к IP и железу больше необходимость, чем
>паранойя или самодурства начальства.Про самодурство я говорил как раз в обратном смысле: что начальник хочет таскать на работу ноутбуки, не заботясь ни о чём, и хоть ты тресни.
>[оверквотинг удален]
>обязаловка И ИМХО это правильно. И эта стратегия на практике остается
>адекватной когда у тебя в сети более 50 компов, и полюбому
>найдется 10-30% умников которые будут тыкаться в соседние розетки и менять
>ИП. Пример из личной практики: в одной конторе когда появился инет
>он толком кроме админов и 1 отделу никому и даром не
>нужен был. Но после прошествии некоторого месяца народ эту тему выкурил
>по полной. Доходило до того что народ обходил бан по IP
>методом мониторинга тачек которые имели доступ т.е. в случае если эта
>тачка выключена то на сетевухе менялся IP и оп инет есть.
>И что самое главное этим промышляла отнють не молодежь ;)Ну так и что? Защитной мерой эта привязка НЕ является. Ну или не выполняет такие функции. Зато создаёт дополнительную нагрузку в обслуживании: каждое перемещение рабочего места будет вызывать необходимость обновления базы IP => MAC. И как раз с ростом количества клиентов этот геморрой будет только расти.
Вы людей в инет (или куда там ещё) по IP пускаете, и при этом админские права на тачках даёте (а иначе как они IP меняют)? Ну тогда и расхлёбывайте.
Когда с помощью DHCP делается псевдостатика (как тут уже описывали, и я сам стараюсь по возможности это внедрять) - это лишь удобство обслуживания. Полноценную защиту от подобных приколов вам даст только VPN.
>Ну так и что? Защитной мерой эта привязка НЕ является. Ну или не выполняет такие функции. Зато создаёт дополнительную нагрузку в обслуживании: каждое перемещение рабочего места будет вызывать необходимость обновления базы IP => MAC. И как раз с ростом количества клиентов этот геморрой будет только расти.Для некоторых "дядей" проще запретить, чем вникать в тонкости... А про перемещение в пространстве раб. места в таких сетях, а именно перенастройка портов мелочи жизни ... там больше юридического геморроя (разрешения, утверждения, мотивация ....)
>Вы людей в инет (или куда там ещё) по IP пускаете, и при этом админские права на тачках даёте (а иначе как они IP меняют)? Ну тогда и расхлёбывайте.
Это был пример ;)
а из-за ната можно его запустить?
>а из-за ната можно его запустить?Насколько я знаю, DHCP работает в пределах одного хопа, т.е. его нельзя запустить даже из-за перевалочного шлюза без ната. Между сервером и клиентом не должно быть ничего серьезнее свичей и хабов.
>>а из-за ната можно его запустить?
>
>Насколько я знаю, DHCP работает в пределах одного хопа, т.е. его нельзя
>запустить даже из-за перевалочного шлюза без ната. Между сервером и клиентом
>не должно быть ничего серьезнее свичей и хабов.Если по-умному, то IP-броадкасты по определению не выходят за пределы подсети.
DHCP запросы пройдут через любую routed сеть главное чтобы первый маршрутизатор умел DHCP relay(ip helper).
Вы отдаляетесь от начальной темы NAT'а. В данном случае через NAT проходит уже не первичный запрос, а то что генерирует агент пересылки DHCP. То что он есть как сущность - вовсе не факт. Мне кажется что задавший вопрос вообще слабо представлял что он спросил.
Limited broadcast используемый DHCP протоколом в принципе может "ходить" только в пределах одного широковещательного Ethernet домена.