>Я бы не утверждал обратного, если бы не видел описанной мной реализвации
>на соляре, но тот сисадмин не счёл возможным объяснить, как он
>добился подобного эффекта.
Если посмотреть протокол dhcp, то единственно возможным параметром, однозначно идентифицирующим клиента, является mac. Если в солярис придумали что-то новое - расскажите, крайне интересно.>К сожалению, всё, что я нашел было в стиле - "если вы
>не знаете, как это работает, то вам и не нужно этого
>знать"...
>Может я не там искал, дайте, плз, ссылку?
Например
http://www.tcpipguide.com/free/t_BOOTPRelayAgentsForwardingA...
>Действительно! Почитайте внимательнее мой вопрос, а так же его разъяснение. А как
>Вы даёте ответы не ознакомившись с вопросом?
Копирую то, что уже писал.
"Если в пересылаемых запросах (в заголовке Ethernet) он ставит свой mac, то попробовать разрешить iptables-ом все пакеты на udp/67 только с этого mac"
Здесь что-то непонятно?
>DHCP - для выдачи IP по мак;
>ARP - для грубой защиты от подмены IP-адресов;
В соляре ARP - отдельная программа? И он может брать данные из SQL?
>Различные мониторы для более тонкой защиты.
Например?
>Но вопрос не конкретно в DHCP<->mac.
>При регистрации клиента нужно указать кучу параметров (мак и ИП толко два
>из них). Весело, когда для почты нужно прописывать данные клиента в
>одном конфиге, для DHCP в другом, для аутентификации в третьем, для
>своего FTP - в четвёртом, etc. (Хотя можно все эти данные
>хранить в одном месте). Слава Богу! Большинство программ умеют получать данные
>из единого источника, но как научить делать это DHCP?
Для smtp, ftp и аутентификации нужны mac<->ip? Какой софт Вы используете?
>А что касается DHCP, то клиент может и карточку поменять. Нужно ворошить
>базу - исправлять.
>Я работал с конторой, которая для подобных вещей требовала являться в офис
>и писать заявление (с указанием причины - почему меняю карту). Работать
>с этой конторой было "одно удовольствие". Лично меня хватило на 2
>недели.
Я предложил вариант решения указанной Вами проблемы, а не замены клиентом сетевой карты.