Вот я больше чем уверен, начинающи( и не только начинающий) системный администратор бросается настраивать прозрачный (transparent) прокси, потому что: это круто, сохраним трафик, не надо у всех ходить и настройки делать и бла-бла-бла.

Ну да, настройки делать не надо для всех.

Так вот, дорогие мои, каким злом это оборачивается: мы не можем аутентифицировать пользователя. Да - да, в таком случае мы не можем проверить, что к нам в кеш пришел "Вася Пупкин". К примеру, в моей связке есть сквид, когда аккаунт может сидеть и на кучке терминальных серверов (а вот представьте ежели все предприятие будет работать на терминальных серверах). Для такого случая я  сделал аутентификацию пользователя по его аккаунту в Active Directory. Очень просто, через ntlm.

auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes

auth_param basic program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

acl ad-auth proxy_auth REQUIRED

http_access allow localnet ad-auth

 эти строки в squid.conf обеспечивают прозрачную авторизацию в IE. Если клиентский компьютер не в домене или же браузер очень альтернативный, то будет в начале сессии браузера запрашиваться окно (basic auth) в которое можно отправить логин и пароль соответствующие вашему доменному аккаунту.

Вся эта радость возможна только при непосредственном указании прокси для клиентов.

Поэтому мы делаем следующие процедуры:

1. на нашем мегароутере фаерволом запрещаем исходящие соединения от клиентов в инет напрямую по портам 80,81,8080,3128,21,443 (добавить по вкусу)
2. указываем через групповую политику всем аккаунтам в ActiveDirectory ходить через наш  прокси (192.168.0.1:3128)

Что мы будем иметь в итоге? Очень просто, мы будем иметь в лог-файле записи содержащие логин пользователя!

1160734900.705     86 192.168.0.29 TCP_MISS/302 253 GET http://c.bigmir.net/? ivanchenko FIRST_UP_PARENT/it-link.com.ua - 

Ну а распарсить логи и отобразить в статистике - дело техники. Пожалуй, выложу в виде проекта мою систему распарсивания в БД MySQL базу логов + web интерфейс на Parser3 (испугались?). Кстати, отказался от использования pipe механизма для записи логов сквида прямо в базу, ибо при любом глюке БД сквид имел скверную привычку отваливаццо. Самый эффективный способ снятия логов в базу, по моему мнению, таков: сквид пишет лог в обычный файл, по крону переворачивает логи (squid -k rotate), перевернутый файл access.log.0 скармливаем скрипту, который распарсивает лог в базу, по окончании удаляем распарсеный лог. Плюсы такого подхода более чем очевидны: 

• сквид теперь не отваливается
• логи подчищаются, поэтому не раздуваются до необъятных размеров
• можно варьировать промежутки распарсивания логов до нужных  значений, например, реалтайм логи, как правило, мало кому нужны. Для меня оптимальным оказался промежуток распарсивания раз в 30 минут.

Вот такая, напоследок, интересная статистика:

У нас на предприятии около 100 хостов, из них 70 - активные веб-пользователи, количество записей в MySQL  3-4 млн. записей в месяц. Для того что бы база на таких количествах не умирала испольуются правильные индексы (само собой) и дополнительная агреггирующая таблица. Т.е. пишем "чиста" лог + update накопительных счетчиков по конкретному пользователю за одну атомарную запись строки лога, это позволяет быстро сгруппировать и просуммировать трафик (а попробуйте без этого просуммировать на 3х млн записей).  За основу был  взят очень правильный скрипт squid2mysql.