Apache AllowCONNECT i odredišni portovi za HTTPS

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

Klijent se prvo poveže s proxy slušaocem. Njegov CONNECT zahtjev zatim navodi odvojeni 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 kontroliše odredišne portove dostupne tim zahtjevima. Dokumentovana 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 svaki zadani port. Koristite direktivu u odgovarajućoj konfiguraciji servera 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 njenih ruta-direktiva može ostaviti izvorni proxy problem netaknutim.

Kada dijagnosticirate kvar, zabilježite slušaoca do kojeg je klijent stigao, CONNECT authority koji je zatražio i odgovor proxyja. Ako CONNECT uspije, a TLS nakon toga ne uspije, dozvola odredišnog porta već je odradila svoj dio. Nastavite s TLS kvarom umjesto da više puta širite AllowCONNECT.