Apache AllowCONNECT dhe portat e destinacionit HTTPS

Proxy-ja juaj Apache dëgjon në portën 3128. Një klient e arrin me sukses, por një shërbim HTTPS në portën 8443 dështon. Ndryshimi i portës dëgjuese të proxy-së nuk ka gjasa ta zgjidhë atë dallim.

Klienti lidhet fillimisht me dëgjuesin e proxy-së. Kërkesa CONNECT e tij më pas emërton një host dhe portë destinacioni të veçantë. Apache mund të pranojë lidhjen e parë dhe të refuzojë veprimin e dytë.

Lexojeni AllowCONNECT si politikë destinacioni

Për Apache 2.4, mod_proxy_connect trajton kërkesat CONNECT hyrëse. Direktiva e tij AllowCONNECT kontrollon portat e destinacionit të disponueshme për ato kërkesa. Vlera e parazgjedhur e dokumentuar është 443 dhe 563.

AllowCONNECT 443 8443

Ky shembull zgjedh ato dy porta destinacioni. Ai zëvendëson zgjedhjen e parazgjedhur; nuk shton 8443 duke i mbajtur në heshtje të gjitha portat e parazgjedhura. Përdoreni direktivën në konfigurimin përkatës të serverit ose të hostit virtual.

Mbani rregullat e autorizimit të klientëve të proxy-së në vend. Një portë destinacioni e lejuar nuk thotë asgjë se cili klient mund ta përdorë shërbimin dhe nuk zëvendëson një kufizim të hostit të destinacionit kur ai nevojitet.

Një shembull i proxy-së së kundërt përgjigjet një pyetjeje tjetër

Rezultatet e kërkimit për Apache dhe HTTPS shpesh tregojnë një faqe interneti publike që përcjell te një backend fiks. Ai konfigurim nuk është mënyra se si një shfletues i kërkon një proxy forward të hapë një tunel CONNECT drejt një faqeje të zgjedhur. Kopjimi i direktivave të tij të rrugëzimit mund ta lërë problemin origjinal të proxy-së të paprekur.

Kur diagnostikoni një dështim, regjistroni dëgjuesin që arriti klienti, autoritetin CONNECT që kërkoi dhe përgjigjen e proxy-së. Nëse CONNECT ka sukses dhe TLS dështon më pas, leja e portës së destinacionit e ka kryer tashmë pjesën e vet. Vazhdoni me dështimin TLS në vend që ta zgjerojnë AllowCONNECT vazhdimisht.