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

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 защита, за да заработи една заявка към нестандартен порт.