В своей конфигурации я использую Haproxy в основном для обратного прокси.
Я установил Squid Proxy в свою частную сеть, и я могу получить к нему доступ с внешнего порта через порт 3128. Но я использую базовую аутентификацию ncsa, а заголовки не зашифрованы, поэтому мой логин уязвим. Я хочу перенаправить свой прокси через haproxy.
[Клиент] -> proxy.example.net -> [haproxy: 443 ssl] -> [squid: 3128]
Я добавил в свою конфигурацию haproxy новый бэкэнд:
frontend www-https
bind *:443 ssl crt /etc/haproxy/ssl/fullchain.pem no-sslv3
log global
mode http
use_backend proxy-squid if { ssl_fc_sni proxy.example.com }
use_backend default if { ssl_fc_sni example.com }
default_backend default
backend default
option forwardfor
server d8-apps 127.0.0.1:8000 #nginx
backend proxy-squid
mode http
option forwardfor
option http-server-close
server d8-apps 127.0.0.1:3128
Мой бэкэнд по умолчанию и другие работают нормально, но не прокси-сквид. Я обнаружил "tcpdump -nX -vv -i lo port 3128" во время моего запроса и ничего .. а с портом 443 я вижу много пакетов с неправильной контрольной суммой.
В Wireshark я не вижу подтверждения ssl, как при доступе к example.com (бэкэнд по умолчанию). Я просто вижу трехэтапное рукопожатие tcp, за которым следуют FIN, ACK.
Я думаю, что Haproxy не понимает мой настоящий запрос, когда я устанавливаю прокси в конфигурации своего браузера. Итак, возможно ли это реализовать с помощью конкретной конфигурации?
Спасибо!
HTTP содержит несколько разных синтаксисов сообщений, которые используются в разных ситуациях. Сообщения, отправленные на сервер (или обратный прокси), сильно отличаются от сообщений, отправленных на прокси.
Поскольку у вас есть настройка haproxy для работы в качестве обратного прокси, она не разрешает сообщения, необходимые браузеру для настройки туннеля HTTPS.
Поскольку все, что вы на самом деле пытаетесь сделать, это защитить свои подключения к Squid, я предлагаю вам просто заставить его прослушивать https_port для подключений из браузера. Конечно, для этого потребуется установка сертификата TLS с публичным именем прокси-сервера. Обратите внимание, что это не та же деталь сертификата, что и для обратного прокси (который использует доменное имя исходного сервера).
Firefox и Chrome, по-видимому, поддерживают TLS для явного прокси-сервера, если он настроен на его использование через файл PAC или переменную среды https_proxy =. В обоих случаях URI прокси-сервера должен использовать схему https: // вместо схемы http: //.
(Я говорю, очевидно, потому что сам еще не пробовал. У других были смешанные результаты, но браузеры продолжают говорить, что это возможно).