Apachen AllowCONNECT ja HTTPS-kohdeportit
Erota toisistaan portti, jolla asiakkaat tavoittavat Apache-välityspalvelimen, ja kohdeportit, jotka mod_proxy_connect sallii tunneleissa.
Apache-välityspalvelimesi kuuntelee porttia 3128. Asiakas tavoittaa sen onnistuneesti, mutta HTTPS-palvelu portissa 8443 epäonnistuu. Välityspalvelimen kuunteluportin vaihtaminen tuskin ratkaisee tätä eroa.
Asiakas yhdistää ensin välityspalvelimen kuuntelijaan. Sen CONNECT-pyyntö nimeää tämän jälkeen erillisen kohdeisännän ja -portin. Apache voi hyväksyä ensimmäisen yhteyden ja hylätä toisen toiminnon.
Lue AllowCONNECT kohdekäytännöksi
Apache 2.4:ssä mod_proxy_connect käsittelee saapuvat CONNECT-pyynnöt. Sen AllowCONNECT-direktiivi ohjaa näille pyynnöille käytettävissä olevia kohdeportteja. Dokumentoitu oletusarvo on 443 ja 563.
AllowCONNECT 443 8443Tämä esimerkki valitsee juuri ne kaksi kohdeporttia. Se korvaa oletusvalinnan; se ei lisää porttia 8443 ja samalla säilytä äänettömästi kaikkia oletusportteja. Käytä direktiiviä asianmukaisessa palvelin- tai virtuaali-isäntäkokoonpanossa.
Pidä välityspalvelimen asiakasvaltuutussäännöt paikallaan. Sallittu kohdeportti ei kerro, mikä asiakas saa käyttää palvelua, eikä se korvaa kohdeisännän rajoitusta, kun sellainen tarvitaan.
Käänteisen välityspalvelimen esimerkki vastaa eri kysymykseen
Apachen ja HTTPS:n hakutulokset näyttävät usein julkisen verkkosivuston, joka välittää kiinteään taustajärjestelmään. Se kokoonpano ei ole tapa, jolla selain pyytää eteenpäin välittävää välityspalvelinta avaamaan CONNECT-tunnelin valittuun verkkosivustoon. Sen reititysdirektiivien kopioiminen voi jättää alkuperäisen välityspalvelinongelman koskemattomaksi.
Vian diagnosoinnissa kirjaa kuuntelija, jonka asiakas tavoitti, pyydetty CONNECT-auktoriteetti ja välityspalvelimen vastaus. Jos CONNECT onnistuu ja TLS epäonnistuu sen jälkeen, kohdeportin lupa on jo tehnyt osansa. Jatka TLS-virheestä sen sijaan, että laajentaisit AllowCONNECTia toistuvasti.