Apache AllowCONNECT i odredišni HTTPS portovi

Vaš Apache proxy sluša na portu 3128. Klijent ga uspješno dosegne, ali HTTPS usluga na portu 8443 ne uspijeva. Promjena porta na kojem proxy sluša vjerojatno neće riješiti tu razliku.

Klijent se prvo povezuje s proxy poslužiteljem. Njegov CONNECT zahtjev zatim navodi zaseban odredišni host i port. Apache može prihvatiti prvu vezu i odbiti drugu operaciju.

Čitajte AllowCONNECT kao odredišnu politiku

Za Apache 2.4, mod_proxy_connect obrađuje dolazne CONNECT zahtjeve. Njegova direktiva AllowCONNECT kontrolira odredišne portove dostupne tim zahtjevima. Dokumentirana zadana vrijednost je 443 i 563.

AllowCONNECT 443 8443

Ovaj primjer bira ta dva odredišna porta. On zamjenjuje zadani izbor; ne dodaje 8443 dok tiho zadržava sve zadane portove. Koristite direktivu u odgovarajućoj konfiguraciji poslužitelja ili virtualnog hosta.

Zadržite pravila autorizacije klijenata proxyja na mjestu. Dozvoljeni odredišni port ne govori ništa o tome koji klijent smije koristiti uslugu i nije zamjena za ograničenje odredišnog hosta kada je ono potrebno.

Primjer obrnutog proxyja odgovara na drugo pitanje

Rezultati pretrage za Apache i HTTPS često prikazuju javnu web stranicu koja prosljeđuje na fiksni backend. Ta konfiguracija nije način na koji preglednik traži od forward proxyja da otvori CONNECT tunel do odabrane web stranice. Kopiranje njezinih usmjeravajućih direktiva može ostaviti izvorni proxy problem netaknutim.

Prilikom dijagnosticiranja kvara zabilježite poslužitelj do kojeg je klijent došao, zatraženi CONNECT autoritet i odgovor proxyja. Ako CONNECT uspije, a TLS zatim ne uspije, dozvola odredišnog porta već je odradila svoj dio. Nastavite s TLS kvarom umjesto da iznova širite AllowCONNECT.