Apache AllowCONNECT и целеви портове за HTTPS

Вашето прокси на Apache слуша на порт 3128. Клиент се свързва успешно с него, но HTTPS услуга на порт 8443 се проваля. Промяната на порта за слушане на проксито едва ли ще реши точно тази разлика.

Клиентът първо се свързва със слушателя на проксито. След това неговата CONNECT заявка посочва отделен хост и порт на местоназначението. Apache може да приеме първата връзка и да отхвърли втората операция.

Четете AllowCONNECT като политика за местоназначението

За Apache 2.4 mod_proxy_connect обработва входящите CONNECT заявки. Директивата AllowCONNECT управлява целевите портове, достъпни за тези заявки. Документираната стойност по подразбиране е 443 и 563.

AllowCONNECT 443 8443

Този пример избира тези два целеви порта. Той замества избора по подразбиране; не добавя 8443, като същевременно запазва тихо всички портове по подразбиране. Използвайте директивата в съответната конфигурация на сървъра или виртуалния хост.

Запазете правилата за оторизация на клиентите на проксито на място. Разрешеният целеви порт не казва нищо за това кой клиент може да използва услугата и не замества ограничение на целевия хост, когато такова е необходимо.

Пример с обратно прокси отговаря на друг въпрос

Резултатите от търсене за Apache и HTTPS често показват публичен уебсайт, който препраща към фиксиран бекенд. Тази конфигурация не е начинът, по който браузърът иска от предно прокси да отвори CONNECT тунел към избран уебсайт. Копирането на нейните маршрутизиращи директиви може да остави първоначалния проблем с проксито недокоснат.

Когато диагностицирате повреда, запишете слушателя, до който е достигнал клиентът, поискания CONNECT authority и отговора на проксито. Ако CONNECT успее и след това TLS се провали, разрешението за целеви порт вече е свършило своята част. Продължете с TLS повредата, вместо многократно да разширявате AllowCONNECT.