Apache AllowCONNECT i ports de destinació HTTPS

El vostre proxy Apache escolta al port 3128. Un client hi arriba correctament, però un servei HTTPS al port 8443 falla. Canviar el port d'escolta del proxy probablement no resoldrà aquesta diferència concreta.

El client primer es connecta a l'oient del proxy. Després la seva sol·licitud CONNECT indica un amfitrió i un port de destinació separats. Apache pot acceptar la primera connexió i rebutjar la segona operació.

Llegiu AllowCONNECT com una política de destinació

Per a Apache 2.4, mod_proxy_connect gestiona les sol·licituds CONNECT entrants. La seva directiva AllowCONNECT controla els ports de destinació disponibles per a aquestes sol·licituds. El valor predeterminat documentat és 443 i 563.

AllowCONNECT 443 8443

Aquest exemple selecciona aquests dos ports de destinació. Substitueix la selecció predeterminada; no afegeix 8443 tot mantenint silenciosament tots els ports predeterminats. Utilitzeu la directiva a la configuració de servidor o d'amfitrió virtual corresponent.

Manteniu les regles d'autorització de clients del proxy al seu lloc. Un port de destinació permès no diu res sobre quin client pot utilitzar el servei, i no substitueix una restricció d'amfitrió de destinació quan cal.

Un exemple de proxy invers respon una altra pregunta

Els resultats de cerca d'Apache i HTTPS sovint mostren un lloc web públic que reenvia a un backend fix. Aquesta configuració no és com un navegador demana a un proxy directe que obri un túnel CONNECT cap a un lloc web seleccionat. Copiar-ne les directives d'encaminament pot deixar intacte el problema original del proxy.

En diagnosticar una fallada, registreu l'oient a què va arribar el client, l'autoritat CONNECT que va sol·licitar i la resposta del proxy. Si CONNECT té èxit i TLS falla després, el permís de port de destinació ja ha fet la seva part. Continueu amb la fallada TLS en lloc d'ampliar AllowCONNECT repetidament.