Permite un porto HTTPS adicional a través de Squid

Un servizo HTTPS no porto 8443 pode fallar a través dun proxy Squid ben configurado aínda que o HTTPS habitual no 443 funcione. Examina a denegación de CONNECT e a política de portos de destino antes de cambiar o protocolo de proxy do cliente.

Nunha política de acceso típica de Squid 6.13 importan dúas comprobacións: o destino debe superar Safe_ports e CONNECT debe superar SSL_ports. Engadir o porto a unha soa ACL pode deixar vixente a outra denegación.

Amplía as definicións existentes con criterio

Para unha política que permite os portos web habituais e un porto HTTPS adicional:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Substitúe ou edita as definicións correspondentes para non deixar un conxunto antigo de valores inesperado. Conserva as regras habituais de denegación de portos inseguros e de CONNECT, así como as restricións de clientes previstas.

Limita a excepción

Se o porto adicional só é necesario para un destino controlado, engade unha denegación específica antes da regra que permite o cliente:

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

O enderezo é un valor de exemplo para documentación. Usa o destino que administras ou ao que tes autorización para acceder e ten en conta os cambios reais do seu enderezo. Isto limita a excepción do porto adicional en vez de permitir todos os destinos no 8443.

Analiza a configuración activa completa e revisa a orde das regras. Unha denegación ben escrita situada despois dunha regra coincidente que permite o cliente non aplicará a restrición prevista.

Proba o nome de host autorizado co seu certificado e porto reais e despois proba un destino controlado que deba seguir denegado. Manter activa a verificación TLS permite distinguir os erros de identidade do destino dos erros da política do proxy. Non elimines toda a protección de CONNECT para facer funcionar unha única solicitude a un porto personalizado.