Apacheov AllowCONNECT i odredišni portovi za HTTPS
Razlikujte port kojim klijenti dolaze do Apacheovog proxyja od odredišnih portova koje mod_proxy_connect dopušta unutar tunela.
Vaš Apacheov proxy sluša na portu 3128. Klijent ga uspješno dosegne, no HTTPS usluga na portu 8443 ne uspijeva. Promjena porta za slušanje proxyja vjerojatno neće riješiti tu razliku.
Klijent se najprije povezuje s proxyjevim slušačem. Njegov CONNECT zahtjev zatim navodi zasebnog odredišnog hosta i port. Apache može prihvatiti prvu vezu i odbiti drugu operaciju.
Čitajte AllowCONNECT kao politiku odredišta
Za Apache 2.4, mod_proxy_connect obrađuje dolazne CONNECT zahtjeve. Njegova direktiva AllowCONNECT upravlja odredišnim portovima dostupnima tim zahtjevima. Dokumentirani je zadani izbor 443 i 563.
AllowCONNECT 443 8443Ovaj primjer odabire ta dva odredišna porta. On zamjenjuje zadani odabir; ne dodaje 8443 i pritom tiho ne zadržava sve zadane portove. Koristite direktivu u odgovarajućoj konfiguraciji poslužitelja ili virtualnog hosta.
Zadržite pravila autorizacije klijenata proxyja na mjestu. Dopušteni 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 pretraživanja za Apache i HTTPS često prikazuju javno web-mjesto koje prosljeđuje na fiksni backend. Ta konfiguracija nije način na koji preglednik traži od naprijed usmjerenog proxyja da otvori CONNECT tunel do odabranog web-mjesta. Kopiranje njegovih direktiva usmjeravanja može ostaviti izvorni proxy problem nedirnutim.
Pri dijagnosticiranju kvara zabilježite slušač do kojeg je klijent došao, zatraženi CONNECT autoritet i odgovor proxyja. Ako CONNECT uspije, a TLS zatim ne uspije, dopuštenje odredišnog porta već je odradilo svoje. Nastavite s TLS kvarom umjesto da iznova proširujete AllowCONNECT.