Apache AllowCONNECT i docelowe porty HTTPS

Odróżnij port, którego klienci używają do połączenia z serwerem proxy Apache, od portów docelowych, które mod_proxy_connect dopuszcza wewnątrz tuneli.

Twój serwer proxy Apache nasłuchuje na porcie 3128. Klient skutecznie się z nim łączy, ale usługa HTTPS na porcie 8443 zawodzi. Zmiana portu nasłuchiwania proxy raczej nie rozwiąże tej różnicy.

Klient najpierw łączy się z nasłuchiwaczem proxy. Jego żądanie CONNECT wskazuje następnie odrębny host i port docelowy. Apache może zaakceptować pierwsze połączenie i odrzucić drugą operację.

Czytaj AllowCONNECT jako politykę docelową

W Apache 2.4 mod_proxy_connect obsługuje przychodzące żądania CONNECT. Jego dyrektywa AllowCONNECT kontroluje porty docelowe dostępne dla tych żądań. Udokumentowana wartość domyślna to 443 i 563.

AllowCONNECT 443 8443

Ten przykład wybiera te dwa porty docelowe. Zastępuje on wybór domyślny; nie dodaje 8443 przy cichym zachowaniu wszystkich portów domyślnych. Użyj dyrektywy w odpowiedniej konfiguracji serwera lub hosta wirtualnego.

Zachowaj reguły autoryzacji klientów proxy. Dozwolony port docelowy nic nie mówi o tym, który klient może korzystać z usługi, i nie zastępuje ograniczenia hosta docelowego, gdy jest ono potrzebne.

Przykład odwrotnego proxy odpowiada na inne pytanie

Wyniki wyszukiwania dla Apache i HTTPS często pokazują publiczną witrynę przekazującą ruch do stałego backendu. Ta konfiguracja nie jest sposobem, w jaki przeglądarka prosi proxy forward o otwarcie tunelu CONNECT do wybranej witryny. Skopiowanie jej dyrektyw routingu może pozostawić pierwotny problem proxy nietknięty.

Diagnozując awarię, zapisz nasłuchiwacz, do którego dotarł klient, żądaną władzę CONNECT i odpowiedź proxy. Jeśli CONNECT się powiedzie, a TLS później zawiedzie, zezwolenie na port docelowy już spełniło swoją rolę. Kontynuuj z błędem TLS, zamiast wielokrotnie poszerzać AllowCONNECT.

Powiązane artykuły