Централизованная схема управления сетью с использованием OpenLDAP: хранение настроек DHCP, DDNS, Squid, IPTables в OpenLDAP, использование Ulog-acctd, Squid, Firebird, Perl для учета трафика, административный клиент Network Console на Java

<P>Для небольшой локальной сети необходимо обеспечить:<BR></P>
<UL>
<LI>Централизованное управление сетевыми настройками рабочих станций (IP-адрес, DNS-имя, маска, адреса шлюза, DNS-сервера, WINS-сервера) на основании MAC-адреса
<LI>Централизованное управление правами доступа в интернет и способом подключения (NAT, прокси, прозрачный прокси)
<LI>Централизованный учет потребляемого трафика по всем возможным параметрам<BR>
<LI>Простой пользователький интерфейс ко всему вышеперечисленному: сеть должен уметь обслуживать человек, имеющий минимальные познания в области системного администрирования. </LI></UL>
<P><A name=decsions></A>Способы решения задач<BR><BR>Традиционно такого рода задачи решаются стандартными средствами открытых UNIX-систем. Для решения каждой подзадачи конфигурируется один из стандарных сервисов:<BR></P>
<UL>
<LI>dhcpd - для автоматической выдачи сетевых настроек клиентам на основании их MAC-адресов либо произвольно
<LI>bind - для прямого и обратного преобразования имен сетевых клиентов и их IP-адресов
<LI>squid - для организации кэширующего прокси-сервера
<LI>ipchains или iptables для Linux и ipfw для FreeBSD - для организации брандмауэра с дополнительными функциями вроде поддержки прозрачного прокси и NAT
<LI>сервер баз данных (как правило, MySQL) для хранения данных о трафике + какая-нибудь система сбора этих данных<BR></LI></UL>
<P>Основной недостаток такого решения - сложность администрирования. Например, чтобы включить в сеть еще один компьютер, необходимо проделать следующее:<BR></P>
<UL>
<LI>прописать этот компьютер в конфигурационном файле dhcpd
<LI>прописать его в файлах прямой и обратной зоны bind
<LI>прописать его в acl squid
<LI>прописать его в стартовом скрипте брандмауэра </LI></UL>
<P>Т.е. человеку, обслуживающего такую систему, приходится выполнять слишком много рутинной работы. Гораздо правильнее будет переложить большую часть работы на плечи компьютера. <BR><BR>Простейшей способ упростить администрирование сводится к выделению наиболее часто изменяемых параметров и вынесению их в отдельное хранилище - текстовый или xml-файл, базу данных и т.д. Затем для каждого сервиса пишется скрипт, вынимающий необходимые данные из главного конфигурационного файла, и генерирующий конфиг для самого сервиса.<BR><BR>Написание скриптов для генерации конфигов может быть довольно трудоемкой задачей. Ситуацию упрощает тот факт, что многие сервисы имеют возможность хранить свои конфигурационные данные не в текстовых файлах, а в некотором внешнем хранилище, в качестве которого чаще всего выступает LDAP. Некоторые особо продвинутые сервисы даже имеют развитые средства для написания собственных backend-ов (примеры - bind и courier-imap), однако LDAP все равно остается самым распространенным внешним хранилищем конфигурационных даных.<BR><BR>Цель данной статьи - показать, как использовать LDAP для хранения конфигурационных данных как тех сервисов, которые непосредственно умеют работать с LDAP, так и тех, которые этого не умеют. Кроме того, в статье будут рассмотрены смежные вопросы, имеющие непосредственное отношение к построению централизованной системы управления сетью: учет трафика и написание кроссплатформенного графического интерфейса к системе управления сетью.</P>
<P>Статья <A href="http://www.linux-os.ru/Members/john/NM" target=_blank>http://www.linux-os.ru/Members/john/NM</A></P>