Разрешите ещё один HTTPS-порт через Squid

Обновите оба ACL портов в Squid 6.13 и ограничьте цель, если разрешённый HTTPS-сервис использует порт 8443.

HTTPS-сервис на порту 8443 может не работать через правильно настроенный прокси Squid, даже если обычный HTTPS на 443 работает. Прежде чем менять протокол прокси в клиенте, проверьте отказ CONNECT и политику целевых портов.

В типичной политике доступа Squid 6.13 важны две проверки: цель должна пройти Safe_ports, а CONNECT — SSL_ports. Добавление порта только в один ACL может оставить второй отказ в силе.

Расширяйте существующие определения осознанно

Для политики, разрешающей обычные веб-порты и ещё один HTTPS-порт:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Замените или отредактируйте соответствующие определения, чтобы не сохранить неожиданный старый набор значений. Оставьте обычные правила запрета небезопасных портов и CONNECT, а также предусмотренные ограничения клиентов.

Ограничьте исключение

Если дополнительный порт нужен только для одной контролируемой цели, добавьте адресный запрет перед правилом, разрешающим клиента:

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

Адрес приведён как пример для документации. Используйте цель, которой вы управляете или к которой имеете разрешённый доступ, и учитывайте реальные изменения её адреса. Это ограничивает исключение для дополнительного порта, а не разрешает все цели на 8443.

Выполните разбор всей активной конфигурации и проверьте порядок правил. Правильно записанный запрет после подходящего правила, разрешающего клиента, не обеспечит нужного ограничения.

Проверьте разрешённое имя хоста с его настоящим сертификатом и портом, затем контролируемую цель, которая должна оставаться запрещённой. Сохраняйте проверку TLS включённой, чтобы отличать ошибки идентификации цели от ошибок политики прокси. Не удаляйте всю защиту CONNECT ради работы одного запроса на нестандартный порт.

Похожие статьи