[Comm] Вопрос по хитрой настройке SQUID и сопутствующих служб

Денис Черносов =?iso-8859-1?q?denis0=2Eru_=CE=C1_gmail=2Ecom?=
Пн Дек 17 12:45:14 MSK 2007


Добрый день. Ситуация следующая:

Есть у меня сетка, в которой большинство машин работает с ограниченным
списком ресурсов. А для некоторых машин открыт полный доступ. Фильтрация
привязана к IP машин. Часть машин вбита в DNS руками, а остальные получают
IP через dhcp. Прозрачное проксирование.

Неудобств в такой схеме много. Хотелось бы следующих улучшений:
1) Хотелось бы все адреса и имена машин формировать динамически. А то, что
должно обладать конкретным ip, hostname, резервировать непосредственно в
dhcp (например, сетевой МФУ HP3055). Информацию о DNS зонах и
dhcp.leasesхочется хранить в LDAP (не то, чтобы совсем суровая
необходимость, но
хочется :) ).

2) http (и желательно также ftp) трафик по умолчанию лучше бы прозрачно
проксировать и ограничивать списком, независимо от ip (или с учетом только
тех, что зарезервированы с помощью dhcp). Такие же права желательно дать
тем, кто ввел прокси явно, но не авторизовался или авторизовался
неправильно.
Чтобы вопросов было меньше.

3) Тех, кому нужно больше, надо бы обязать авторизоваться на прокси. Сейчас
у меня авторизация делается через LDAP, в котором у учетных записей есть
атрибуты и POSIX и Samba. Чтобы не заморачиваться и не привязываться к Самбе
лишний раз, лучше использовать POSIX атрибуты. При этом, авторизованные
юзеры должны получать права соответственно членству в спец. группах
(наверное тоже POSIX). Типа user1,user2 члены спец. группы proxy_filtered
(всё, кроме отрезанного порно- и/или другим фильтром), user3, user4 -
proxy_unlim (вообще всё), user5,user6 - proxy_direct (всё, без кэширования).
4) Если юзеры везде будут использовать сетевой home, то привилегированным
юзерам настроить параметры прокси достаточно только один раз для каждого
браузера. Если нет, то достаточно вбить опции один раз для каждого браузера
на каждой машине (если у каждого привилегированного юзера отдельная учетная
запись). Но, разумеется, наиудобнейшим выходом видится сквозная авторизация
при открытии сессии юзера на машине - авторизовался при входе в KDE и
логин/пароль прокси подставился в нужные места автоматически. Без последнего
можно жить, но хотелось бы узнать о принципиальной возможности сотворения
такого чуда...

5) Отдельный вопрос - фильтрация не http-трафика. Она обычно делается через
iptables, но желательно её тоже как-то привязывать к группам юзеров, а не их
ip. Как вариант на заданную тему, видел статью про совместную настройку
Samba, dhcp, iptables. С авторизацией в Самбе и добавлением/удалением правил
в iptables при авторизации и в конце сессии (правила добавляются по ip, а
соответствие user-ip узнается в момент авторизации). Но в сетке с
линуксовыми клиентами авторизация в Самбе порождает один большой минус -
uid-ы и gid-ы получаются неуникальными в пределах сетки. А это может
породить проблемы при использовании ресурсов по протоколам отличным от smb.
Есть ли информация по запуску подобного механизма при прямой авторизации в
LDAP-е?


Если совсем кратко, то хотелось бы, конечно, какое-нибудь обобщенное решение
из коробки с централизованной сквозной авторизацией win|lin клиентов,
ограничением доступа (и подсчетом трафика! как я мог забыть :) ) по группам
пользователей и максимальным сохранением/использованием OC-специфических
атрибутов учетных записей.

Важное замечание: кэширование трафика интересует в последнюю очередь.
Гораздо важнее скорость и удобство настройки сервера, гибкость фильтрации,
привязка фильтрации к группам юзеров, наличие "умолчальных" профилей, а
также минимизация телодвижений на клиентских машинах и для самих клиентов.
Поэтому, если есть howto без участия SQUID (может быть privoxy?), то с
удовольствием вчитаюсь.

Знаю, что губа - не дура, но буду рад и частичному решению и вообще
обсуждению проблемы, как она видна другим админам. Или разумной критике
постановки задачи.
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/community/attachments/20071217/3d3349a9/attachment-0002.html>


Подробная информация о списке рассылки community