AllowCONNECT di Apache e le porte di destinazione HTTPS

Il proxy Apache è in ascolto sulla porta 3128. Un client lo raggiunge correttamente, ma un servizio HTTPS sulla porta 8443 non funziona. Cambiare la porta di ascolto del proxy difficilmente risolverà questa differenza specifica.

Il client si connette prima al listener del proxy. La sua richiesta CONNECT indica poi un host e una porta di destinazione separati. Apache può accettare la prima connessione e rifiutare la seconda operazione.

Leggere AllowCONNECT come criterio di destinazione

Per Apache 2.4, mod_proxy_connect gestisce le richieste CONNECT in ingresso. La sua direttiva AllowCONNECT controlla le porte di destinazione disponibili per tali richieste. Il valore predefinito documentato è 443 e 563.

AllowCONNECT 443 8443

Questo esempio seleziona quelle due porte di destinazione. Sostituisce la selezione predefinita; non aggiunge 8443 mantenendo silenziosamente tutte le porte predefinite. Usare la direttiva nella configurazione del server o dell'host virtuale pertinente.

Mantenere le regole di autorizzazione dei client del proxy in vigore. Una porta di destinazione consentita non dice nulla su quale client possa usare il servizio e non sostituisce una restrizione sull'host di destinazione quando serve.

Un esempio di reverse proxy risponde a un'altra domanda

I risultati di ricerca su Apache e HTTPS mostrano spesso un sito pubblico che inoltra a un backend fisso. Quella configurazione non è il modo in cui un browser chiede a un forward proxy di aprire un tunnel CONNECT verso un sito scelto. Copiarne le direttive di routing può lasciare intatto il problema originale del proxy.

Quando si diagnostica un guasto, annotare il listener raggiunto dal client, l'authority CONNECT richiesta e la risposta del proxy. Se CONNECT riesce e TLS fallisce in seguito, l'autorizzazione della porta di destinazione ha già fatto la sua parte. Continuare con l'errore TLS invece di ampliare ripetutamente AllowCONNECT.