Apache AllowCONNECT y los puertos de destino HTTPS

Su proxy Apache escucha en el puerto 3128. Un cliente lo alcanza correctamente, pero un servicio HTTPS en el puerto 8443 falla. Cambiar el puerto de escucha del proxy probablemente no resolverá esa distinción concreta.

El cliente primero se conecta al listener del proxy. Luego su solicitud CONNECT indica un host y un puerto de destino separados. Apache puede aceptar la primera conexión y rechazar la segunda operación.

Lea AllowCONNECT como una política de destino

Para Apache 2.4, mod_proxy_connect gestiona las solicitudes CONNECT entrantes. Su directiva AllowCONNECT controla los puertos de destino disponibles para esas solicitudes. El valor predeterminado documentado es 443 y 563.

AllowCONNECT 443 8443

Este ejemplo selecciona esos dos puertos de destino. Reemplaza la selección predeterminada; no añade 8443 mientras conserva silenciosamente todos los puertos predeterminados. Utilice la directiva en la configuración de servidor o de host virtual correspondiente.

Mantenga las reglas de autorización de clientes del proxy en su sitio. Un puerto de destino permitido no dice nada sobre qué cliente puede usar el servicio, y no sustituye a una restricción de host de destino cuando se necesita una.

Un ejemplo de proxy inverso responde a otra pregunta

Los resultados de búsqueda sobre Apache y HTTPS suelen mostrar un sitio web público que reenvía a un backend fijo. Esa configuración no es cómo un navegador pide a un proxy directo que abra un túnel CONNECT hacia un sitio web seleccionado. Copiar sus directivas de enrutamiento puede dejar intacto el problema original del proxy.

Al diagnosticar un fallo, registre el listener al que llegó el cliente, la autoridad CONNECT que solicitó y la respuesta del proxy. Si CONNECT tiene éxito y TLS falla después, el permiso del puerto de destino ya ha hecho su parte. Continúe con el fallo de TLS en lugar de ampliar AllowCONNECT repetidamente.