Apache AllowCONNECT kaj HTTPS-cellokhavenoj

Via Apache-prokurilo aŭskultas sur pordo 3128. Kliento sukcese atingas ĝin, sed HTTPS-servo sur pordo 8443 fiaskas. Ŝanĝi la aŭskultan pordon de la prokurilo verŝajne ne solvos tiun specifan diferencon.

La kliento unue konektiĝas al la prokurila aŭskultilo. Poste ĝia CONNECT-peto nomas apartan celan gastiganton kaj pordon. Apache povas akcepti la unuan konekton kaj malakcepti la duan operacion.

Legu AllowCONNECT kiel cellokan politikon

Por Apache 2.4, mod_proxy_connect traktas alvenantajn CONNECT-petojn. Ĝia direktivo AllowCONNECT regas la cellokhavenojn disponeblajn por tiuj petoj. La dokumentita defaŭlto estas 443 kaj 563.

AllowCONNECT 443 8443

Ĉi tiu ekzemplo elektas tiujn du cellokhavenojn. Ĝi anstataŭigas la defaŭltan elekton; ĝi ne aldonas 8443 dum ĝi silentas ĉiun defaŭltan pordon. Uzu la direktivon en la aplikebla servila aŭ virtualgastiganta agordo.

Konservu la klientajn rajtigajn regulojn de la prokurilo surloke. Permesita cellokhaveno diras nenion pri tio, kiu kliento rajtas uzi la servon, kaj ĝi ne anstataŭas limigon de la cela gastiganto, kiam ĝi necesas.

Ekzemplo de inversa prokurilo respondas al alia demando

Serĉrezultoj pri Apache kaj HTTPS ofte montras publikan retejon plusendantan al fiksa malantaŭaĵo. Tiu agordo ne montras, kiel retumilo petas antaŭan prokurilon malfermi CONNECT-tunelon al elektita retejo. Kopii ĝiajn enkursigajn direktivojn povas lasi la originan prokurilan problemon netuŝita.

Kiam vi diagnozas fiaskon, registru la aŭskultilon, kiun la kliento atingis, la CONNECT-aŭtoritaton, kiun ĝi petis, kaj la respondon de la prokurilo. Se CONNECT sukcesas kaj TLS poste fiaskas, la cellokhavena permeso jam faris sian parton. Daŭrigu per la TLS-fiasko anstataŭ ripete larĝigi AllowCONNECT.