не за что благодарить, сам при помощи хабра познавал эту науку.
как совет глянуть логику в конфиге, а именно тут ssl_bump peek step1
ssl_bump terminate blacklist_ssl
ssl_bump splice whitelist_ssl
ssl_bump terminate all worktime
ssl_bump splice all
я бы убрал бы 3-ю строку, а 4-ю переделал бы так
ssl_bump terminate all worktime !whitelist_ssl
т. к. белый список нам разрешён всегда, то и запрещать его не нужно и строка говорит блокировать всё в рабочее время кроме белого списка.
и последняя строка говорит, что устанавливать все соединения, что не вошли в предыдущие правила.
если в рабочее время вообще всё запрещено, тогда и разрешающее правило для белого списка не нужно.
А Вам и не нужно nat-ить пакеты на http/https портах, их нужно перенаправлять (если микрот в такое умеет, проверить нет и не скоро появится возможность) на сквид. Но сразу тогда исключить на микроте пакеты с сквида, иначе получится цикл, между микротом и сквидом.
Если у Вас в прозрачном режиме домены с белого списка ругаются на сертификат, то посмотрите лог сквида cache.log, там скорее всего присутствуют записи SECURITY ALERT: Host header forgery detected on ... (local IP does not match any domain IP)
Если это так, то это фитча (не баг) сквида, в плане безопасности и вот тут есть лекарство для этого, но придётся пересобирать пакет. Этот патч работает в том числе и на 4.8 версии.
для использования сквида не нужно подменять сертификат и явно указывать настройки прокси у клиента, достаточно собрать сквид с поддержкой ssl, что автор и сделал, указать сквиду порт прозрачного проксирование и обычными средствами firewall зарулить трафик на нужные порты, что так же автор сделал. Возможны какие-то отличия настройки микротов от ipfw могут быть. У меня на боевом рабочем сервере все пакеты с локального интефейса по портам 80, 8080, 443 заруливаются на локалхост и оттуда уже на сквид.
ну или на крайний случай, в самом микроте в DHCP сервере указать скивд в качестве шлюза.
тогда решится и ещё одна проблема автора, что в локах сквида только ip микротика.
1. Зачем собирать старый сквид, когда уже доступен 4.8, исправно работающий?
2. Надеюсь Вы не столкнулись с проблемой, когда браузер на домены в белом списке ругается на недействительные сертификаты. Пример с тем же mail.ru Сам сайт открывается, а вот вложения, авторизация, выход выдают «ERR_SSL_PROTOKOL_ERROR». Это болезнь сквида с версий, когда появилась директива ssl-bump. Решением которой будет патч указанный в этой статье.
3. По конфигу сквида, не вижу, где Вы разрешили себе ходить во всюду, а остальным ходить нельзя. Можно добавить пару ACL типо admin, teachers, students, servers в которых указаны соответствующие ip или сразу диапазоны ip (например 192.168.1.12-192.168.1.58). И соответственно прописать запреты/разрешения в http_access и в ssl_bump кому по какому списку ходить (например: ssl_bump terminate students !admin blacklist_ssl)
4. строка «ssl_bump splice whitelist_ssl» абсолютно не нужна, т. к. основным правило идёт разрешить всё, что не запрещено, а именно «ssl_bump splice all»
PS. На работе использую сквида 4.8 собранного на freebsd 11.2 (основной GW), Debian 9 (тестовый GW) и у пары знакомых на Debian 9 в качестве детского firewall.
как совет глянуть логику в конфиге, а именно тут
ssl_bump peek step1ssl_bump terminate blacklist_ssl
ssl_bump splice whitelist_ssl
ssl_bump terminate all worktime
ssl_bump splice all
я бы убрал бы 3-ю строку, а 4-ю переделал бы так
ssl_bump terminate all worktime !whitelist_sslт. к. белый список нам разрешён всегда, то и запрещать его не нужно и строка говорит блокировать всё в рабочее время кроме белого списка.
и последняя строка говорит, что устанавливать все соединения, что не вошли в предыдущие правила.
если в рабочее время вообще всё запрещено, тогда и разрешающее правило для белого списка не нужно.
SECURITY ALERT: Host header forgery detected on ... (local IP does not match any domain IP)Если это так, то это фитча (не баг) сквида, в плане безопасности и вот тут есть лекарство для этого, но придётся пересобирать пакет. Этот патч работает в том числе и на 4.8 версии.
ну или на крайний случай, в самом микроте в DHCP сервере указать скивд в качестве шлюза.
тогда решится и ещё одна проблема автора, что в локах сквида только ip микротика.
2. Надеюсь Вы не столкнулись с проблемой, когда браузер на домены в белом списке ругается на недействительные сертификаты. Пример с тем же mail.ru Сам сайт открывается, а вот вложения, авторизация, выход выдают «ERR_SSL_PROTOKOL_ERROR». Это болезнь сквида с версий, когда появилась директива ssl-bump. Решением которой будет патч указанный в этой статье.
3. По конфигу сквида, не вижу, где Вы разрешили себе ходить во всюду, а остальным ходить нельзя. Можно добавить пару ACL типо admin, teachers, students, servers в которых указаны соответствующие ip или сразу диапазоны ip (например 192.168.1.12-192.168.1.58). И соответственно прописать запреты/разрешения в http_access и в ssl_bump кому по какому списку ходить (например: ssl_bump terminate students !admin blacklist_ssl)
4. строка «ssl_bump splice whitelist_ssl» абсолютно не нужна, т. к. основным правило идёт разрешить всё, что не запрещено, а именно «ssl_bump splice all»
PS. На работе использую сквида 4.8 собранного на freebsd 11.2 (основной GW), Debian 9 (тестовый GW) и у пары знакомых на Debian 9 в качестве детского firewall.