Apache AllowCONNECT și porturile de destinație HTTPS

Proxy-ul dumneavoastră Apache ascultă pe portul 3128. Un client îl atinge cu succes, dar un serviciu HTTPS pe portul 8443 eșuează. Schimbarea portului de ascultare al proxy-ului nu va rezolva probabil această diferență.

Clientul se conectează mai întâi la listenerul proxy-ului. Cererea CONNECT a acestuia numește apoi un host și un port de destinație separate. Apache poate accepta prima conexiune și respinge a doua operațiune.

Citiți AllowCONNECT ca pe o politică de destinație

Pentru Apache 2.4, mod_proxy_connect gestionează cererile CONNECT primite. Directiva sa AllowCONNECT controlează porturile de destinație disponibile pentru aceste cereri. Valoarea implicită documentată este 443 și 563.

AllowCONNECT 443 8443

Acest exemplu selectează cele două porturi de destinație. Înlocuiește selecția implicită; nu adaugă 8443 păstrând în tăcere toate porturile implicite. Folosiți directiva în configurația corespunzătoare a serverului sau a gazdei virtuale.

Păstrați regulile de autorizare a clienților proxy-ului. Un port de destinație permis nu spune nimic despre ce client poate folosi serviciul și nu înlocuiește o restricție de host de destinație atunci când este necesară.

Un exemplu de proxy invers răspunde la o altă întrebare

Rezultatele căutării pentru Apache și HTTPS arată frecvent un site public care redirecționează către un backend fix. Acea configurație nu este modul în care un browser cere unui proxy forward să deschidă un tunel CONNECT către un site ales. Copierea directivelor sale de rutare poate lăsa problema inițială a proxy-ului neatinsă.

Când diagnosticați o defecțiune, notați listenerul atins de client, autoritatea CONNECT solicitată și răspunsul proxy-ului. Dacă CONNECT reușește și TLS eșuează ulterior, permisiunea portului de destinație și-a făcut deja partea. Continuați cu defecțiunea TLS în loc să lărgiți AllowCONNECT în mod repetat.