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

[Денис Черносов]

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

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

Настроено несколько лет назад и за это время появились кое-какие
идеи/пожелания:

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/2088375e/attachment-0002.html>