У меня есть настройка squid с использованием аутентификации Kerberos. Я также использую squidguard как URL-редиктор, чтобы блокировать обычную пакость веба. Однако есть некоторые сайты, которые мы разрешаем определенным пользователям, а другим — нет. Все это работает хорошо, если я не использую потоковую передачу.
Из того, что я могу определить из логов squid и трассировок wireshark, которые я сделал, когда отправляется первоначальный запрос на поток, все хорошо, аутентифицированное имя пользователя отправляется с запросом в squidguard. Проблема в том, что при последующем трафике имя пользователя не отправляется в squidguard, что приводит к его блокировке на основе политики по умолчанию.
Я пробовал использовать встроенную в Squid функцию разрешения/запрета, но она довольно неуклюжа, а Squidguard пока что довольно прост и быстр.
Вот вопрос(ы):
- Как заставить Squid передавать имя пользователя во всех запросах? (что-то мне подсказывает, что это не лучший способ)
- Как заставить Squidguard видеть, что трафик аутентифицируется для определенного пользователя, даже если имя пользователя не передано?
- Есть ли другой способ добиться этого?
Несколько деталей, которые могут иметь значение:
- Я использую список пользователей, сохраненный в текстовом файле, с которым Squidguard может сравнивать свои данные.
- Я использую полную аутентификацию Kerberos со Squid.
- CentOS 6.0
- Кальмар 3.1.4
- Сквидгард 1.3
Редактировать
Для пояснения я добавил следующий фрагмент кода кальмара, демонстрирующий происходящее:
wsXX.domain.local 534 5.99 34M 3.04 1 69.93
*.outsidedomain.com 204 14.22 5M 20.66 0 92.14
<error> 137 0.00 0M 0.00 0 589.16
[email protected]@wsXX.domain.local 115 0.00 1M 0.00 70 0.16
*.outsidedomain.com 84 0.00 1M 0.00 73 0.17
<error> 24 0.00 0M 0.00 21 0.00
* РЕДАКТИРОВАТЬ *
По мере того, как я углублялся в кроличью нору, оказалось, что в частности, он не аутентифицируется в ответах на HTTP-запросы. Фактически, если я вставлю в statemenet
http_reply_access deny !auth
Он не будет пропускать https-трафик, но будет пропускать большую часть http-трафика. Я в полном замешательстве, на самом деле похоже, что он пропускает неаутентифицированный трафик (сегодня буду тестировать) [Протестировано, и он пропускает неаутентифицированный http-трафик, но горячий https], хотя у меня в squid.conf есть следующие строки:
http_access deny !auth
http_access allow auth
http_access deny all
* РЕДАКТИРОВАТЬ * Я исправил неаутентифицированный http и httpsm, все, похоже, работает хорошо, за исключением потоковых сайтов :(
для чего это стоило мне пришлось изменить следующую строку в конфигурации
http_access deny !Safe_ports
к
http_access deny !Safe_ports !auth
решение1
Итак, я понял это. Оказывается, в моем squid.conf были некоторые другие ACL, которые разрешали неаутентифицированный трафик через прокси. Поскольку эти правила срабатывали до правил, запрещающих неаутентифицированный трафик, трафик отправлялся через неаутентифицированный.
Надеюсь, это послужит хорошим источником информации для тех, кто пытается сделать что-то подобное.