Назад | Перейти на главную страницу

Squid аутентификация и потоковая передача

У меня есть настройка squid с использованием аутентификации Kerberos. Я также использую squidguard в качестве перенаправителя URL-адресов, чтобы заблокировать обычную гадость в Интернете. Однако есть некоторые сайты, которые мы разрешаем определенным пользователям, а другие - нет. Все это работает хорошо, если я не использую потоковую передачу.

Из того, что я могу определить из журналов squid и трассировок wirehark, которые я сделал, когда отправляется первоначальный запрос на поток, все в порядке, аутентифицированное имя пользователя отправляется с запросом в squidguard. Проблема в том, что при последующем трафике имя пользователя не отправляется в squidguard, что приводит к его блокировке в соответствии с политикой по умолчанию.

Я пробовал использовать встроенный в squid механизм разрешения / запрета, но он довольно неуклюжий, и до сих пор squidguard был довольно простым и быстрым.

Вот вопрос (ы):

Несколько важных деталей:

редактировать

Для пояснения я добавил следующий фрагмент Calamaris, чтобы продемонстрировать, что происходит:

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

user2@DOMAIN.LOCAL@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

Итак, я понял это. Оказывается, в моем squid.conf были некоторые другие ACL, которые разрешали неаутентифицированный трафик через прокси. Поскольку эти правила применялись раньше, чем правила, запрещающие неаутентифицированный трафик, трафик отправлялся неаутентифицированным.

Я надеюсь, что это послужит хорошим ресурсом для всех, кто пытается сделать что-то подобное.