Apache AllowCONNECT in ciljna vrata HTTPS
Ločite vrata, ki jih odjemalci uporabljajo za dostop do proxyja Apache, od ciljnih vrat, ki jih mod_proxy_connect dovoljuje znotraj tunelov.
Vaš proxy Apache posluša na vratih 3128. Odjemalec jih uspešno doseže, storitev HTTPS na vratih 8443 pa ne uspe. Sprememba vrat poslušanja proxyja te razlike verjetno ne bo odpravila.
Odjemalec se najprej poveže s poslušalcem proxyja. Njegova zahteva CONNECT nato navede ločenega ciljnega gostitelja in vrata. Apache lahko prvo povezavo sprejme in drugo operacijo zavrne.
Berite AllowCONNECT kot ciljno politiko
V Apache 2.4 mod_proxy_connect obdeluje dohodne zahteve CONNECT. Njegova direktiva AllowCONNECT nadzoruje ciljna vrata, ki so na voljo tem zahtevam. Dokumentirana privzeta vrednost je 443 in 563.
AllowCONNECT 443 8443Ta primer izbere ti dve ciljni vrati. Nadomesti privzeti izbor; ne doda 8443, hkrati pa tiho obdrži vsa privzeta vrata. Uporabite direktivo v ustrezni konfiguraciji strežnika ali navideznega gostitelja.
Ohranite pravila za avtorizacijo odjemalcev proxyja. Dovoljena ciljna vrata ne povedo nič o tem, kateri odjemalec sme uporabljati storitev, in ne nadomestijo omejitve ciljnega gostitelja, ko je ta potrebna.
Primer obratnega proxyja odgovarja na drugo vprašanje
Rezultati iskanja za Apache in HTTPS pogosto prikažejo javno spletno mesto, ki posreduje na fiksni backend. Ta konfiguracija ni način, kako brskalnik prosi posredniški proxy, naj odpre tunel CONNECT do izbranega spletnega mesta. Kopiranje njegovih usmerjevalnih direktiv lahko pusti prvotno težavo proxyja nedotaknjeno.
Pri diagnosticiranju napake zabeležite poslušalca, ki ga je odjemalec dosegel, zahtevano avtoriteto CONNECT in odgovor proxyja. Če CONNECT uspe in TLS nato ne uspe, je dovoljenje ciljnih vrat že opravilo svoj del. Nadaljujte z napako TLS, namesto da bi AllowCONNECT znova in znova širili.