Zure Apache proxyak 3128 portuan entzuten du. Bezero bat ondo iristen da, baina 8443 portuko HTTPS zerbitzu batek huts egiten du. Proxyaren entzute-portua aldatzeak ez du litekeena desberdintasun hori konpontzea.

Bezeroa lehenengo proxyaren entzulearekin konektatzen da. Ondoren, bere CONNECT eskaerak helmuga ostalari eta portu bereizi bat izendatzen ditu. Apachek lehen konexioa onar dezake eta bigarren eragiketa baztertu.

Irakurri AllowCONNECT helmuga-politika gisa

Apache 2.4rako, mod_proxy_connectek kudeatzen ditu sarrerako CONNECT eskaerak. Bere AllowCONNECT direktibak eskaera horien helmuga-portuak kontrolatzen ditu. Dokumentatutako lehenespena 443 eta 563 da.

AllowCONNECT 443 8443

Adibide honek bi helmuga-portu horiek hautatzen ditu. Lehenespen-hautaketa ordezten du; ez du 8443 gehitzen lehenespeneko portu guztiak isilean mantenduz. Erabili direktiba dagokion zerbitzari edo ostalari birtualaren konfigurazioan.

Mantendu proxyaren bezero-baimen arauak lekuan. Baimendutako helmuga-portu batek ez du ezer esaten zein bezerok erabil dezakeen zerbitzua, eta ez da helmuga-ostalariaren murrizketa baten ordezkoa behar denean.

Alderantzizko proxyaren adibide batek beste galdera bati erantzuten dio

Apache eta HTTPS bilaketetan sarritan agertzen da webgune publiko bat backend finko batera birbidaltzen. Konfigurazio hori ez da nabigatzaileak aurreranzko proxyari webgune hautatu batera CONNECT tunel bat irekitzeko eskatzen dion modua. Bere bideratze-direktibak kopiatzeak jatorrizko proxy arazoa ukitu gabe utz dezake.

Hutsegite bat diagnostikatzean, erregistratu bezeroak iritsi zen entzulea, eskatutako CONNECT autoritatea eta proxyaren erantzuna. CONNECT ondo badoa eta TLS gero huts egiten badu, helmuga-portuaren baimenak jada egin du bere zatia. Jarraitu TLS hutsegitearekin AllowCONNECT behin eta berriz zabaltzen jarraitu beharrean.

Erlazionatutako artikuluak